[ANN] analyze 0.1
Inspired by the ClojureScript compiler, analyze is an interface to the Clojure analysis phase. Check the README for some cool things you can do. https://clojars.org/analyze https://github.com/frenchy64/analyze I've barely tested the library but it manages to analyze a good part of the core Clojure library. This is work in progress. If you heard Rich Hickey talking about leveraging the "analysis phase" at the Conj, this is a step in that direction. Have fun :) Ambrose -- 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: New home for ClojureCLR
Thanks. I hope 2012 is the year for community building for ClojureCLR, And maybe some IDE building. -David On Jan 1, 12:32 pm, rippinrobr wrote: > I would also like to thank David for his work on ClojureCLR. > ClojureCLR is going to make > for a great 2012 for me! > > -Rob Rowe > > On Jan 1, 1:01 pm, Stuart Sierra wrote: > > > > > > > > > And thanks to David Miller for his excellent and continued work on > > ClojureCLR! I'm happy that we have such a great community to support > > Clojure on the .NET platform. > > > -Stuart Sierra > > clojure.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
Re: [ANN] analyze 0.1
Very cool. If you think of other potential example errors this would be capable of detecting it might be nice to include them in a TODO list in the README. This might motivate someone to implement them or develop a nice emacs UI for displaying these errors. Scott On Mon, Jan 2, 2012 at 4:14 AM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Inspired by the ClojureScript compiler, analyze is an interface to the > Clojure analysis phase. > > Check the README for some cool things you can do. > > https://clojars.org/analyze > https://github.com/frenchy64/analyze > > I've barely tested the library but it manages to analyze a good part of > the core Clojure library. > This is work in progress. > > If you heard Rich Hickey talking about leveraging the "analysis phase" at > the Conj, this is a step in that direction. > > Have fun :) > Ambrose > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
accessing multiple return values
Someone was asking on the list here about multiple return values, which Clojure does not have. If the facility were ever added, perhaps multiple values could be accessed via namespaces. Functions would possess another level of namespace and have the ability to inject values into the environment under that namespace. For instance: (defn quotient [x y] . (values quotient remainder)) (clojure.core/quotient 5 2) --> 2 clojure.core/quotient/remainder --> 1 This seems simpler than the Common Lisp way. -- 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
Potential bug w/ inlined functions
Hey all,
I'm writing a function called barr= that looks just like clojure.core/=,
but uses java.util.Arrays/equals instead of equiv. To speed up the function
I tried adding type hints to both the function definition and the
2-argument inlined version. Type hinting the inline function threw an
exception that makes me think the compiler is interpreting Here's the gist:
https://gist.github.com/1551640
Type hints on the function definition work great:
(defn barr=
([x] true)
([^bytes x ^bytes y]
(java.util.Arrays/equals x y))
([x y & more]
(if (barr= x y)
(if (next more)
(recur y (first more) (next more))
(barr= y (first more)))
false)))
But hinting the inline version causes an exception:
(defn barr=
{:inline-arities #{2}
:inline (fn [x y] `(let [^bytes x# ~x
^bytes y# ~y]
(java.util.Arrays/equals x# y#)))}
([x] true)
([^bytes x ^bytes y]
(java.util.Arrays/equals x y))
([x y & more]
(if (barr= x y)
(if (next more)
(recur y (first more) (next more))
(barr= y (first more)))
false)))
;; CompilerException java.lang.IllegalArgumentException: Unable to resolve
classname:
;; clojure.core/bytes, compiling:(NO_SOURCE_PATH:54)
The compiler seems to be interpreting this type hint as a var. Are type
hints not allowed inside of inline definitions for some reason?
Cheers,
--
Sam Ritchie, Twitter Inc
703.662.1337
@sritchie09
(Too brief? Here's why! http://emailcharter.org)
--
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: accessing multiple return values
nchurch writes: Hi, > Someone was asking on the list here about multiple return values, > which Clojure does not have. > > If the facility were ever added, perhaps multiple values could be > accessed via namespaces. Functions would possess another level of > namespace and have the ability to inject values into the environment > under that namespace. For instance: > > (defn quotient [x y] > . > (values quotient remainder)) > > (clojure.core/quotient 5 2) > --> 2 > clojure.core/quotient/remainder > --> 1 > > This seems simpler than the Common Lisp way. I don't think so. And there are several major problems with that approach. First of all, your clojure.core.quotient/remainder var needs to be a mutable, thread-local var, because else you couldn't be sure that 1 is the remainder of the quotient call directly above, or the remainder of a call that happened a blink later in another thread (or ForkJoinTask). Another problem is that if the var name is determined by the name of the local var in the function which is given to `values', then changing its name requires changing all places where clojure.core.quotient/remainder is used. Bye, Tassilo -- 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: Potential bug w/ inlined functions
I suspect this has more to do with type-hinting inside a macro. Did you try
adding :tag metadata to those symbols?
As a side note I do find this approach a bit strange. Why not just define a
generic arr= that with multi-arity inlining?
David
On Mon, Jan 2, 2012 at 1:43 PM, Sam Ritchie wrote:
> Hey all,
>
> I'm writing a function called barr= that looks just like clojure.core/=,
> but uses java.util.Arrays/equals instead of equiv. To speed up the function
> I tried adding type hints to both the function definition and the
> 2-argument inlined version. Type hinting the inline function threw an
> exception that makes me think the compiler is interpreting Here's the gist:
> https://gist.github.com/1551640
>
> Type hints on the function definition work great:
>
> (defn barr=
> ([x] true)
> ([^bytes x ^bytes y]
> (java.util.Arrays/equals x y))
> ([x y & more]
> (if (barr= x y)
>(if (next more)
> (recur y (first more) (next more))
> (barr= y (first more)))
>false)))
>
> But hinting the inline version causes an exception:
>
> (defn barr=
> {:inline-arities #{2}
>:inline (fn [x y] `(let [^bytes x# ~x
> ^bytes y# ~y]
>(java.util.Arrays/equals x# y#)))}
> ([x] true)
> ([^bytes x ^bytes y]
> (java.util.Arrays/equals x y))
> ([x y & more]
> (if (barr= x y)
>(if (next more)
> (recur y (first more) (next more))
> (barr= y (first more)))
>false)))
>
> ;; CompilerException java.lang.IllegalArgumentException: Unable to resolve
> classname:
> ;; clojure.core/bytes, compiling:(NO_SOURCE_PATH:54)
>
> The compiler seems to be interpreting this type hint as a var. Are type
> hints not allowed inside of inline definitions for some reason?
>
> Cheers,
> --
> Sam Ritchie, Twitter Inc
> 703.662.1337
> @sritchie09
>
> (Too brief? Here's why! http://emailcharter.org)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Potential bug w/ inlined functions
You're right, it's macro more than inlining. Tag metadata doesn't throw an
error, but it doesn't fix the reflection warning either (assuming I'm doing
it correctly):
(defmacro barr= [^{:tag bytes} x ^{:tag bytes} y]
`(java.util.Arrays/equals ~x ~y))
(defmacro barr= [ x y]
`(java.util.Arrays/equals ^{:tag bytes} ~x
^{:tag bytes} ~y))
As for the approach, I wanted to start out by mimicking the implementation
of clojure.core/=. I haven't written inlined functions before, and was
curious about the potential speedup. I do like the idea of a generic arr=.
On Mon, Jan 2, 2012 at 11:27 AM, David Nolen wrote:
> I suspect this has more to do with type-hinting inside a macro. Did you
> try adding :tag metadata to those symbols?
>
> As a side note I do find this approach a bit strange. Why not just define
> a generic arr= that with multi-arity inlining?
>
> David
>
> On Mon, Jan 2, 2012 at 1:43 PM, Sam Ritchie wrote:
>
>> Hey all,
>>
>> I'm writing a function called barr= that looks just like clojure.core/=,
>> but uses java.util.Arrays/equals instead of equiv. To speed up the function
>> I tried adding type hints to both the function definition and the
>> 2-argument inlined version. Type hinting the inline function threw an
>> exception that makes me think the compiler is interpreting Here's the gist:
>> https://gist.github.com/1551640
>>
>> Type hints on the function definition work great:
>>
>> (defn barr=
>> ([x] true)
>> ([^bytes x ^bytes y]
>> (java.util.Arrays/equals x y))
>> ([x y & more]
>> (if (barr= x y)
>>(if (next more)
>> (recur y (first more) (next more))
>> (barr= y (first more)))
>>false)))
>>
>> But hinting the inline version causes an exception:
>>
>> (defn barr=
>> {:inline-arities #{2}
>>:inline (fn [x y] `(let [^bytes x# ~x
>> ^bytes y# ~y]
>>(java.util.Arrays/equals x# y#)))}
>> ([x] true)
>> ([^bytes x ^bytes y]
>> (java.util.Arrays/equals x y))
>> ([x y & more]
>> (if (barr= x y)
>>(if (next more)
>> (recur y (first more) (next more))
>> (barr= y (first more)))
>>false)))
>>
>> ;; CompilerException java.lang.IllegalArgumentException: Unable to
>> resolve classname:
>> ;; clojure.core/bytes, compiling:(NO_SOURCE_PATH:54)
>>
>> The compiler seems to be interpreting this type hint as a var. Are type
>> hints not allowed inside of inline definitions for some reason?
>>
>> Cheers,
>> --
>> Sam Ritchie, Twitter Inc
>> 703.662.1337
>> @sritchie09
>>
>> (Too brief? Here's why! http://emailcharter.org)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Sam Ritchie, Twitter Inc
703.662.1337
@sritchie09
(Too brief? Here's why! http://emailcharter.org)
--
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: Potential bug w/ inlined functions
I agree it looks like a type-hinting issue, but since ^bytes x is
reader-expanded to ^{:tag 'bytes} x, I don't see that change making
any difference. I'd be more inclined to try ^"[B" instead, to avoid
the possibility of var resolution.
I don't get the last point. He wants it to be type-hinted so a generic
arr= won't work unless you tell it what type to use; and the compiler
is not set up to support arbitrary-arity inlining, so he would have to
pick some fixed set of arities to support. The set #{2} seems like a
reasonable choice to me, since there's no builtin for comparing
multiple arrays.
On Jan 2, 11:27 am, David Nolen wrote:
> I suspect this has more to do with type-hinting inside a macro. Did you try
> adding :tag metadata to those symbols?
>
> As a side note I do find this approach a bit strange. Why not just define a
> generic arr= that with multi-arity inlining?
>
> On Mon, Jan 2, 2012 at 1:43 PM, Sam Ritchie wrote:
> > Hey all,
>
> > I'm writing a function called barr= that looks just like clojure.core/=,
> > but uses java.util.Arrays/equals instead of equiv. To speed up the function
> > I tried adding type hints to both the function definition and the
> > 2-argument inlined version. Type hinting the inline function threw an
> > exception that makes me think the compiler is interpreting Here's the gist:
> >https://gist.github.com/1551640
>
> > Type hints on the function definition work great:
>
> > (defn barr=
> > ([x] true)
> > ([^bytes x ^bytes y]
> > (java.util.Arrays/equals x y))
> > ([x y & more]
> > (if (barr= x y)
> > (if (next more)
> > (recur y (first more) (next more))
> > (barr= y (first more)))
> > false)))
>
> > But hinting the inline version causes an exception:
>
> > (defn barr=
> > {:inline-arities #{2}
> > :inline (fn [x y] `(let [^bytes x# ~x
> > ^bytes y# ~y]
> > (java.util.Arrays/equals x# y#)))}
> > ([x] true)
> > ([^bytes x ^bytes y]
> > (java.util.Arrays/equals x y))
> > ([x y & more]
> > (if (barr= x y)
> > (if (next more)
> > (recur y (first more) (next more))
> > (barr= y (first more)))
> > false)))
>
> > ;; CompilerException java.lang.IllegalArgumentException: Unable to resolve
> > classname:
> > ;; clojure.core/bytes, compiling:(NO_SOURCE_PATH:54)
>
> > The compiler seems to be interpreting this type hint as a var. Are type
> > hints not allowed inside of inline definitions for some reason?
>
> > Cheers,
> > --
> > Sam Ritchie, Twitter Inc
> > 703.662.1337
> > @sritchie09
>
> > (Too brief? Here's why!http://emailcharter.org)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Potential bug w/ inlined functions
On Jan 2, 2012 11:43 AM, "Sam Ritchie" wrote:
>
> You're right, it's macro more than inlining. Tag metadata doesn't throw
an error, but it doesn't fix the reflection warning either (assuming I'm
doing it correctly):
>
> (defmacro barr= [^{:tag bytes} x ^{:tag bytes} y]
> `(java.util.Arrays/equals ~x ~y))
>
> (defmacro barr= [ x y]
> `(java.util.Arrays/equals ^{:tag bytes} ~x
> ^{:tag bytes} ~y))
>
The pevious macro is incorrectly written.
> As for the approach, I wanted to start out by mimicking the
implementation of clojure.core/=. I haven't written inlined functions
before, and was curious about the potential speedup. I do like the idea of
a generic arr=.
>
> On Mon, Jan 2, 2012 at 11:27 AM, David Nolen
wrote:
>>
>> I suspect this has more to do with type-hinting inside a macro. Did you
try adding :tag metadata to those symbols?
>>
>> As a side note I do find this approach a bit strange. Why not just
define a generic arr= that with multi-arity inlining?
>>
>> David
>>
>> On Mon, Jan 2, 2012 at 1:43 PM, Sam Ritchie wrote:
>>>
>>> Hey all,
>>>
>>> I'm writing a function called barr= that looks just like
clojure.core/=, but uses java.util.Arrays/equals instead of equiv. To speed
up the function I tried adding type hints to both the function definition
and the 2-argument inlined version. Type hinting the inline function threw
an exception that makes me think the compiler is interpreting Here's the
gist: https://gist.github.com/1551640
>>>
>>> Type hints on the function definition work great:
>>>
>>> (defn barr=
>>> ([x] true)
>>> ([^bytes x ^bytes y]
>>> (java.util.Arrays/equals x y))
>>> ([x y & more]
>>> (if (barr= x y)
>>>(if (next more)
>>> (recur y (first more) (next more))
>>> (barr= y (first more)))
>>>false)))
>>>
>>> But hinting the inline version causes an exception:
>>>
>>> (defn barr=
>>> {:inline-arities #{2}
>>>:inline (fn [x y] `(let [^bytes x# ~x
>>> ^bytes y# ~y]
>>>(java.util.Arrays/equals x# y#)))}
>>> ([x] true)
>>> ([^bytes x ^bytes y]
>>> (java.util.Arrays/equals x y))
>>> ([x y & more]
>>> (if (barr= x y)
>>>(if (next more)
>>> (recur y (first more) (next more))
>>> (barr= y (first more)))
>>>false)))
>>>
>>> ;; CompilerException java.lang.IllegalArgumentException: Unable to
resolve classname:
>>> ;; clojure.core/bytes, compiling:(NO_SOURCE_PATH:54)
>>>
>>> The compiler seems to be interpreting this type hint as a var. Are type
hints not allowed inside of inline definitions for some reason?
>>>
>>> Cheers,
>>> --
>>> Sam Ritchie, Twitter Inc
>>> 703.662.1337
>>> @sritchie09
>>>
>>> (Too brief? Here's why! http://emailcharter.org)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>
>
> --
> Sam Ritchie, Twitter Inc
> 703.662.1337
> @sritchie09
>
> (Too brief? Here's why! http://emailcharter.org)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Potential bug w/ inlined functions
Hi,
Am 02.01.2012 um 21:27 schrieb Kevin Downey:
>> (defmacro barr= [ x y]
>> `(java.util.Arrays/equals ^{:tag bytes} ~x
>> ^{:tag bytes} ~y))
>
> The pevious macro is incorrectly written.
And to enlighten the astute reader why (and to use the occasion for a shameless
self-promotion):
http://kotka.de/blog/2009/12/with-meta_and_the_reader.html
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: [ANN] analyze 0.1
Very cool stuff Ambrose! On Mon, Jan 2, 2012 at 1:11 PM, Scott Jaderholm wrote: > Very cool. If you think of other potential example errors this would be > capable of detecting it might be nice to include them in a TODO list in the > README. This might motivate someone to implement them or develop a nice > emacs UI for displaying these errors. > > Scott > > > On Mon, Jan 2, 2012 at 4:14 AM, Ambrose Bonnaire-Sergeant < > abonnaireserge...@gmail.com> wrote: > >> Inspired by the ClojureScript compiler, analyze is an interface to the >> Clojure analysis phase. >> >> Check the README for some cool things you can do. >> >> https://clojars.org/analyze >> https://github.com/frenchy64/analyze >> >> I've barely tested the library but it manages to analyze a good part of >> the core Clojure library. >> This is work in progress. >> >> If you heard Rich Hickey talking about leveraging the "analysis phase" at >> the Conj, this is a step in that direction. >> >> Have fun :) >> Ambrose >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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: clj-http - how to use cookies in subsequent request
Excellent thanks Stephen that's done the trick, I've been pulling my
hair out over this!
On Jan 1, 9:40 pm, Stephen Compall wrote:
> On Sun, 2012-01-01 at 08:11 -0800, djh wrote:
> > How do I use this response as part of any subsequent requests? The
> > response contains a 302 code which I'd imagine should redirect to the
> > homepage as a logged in user, but I'm struggling to understand how to
> > make clj-http use the authenticated cookie as part of new requests.
>
> I think you can just pass {:cookies ...} with the same value from the
> response back in with the second request, based on a reading of the
> code.
>
> However, if you're willing to cut out the middleman and go
> non-functional, a single DefaultHttpClient from Apache
> httpcomponents-client can hold on to a stateful cookie jar for multiple
> requests.
>
> --
> Stephen Compall
> ^aCollection allSatisfy: [:each|aCondition]: less is better
--
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
Do you use Monads in your real clojure applications
Hello, I would like to know do you use Monads in your real clojure applications, and are monads realy useful in impure functional languages like clojure? On the net I read that "Impure functional programming doesn't really need monads." and "It appears that in the presence of mutable state, a lot of the advantages of monads become moot." ( sources: http://www.reddit.com/r/programming/comments/p66e/are_monads_actually_used_in_anything_except http://marijnhaverbeke.nl/monad.html ) so I am interesting to hear what clojure programmers think about that. Thanks in advance for your help. Best regards, Dragan Radevic -- 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: Prefix tree creation in clojure
On Sun, 2012-01-01 at 23:16 -0500, Cedric Greevey wrote: > And that will obviously be chock-full of internals changes and > miscellaneous tweaks and not just the user-visible feature > changes/additions, aimed more at developers of Clojure itself than at > developers using Clojure to make other things. No, it's not. That stuff is in `git log'. > Other than as a shorthand for (if (not-empty x) x) the return value is > unlikely to be used very often for more than its truthiness. Most library functions are shorthand for something else, and much of their value lies in capturing a common idiom. `not-empty' is used several times in core.clj itself, and only once as a truth test. (Moreover, that instance, in `underive', deviates from common Clojure style in other ways.) The usual function to use for truth in this situation is `seq', not `not-empty'. See core.clj: (defn empty? "Returns true if coll has no items - same as (not (seq coll)). Please use the idiom (seq x) rather than (not (empty? x))" ...and several past discussions on this list not otherwise relevant to this thread. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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: Do you use Monads in your real clojure applications
On Mon, 2012-01-02 at 05:18 -0800, Dragan R wrote: > and are monads realy useful in impure functional languages like > clojure? Clojure's impurity doesn't mean that we wouldn't like to avoid side-effecty ways of doing stuff. Monads can help you there, among other things. The monad idea captures a very high-level abstraction, giving you the stuff that is implemented on that idea for free. For example, if you want an idea of `map' for your data structure, you'll get m-fmap if you write a monad instance. Some of this stuff seeps into more commonplace operators. `for' is essentially a sugary and faster `domonad sequence-m'. Likewise, the terribly useful `-?>' from core.incubator is much like `((with-monad maybe-m (m-chain [...])) start)'. That said, Haskell-style evaluation and type inference does make them more useful and easier to use. > I would like to know do you use Monads in your real clojure > applications, Aside from `-?>' and `for', I've implemented one custom monad instance for a production Clojure application. No doubt some of the stuff I've done with dynamic vars would have been cleaner with the reader monad; https://github.com/straszheimjeffrey/The-Kiln will, I think, be a good use case for the reader monad when it's ready. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- 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: Do you use Monads in your real clojure applications
Midje has some of its error handling code implemented with a monad. https://github.com/marick/Midje/blob/master/src/midje/error_handling/monadic.clj#L32 `error-let` is like a regular let, except if there is a validation-error, that error short-circuits out. Alex -- 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] swank-clojure 1.3.4 released
Keith Irwin writes: > The only way I could get the colorized stack-trace was to use M-x > clojure-jack-in. > > Normally, I type "lein swank" on a command line, then use M-x > slime-connect from Emacs. This is so that I can see the > clojure.tools.logging output. (I've no idea where it goes when you use > clojure-jack-in. Getting colors outside M-x clojure-jack-in requires a couple extra steps I forgot to document, I just added it here: https://github.com/technomancy/swank-clojure/commit/94fa71f90e52c55d74 -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Prefix tree creation in clojure
On Mon, Jan 2, 2012 at 5:28 PM, Stephen Compall wrote: > On Sun, 2012-01-01 at 23:16 -0500, Cedric Greevey wrote: >> And that will obviously be chock-full of internals changes and >> miscellaneous tweaks and not just the user-visible feature >> changes/additions, aimed more at developers of Clojure itself than at >> developers using Clojure to make other things. > > No, it's not. That stuff is in `git log'. Anything that's packaged with the source rather than with the binary, and/or is on the repo site and/or the dev.* site rather than on the main web site, is thereby more or less being *stated* to be intended for the software's developers rather than its users. > Most library functions are shorthand for something else, and much of > their value lies in capturing a common idiom. `not-empty' is used > several times in core.clj itself, and only once as a truth test. Not a representative sample; core.clj does a lot of things weirdly due to things not yet being defined at a particular point, etc. > The usual function to use for truth in this situation is `seq', not > `not-empty'. Yes; not-empty does seem rather redundant with that, other than for the narrow and unusual case where you'd otherwise have (if (seq x) x). But it's more likely you'd have (if (seq x) (...more complex expression using x) (...alternative)) or (if-let [x (seq x)] ...). About the only spot I can think of for using it, offhand, is when calling a function and passing an argument that should be a collection or nil, and wanting the collection type unmodified if it isn't nil, so (seq x) won't do. All of the subcases I can think of offhand, in turn, *do* work fine with (seq x), or even with a non-nil empty collection, for example concat. The case above, where you want to nil out substring if it's not empty but not disturb its stringness, is actually about the only one I think likely, and there are probably other ways to solve the problem, probably by accepting an empty string instead of nil or by moving the empty check to where a nil check is currently used. Nil punning is clever, but sometimes it's cleverness purely for its own sake and at the expense of tangling some of the rest of the code. > ^aCollection allSatisfy: [:each|aCondition]: less is better Eh, another (ex-)Smalltalk hacker? -- 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] swank-clojure 1.3.4 released
> Getting colors outside M-x clojure-jack-in requires a couple extra steps > I forgot to document, I just added it here: > > https://github.com/technomancy/swank-clojure/commit/94fa71f90e52c55d74 Thanks, the above steps worked--almost. I now see the raw ANSI color escape codes and not the colors. How do I tell Emacs to interpret the color codes the right way? Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: accessing multiple return values
On Mon, Jan 2, 2012 at 2:16 PM, Tassilo Horn wrote: > nchurch writes: > > Hi, > >> Someone was asking on the list here about multiple return values, >> which Clojure does not have. >> >> If the facility were ever added, perhaps multiple values could be >> accessed via namespaces. Functions would possess another level of >> namespace and have the ability to inject values into the environment >> under that namespace. For instance: >> >> (defn quotient [x y] >> . >> (values quotient remainder)) >> >> (clojure.core/quotient 5 2) >> --> 2 >> clojure.core/quotient/remainder >> --> 1 >> >> This seems simpler than the Common Lisp way. > > I don't think so. And there are several major problems with that > approach. First of all, your clojure.core.quotient/remainder var needs > to be a mutable, thread-local var, because else you couldn't be sure > that 1 is the remainder of the quotient call directly above, or the > remainder of a call that happened a blink later in another thread (or > ForkJoinTask). > > Another problem is that if the var name is determined by the name of the > local var in the function which is given to `values', then changing its > name requires changing all places where clojure.core.quotient/remainder > is used. On top of all that, how often is this needed anyway where destructuring or metadata can't solve the problem? When performance isn't a concern and you control the calling functions (or they're generic things like map and reduce that just pass the return value through to code you control, such as whatever processes the map sequence output) you can replace something with a vector of that something and additional values, and destructure. And even when you don't control the calling functions, and replacing the return value with a wrapper of any kind would blow up, if that return value is a seq, vector, or other Clojure data type that supports metadata, you can attach metadata (and, to avoid collisions, use namespaced keywords in it) to smuggle the extra values out. In a similar vein, if a non-primitive, non-final Java type is the expected value, you can subclass it with added fields and getters to smuggle out the extra values (the old "decorator pattern") using deftype or reify or proxy. (Some of these don't let you explicitly add fields, but all of them let you define "getters" that close over locals in the function returning them. You'll need a definterface specifying the getters, too.) When the only objection to destructuring is performance, as is likely with your quotient-and-remainder case or similar mathematical-transform cases, there's a final judo move available: continuation-passing. You make the code that was going to *use* the results into a *parameter*, which takes all of the results as arguments. Pre-1.3 you'd probably write something like (defmacro quot-and-rem [a b q r & forms] `(let [a# (long ~a) b# (long ~b) t# (... a# ... b# ...) ~q (...) ~r (...)] ~@forms)) which would execute forms with q and r bound to the quot and rem, respectively, of a and b. Now you can also pass a function expecting two long primitives to a function that takes two long primitives and a function and calls that function with two long primitives, the quotient and the remainder. (The macro approach still gets you the potential benefits and drawbacks of inlining both functions: avoiding the overhead of calls and parameter passing, twice, but also making the current function larger, perhaps large enough to cause cache misses. Obviously it also lets you stay source-compatible with older Clojure versions, for whatever that's worth.) -- 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] swank-clojure 1.3.4 released
On Tue, Jan 3, 2012 at 12:28 AM, Baishampayan Ghose wrote: >> Getting colors outside M-x clojure-jack-in requires a couple extra steps >> I forgot to document, I just added it here: >> >> https://github.com/technomancy/swank-clojure/commit/94fa71f90e52c55d74 > > Thanks, the above steps worked--almost. I now see the raw ANSI color > escape codes and not the colors. How do I tell Emacs to interpret the > color codes the right way? My preferred method would involve 'rm /user/bin/emacs', but maybe that's just me. ;) Seriously, though. Terminals? Escape codes? Impedance mismatches involving term types and escape codes? What is this, the Dark Ages? Those kinds of problems simply should not trouble us in the 21st century. -- 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] analyze 0.1
Hi Ambrose I’ve been playing around with your library and find it very intresting. A couple of questions: 1. In order to be able to run your examples I have to comment out the clojure.test, clojure.stacktrace and clojure.template namespaces. Otherwise I get a NullPointerException[1] which I’m unable to track down. It seems to originate from the wall-hack function. What does this function do? 2. Is it possible to do some analysis before macroexpansion? For example, If I want to look for the pattern (if (some-test? …) (some-expr …) nil) and print the following: “WARNING: consider using (when …) instead of (if test then nil)”. Is this possible since (when test expr) expands to (if test (do expr)). Maybe this kind of code analysis is outside the scope of your library? [1]: https://gist.github.com/1553808 -- 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] analyze 0.1
Hi Jonas On Tue, Jan 3, 2012 at 2:43 PM, Jonas wrote: > > 1. In order to be able to run your examples I have to comment out the > clojure.test, clojure.stacktrace and clojure.template namespaces. Otherwise > I get a NullPointerException[1] which I’m unable to track down. It seems to > originate from the wall-hack function. What does this function do? > wall-hack allows me to access method/fields of private classes via reflection. If there's a better way I'm all ears, but if I'm using wall-hack it usually means the Class is private. That being said, the stacktrace you're getting originates in the Compiler's analysis phase. The call to wall-hack is a call to clojure.lang.Compiler/analyze. Be ready for some very cryptic errors :) It also helps to have a clone of the clojure source to follow the stacktrace. How are you running the code? Could you pull the latest master and try again? Possibly track down exactly which namespace is causing the Exception. (I just realized there's a public method of clojure.lang.Compiler/analyze, so wall-hack is not necessary for calling clojure.lang.Compiler/analyze. Just pushed the change.) > 2. Is it possible to do some analysis before macroexpansion? For example, > If I want to look for the pattern > > (if (some-test? …) > (some-expr …) > nil) > > and print the following: “WARNING: consider using (when …) instead of (if > test then nil)”. Is this possible since (when test expr) expands to (if > test (do expr)). Maybe this kind of code analysis is outside the scope of > your library? > This would be easy if the analyzer was more like ClojureScript's analyzer. ie. written in Clojure with multimethods. But I'm not sure how to do this otherwise. You'd basically want to add a new special form that tells the analyzer to stop macroexpanding. Basically, yes, this is outside the scope of what I hope to achieve right now. Thanks, Ambrose -- 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] analyze 0.1
Actually, it's my environment which is the issue. Vimclojure seems to load lots of extra libs. It seems to be barfing at the `ns` forms. Ambrose On Tue, Jan 3, 2012 at 3:13 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Hi Jonas > > On Tue, Jan 3, 2012 at 2:43 PM, Jonas wrote: >> >> 1. In order to be able to run your examples I have to comment out the >> clojure.test, clojure.stacktrace and clojure.template namespaces. Otherwise >> I get a NullPointerException[1] which I’m unable to track down. It seems to >> originate from the wall-hack function. What does this function do? >> > > wall-hack allows me to access method/fields of private classes via > reflection. If there's a better way I'm all ears, but if I'm using > wall-hack it usually means the Class is private. > > That being said, the stacktrace you're getting originates in the > Compiler's analysis phase. The call to wall-hack is a call to > clojure.lang.Compiler/analyze. > > Be ready for some very cryptic errors :) It also helps to have a clone of > the clojure source to follow the stacktrace. > > How are you running the code? Could you pull the latest master and try > again? Possibly track down exactly which namespace is causing the Exception. > > (I just realized there's a public method of clojure.lang.Compiler/analyze, > so wall-hack is not necessary for calling clojure.lang.Compiler/analyze. > Just pushed the change.) > > >> 2. Is it possible to do some analysis before macroexpansion? For example, >> If I want to look for the pattern >> >> (if (some-test? …) >> (some-expr …) >> nil) >> >> and print the following: “WARNING: consider using (when …) instead of (if >> test then nil)”. Is this possible since (when test expr) expands to (if >> test (do expr)). Maybe this kind of code analysis is outside the scope of >> your library? >> > > This would be easy if the analyzer was more like ClojureScript's analyzer. > ie. written in Clojure with multimethods. > > But I'm not sure how to do this otherwise. You'd basically want to add a > new special form that tells the analyzer to stop macroexpanding. > > Basically, yes, this is outside the scope of what I hope to achieve right > now. > > Thanks, > Ambrose > -- 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] swank-clojure 1.3.4 released
Baishampayan Ghose writes: Hi Baishampayan, >> Getting colors outside M-x clojure-jack-in requires a couple extra >> steps I forgot to document, I just added it here: >> >> https://github.com/technomancy/swank-clojure/commit/94fa71f90e52c55d74 > > Thanks, the above steps worked--almost. I now see the raw ANSI color > escape codes and not the colors. How do I tell Emacs to interpret the > color codes the right way? ,[ C-h f ansi-color-for-comint-mode-on RET ] | ansi-color-for-comint-mode-on is an interactive compiled Lisp function in | `ansi-color.el'. | | (ansi-color-for-comint-mode-on) | | Set `ansi-color-for-comint-mode' to t. ` Bye, Tassilo -- 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] analyze 0.1
Hi, I pulled the latest version. > How are you running the code? Could you pull the latest master and try again? Nothing fancy: - clone the repo - lein deps - start emacs, clojure-jack-in, - compile e.g., examples/docstring -> NullPointerException - comment out the three namespaces I mentioned -> It works perfectly :) > Possibly track down exactly which namespace is causing the Exception. The following works (def analyzed (map #(apply analyze/analyze-path %) '[#_["clojure/test.clj" clojure.test] ["clojure/set.clj" clojure.set] ["clojure/java/io.clj" clojure.java.io] #_["clojure/stacktrace.clj" clojure.stacktrace] ["clojure/pprint.clj" clojure.pprint] ["clojure/walk.clj" clojure.walk] ["clojure/string.clj" clojure.string] ["clojure/repl.clj" clojure.repl] ["clojure/core/protocols.clj" clojure.core.protocols] #_["clojure/template.clj" clojure.template]])) Uncommenting any of the three lines above results in a NullPointerException. -- 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] swank-clojure 1.3.4 released
On Tue, Jan 3, 2012 at 1:03 PM, Tassilo Horn wrote: >> Thanks, the above steps worked--almost. I now see the raw ANSI color >> escape codes and not the colors. How do I tell Emacs to interpret the >> color codes the right way? > > ,[ C-h f ansi-color-for-comint-mode-on RET ] > | ansi-color-for-comint-mode-on is an interactive compiled Lisp function in > | `ansi-color.el'. > | > | (ansi-color-for-comint-mode-on) > | > | Set `ansi-color-for-comint-mode' to t. Thanks Tassilo, but that turns on ansi color for the shell, and not the sldb buffer with the stacktrace. Is there any way to enable that globally? Regards, BG -- Baishampayan Ghose b.ghose at gmail.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
Re: [ANN] analyze 0.1
Thanks for that. It seems if the namespace is not already loaded, then there are issues. I already suspected this, and to be honest I don't know the Compiler well enough to fully appreciate the problem. Looking into it. Ambrose On Tue, Jan 3, 2012 at 3:37 PM, Jonas wrote: > Hi, > > I pulled the latest version. > > > How are you running the code? Could you pull the latest master and try > again? > > Nothing fancy: > - clone the repo > - lein deps > - start emacs, clojure-jack-in, > - compile e.g., examples/docstring -> NullPointerException > - comment out the three namespaces I mentioned -> It works perfectly :) > > > Possibly track down exactly which namespace is causing the Exception. > > The following works > > (def analyzed > (map #(apply analyze/analyze-path %) >'[#_["clojure/test.clj" clojure.test] > ["clojure/set.clj" clojure.set] > ["clojure/java/io.clj" clojure.java.io] > #_["clojure/stacktrace.clj" clojure.stacktrace] > ["clojure/pprint.clj" clojure.pprint] > ["clojure/walk.clj" clojure.walk] > ["clojure/string.clj" clojure.string] > ["clojure/repl.clj" clojure.repl] > ["clojure/core/protocols.clj" clojure.core.protocols] > #_["clojure/template.clj" clojure.template]])) > > Uncommenting any of the three lines above results in a > NullPointerException. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] analyze 0.1
On Tuesday, January 3, 2012 9:45:04 AM UTC+2, Ambrose Bonnaire-Sergeant wrote: > > It seems if the namespace is not already loaded, then there are issues. That's it! It's simple to fix. Just require the namespaces in the ns form. I can send you a pull request if you want to? /Jonas -- 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
