Re: Invalid-token when dereferencing namespaced keywords.

[Justin Smith]

you are misusing the :: alias resolution operator, user is not an alias

Clojure 1.9.0
(ins)user=> (ns foo)
nil
(ins)foo=> ::user/a
RuntimeException Invalid token: ::user/a
clojure.lang.Util.runtimeException (Util.java:221)
(ins)foo=> :user/a
:user/a

On Tue, Jan 29, 2019 at 2:52 PM Philip Markgraf  wrote:
>
> I am moving some code to use spec and namespaced keywords under Clojure 
> 1.10.0 (release). One group of keywords starts with a numeric character after 
> the colon, which has worked fine in the non-namespaced context. Creating and 
> using the namespaced keyword works correctly in the local namespace (using 
> only the double-colon), but fails with "Invalid Token" when dereferencing 
> from another workspace.
>
> I'm not sure if this is a bug or if I have been taking advantage of an 
> undocumented/unsupported feature.
> Having a leading-digit keyword has been very useful, as the names are an 
> exacting fit of the problem domain and don't suffer from the addition of any 
> visual pollution.
>
> user=> (def example-a {:015-00 "015-00"})
> #'user/example-a
> user=> (def example-b {::015-00 "015-00"})
> #'user/example-b
> user=> (:015-00 example-a)
> "015-00"
> user=> (:015-00 example-b)
> nil
> user=> (::015-00 example-b)
> "015-00"
> user=> (::015-00 example-a)
> nil
> user=> (ns try)
> nil
> try=> (:015-00 user/example-a)
> "015-00"
> try=> (::user/015-00 user/example-b)
>
> Syntax error reading source at (REPL:1:15).
> Invalid token: ::user/015-00
> Syntax error reading source at (REPL:1:31).
> Unmatched delimiter: )
> try=>
>
> The current behavior is certainly inconsistent, even if it is not a serious 
> bug.
>
> Thank you!
>
>
> --
> 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: Using map to produce side effects, not working

[Justin Smith]

also do note that clojure.core/run! is designed for two-arg map when
it's only run for side effects, and clojure.core/doseq is designed for
nested side-effecting iteration

On Thu, Feb 7, 2019 at 3:33 AM Pierpaolo Tofani
 wrote:
>
> Thanks ! Your diagnosis is correct. With two dorun works fine.
>
> Il giorno giovedì 7 febbraio 2019 12:19:40 UTC+1, Orestis Markou ha scritto:
>>
>> Without having ran your code, it seems that the inner map is not wrapped in 
>> a doall, so while the outer lazy-seq is forced, the inner is not.
>>
>> This might be of interest to you: 
>> http://clojure-doc.org/articles/language/laziness.html
>>
>> If you only want to do map for side effects, you could use dorun instead of 
>> doall.
>>
>> On 7 Feb 2019, at 12:04 PM, Pierpaolo Tofani  wrote:
>>
>> Hi
>> i am new in clojure sorry.
>> In the snippet of code i used two map functions only to produce side effects 
>> on two ref.
>> Even using doall no affect is produced on ref aaa and zzz, seems that the 
>> sequence is still lazy.
>> But if i remove the final :done , and the repl show me the sequence produced 
>> (that i don't care) the ref aaa and zzz are affected.Thanks in advance.
>> PS The two map are in effect doing a for.
>>
>> (def aaa (ref 0))
>> (def zzz (ref 0))
>> (def s1 [1 2 3 4 5])
>> (def s2 [1 2 3 4 5])
>> (defn make-side []
>> (do
>> (doall
>> (map
>>   (fn [x]
>> (map
>>   (fn [y]
>> (dosync
>>   (alter aaa inc)
>>   (alter zzz dec)
>> )
>> )
>>   s2))
>>   s1)
>> )
>> :done
>> )
>> )
>>
>>
>> --
>> 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.

-- 
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: results from sort-by are not sorted

[Justin Smith]

minor nitpick to the answer Sean provided: #{:age} as a function returns
:age for an argument equal to :age and nil for all other inputs, including
a hash map containing that key.

On Sun, May 5, 2019, 22:22  wrote:

> Thanks. What a newbie question.
>
> 在 2019年5月6日星期一 UTC+8上午11:34:36，se...@corfield.org写道：
>>
>> (sort-by #{:age} …) will use the set #{:age} as the keyfn, and both
>> (#{:age} {:age 3, :name “luo”}) and (#{:age} {:age 1, :name “sheng”}) both
>> return :age – because both maps contain the key in the set. As far as
>> sort-by is concerned, both hash maps compare equal.
>>
>>
>>
>> What you want is (sort-by :age …) so you the keyfn pulls the value
>> corresponding to :age out of the hash maps. That will produce 3 from {:age
>> 3, :name “luo”} and 1 from {:age 1, :name “sheng”} so they will sort
>> appropriately.
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>>
>> *From: *sheng@gmail.com
>> *Sent: *Sunday, May 5, 2019 7:48 PM
>> *To: *Clojure
>> *Subject: *results from sort-by are not sorted
>>
>>
>>
>> Hey there,
>>
>>
>>
>> in my lein repl,
>>
>>
>>
>> (sort-by #{:age} [{:age 3,:name "luo"},{:age 1,:name "sheng"}])
>>
>>
>>
>> returns
>>
>>
>>
>> ({:age 3, :name "luo"} {:age 1, :name "sheng"})
>>
>>
>>
>> rather than
>>
>>
>>
>> ({:age 1, :name "sheng"}, {:age 3, :name "luo"}).
>>
>>
>>
>> Why?
>>
>> --
>> 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
>> clo...@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 clo...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Blocking behavior of >!! ?

[Justin Smith]

I might be missing something here, but when it is mentioned that
something blocks, it's implicit in all cases that there's some
condition that allows it to proceed (even immediately) if satisfied.
If there's no buffer space it blocks, until that value is consumed.
Just because we can construct a case where the consuption happens
immediately doesn't mean the call doesn't block.

On Mon, May 20, 2019 at 9:33 AM LaurentJ  wrote:
>
> ...waiting -offers +takers
>
> Le lundi 20 mai 2019 18:30:36 UTC+2, LaurentJ a écrit :
>>
>> You are not wrong.
>>
>> I think it was obvious for the author to consider that >!! will not block if 
>> there are waiting offers.
>>
>> You can see it in the code, if no buffer is set the write method will 
>> iterate over takers ready to consume the value.
>> https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116
>>
>>
>>
>> Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>>>
>>> Thanks, Thomas. I shouldn't have included the quoted code about (>> my question because it distracts from what I really want to know, and what 
>>> I want to know is all about how (go (>> so that (>!! c 42) doesn't block.
>>>
>>> The following is an attempt to clarify my question. I first (go (>> give the name d to the result, which is a channel that I am going read-from 
>>> later. Channel d is "connected to" or "relayed from" c. I then (>!! c 42), 
>>> and then (>> wasted your attention by writing some code that would block (>> weren't quoted.
>>>
>>> Here is the part I don't understand: the documentation says that (>!! c 42) 
>>> will block "if there is no buffer space available," and the documentation 
>>> does not specify any other conditions. Well, I created c with no buffer 
>>> space, so, (>!! c 42) must block unless something else "makes buffer space 
>>> available," assuming the documentation is correct. The only other 
>>> interaction with c that could possibly be alive at the time when I do (>!! 
>>> c 42), is (go (>> assuming the documentation is correct. My understanding of (>> suspicious of my understanding), is that (>> available, not a buffer. If that understanding is correct, then (>!! c 42) 
>>> should block because there is no buffer available.
>>>
>>> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:

 (>>> by the first go (running in a different thread). So it is blocking until 
 something puts another value into c. Since nothing ever does your program 
 hangs.

 If it helps you can read "go" as "please run this somewhere else, possibly 
 at a different time" and let the current thread continue after the go.

 I can't explain this very well but the documentation aspect is accurate.

 On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>
> The documentation for >!! reads:
>
> -
> clojure.core.async/>!!
> ([port val])
>   puts a val into port. nil values are not allowed. Will block if no
>   buffer space is available. Returns true unless port is already closed.
>
>
> I have a case where I believe that the channel has no buffer, I park a 
> "pseudothread" in a go block reading off that channel via  (lexically, not temporally), put to the unbuffered channel via >!!:
>
> (let [c (chan) ;; NO BUFFER!
>   d (go (   e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
> (println {:c-coughs-up '(this will hang (   :d-coughs-up (   :what's-ee})
> (close! c) (close! d))
>
> {:c-coughs-up (this will hang (
>
> This case leads me to wonder whether the documentation might read
>
>  >!! will block if there is no buffer space available and if there is no 
> rendezvous available, that is, no pseudothread parked waiting for 
> but it's more likely that I completely misunderstand core.async because I 
> just made up the notion of a pseudothread in my struggle to understand!
>
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/456c5363-a2fd-49e8-9de5-73ae9ffae075%40googlegroups.com.
> For more options, visit https://groups.google.co

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

[Justin Smith]

if you define proto method x, it belongs to the protocol namespace no
matter where it is called, and calling it as if it belonged to the
namespace defining the object extending the protocol will and should
fail

On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
 wrote:
>
> Hi folks,
>
> This has me completely stumped - I would massively appreciate a helping hand! 
> Suppose the following simple directory structure:
>
>
> — someProject.impl.{foo.clj, bar.clj,baz.clj}
> — someProject.proto.clj
> — someProject.api.clj
>
> `proto.clj` contains a single protocol with two methods - let’s call them X & 
> Y. Each implementation namespace (foo, bar, baz), requires 
> `[someProject.proto :as proto]`,  extends it to 3 types (bytes/chars/String), 
> and defines two public fns x & y which delegate to `proto/X` & `proto/Y` 
> respectively. Everything is good so far. I can fire up a REPL, load any of 
> the impl  namespaces (foo, bar, baz), call the corresponding x or y fn and 
> get the right result.
>
> Now, I want to provide a unified API so that the caller doesn’t need to 
> (potentially) require 3 namespaces. Hence the `someProject.api` ns, which 
> contains require clauses for all impl namespaces + two multi-methods `X-with` 
> & `Y-with` with 3 implementations (`defmethod`) each. Each implementation 
> delegates to the x or y fn in the right impl namespace. In other words,  
> `X-with :foo` calls `(foo/x)`, `X-with :bar` calls `(bar/x)` etc etc. 
> Remember, that calling x or y inside any impl namespace works correctly, so 
> all I’m doing here is providing a multi-method wrapper. However, things don’t 
> work as I was expecting in this namespace…Loading `someProject.api` in a 
> fresh REPL and calling  `X-with :foo` bottoms out at the protocol extension 
> for X in the baz ns, which is the last require clause in the api namespace.
>
> So basically,  the protocol extensions in each impl namespace work fine when 
> called from their wrapper fn in the namespace they were defined, but don’t 
> quite work when the same wrapper fn is called from some other namespace! What 
> am I missing? :(
>
> Many thanks in advance…
> Dimitris
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/A549FB15-0B12-4E20-9D98-4F5A56330DC4%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAGokn9L-8Stw4ucMJ4DueU5CFVabvTCr1DupOE95oyMhu5fkuw%40mail.gmail.com.

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

[Justin Smith]

it might be helpful to consider that in the jvm methods are not data,
and the proto function makes the method into concrete data belongs to
the namespace that owns the protocol

On Thu, Nov 21, 2019 at 2:58 PM Justin Smith  wrote:
>
> if you define proto method x, it belongs to the protocol namespace no
> matter where it is called, and calling it as if it belonged to the
> namespace defining the object extending the protocol will and should
> fail
>
> On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
>  wrote:
> >
> > Hi folks,
> >
> > This has me completely stumped - I would massively appreciate a helping 
> > hand! Suppose the following simple directory structure:
> >
> >
> > — someProject.impl.{foo.clj, bar.clj,baz.clj}
> > — someProject.proto.clj
> > — someProject.api.clj
> >
> > `proto.clj` contains a single protocol with two methods - let’s call them X 
> > & Y. Each implementation namespace (foo, bar, baz), requires 
> > `[someProject.proto :as proto]`,  extends it to 3 types 
> > (bytes/chars/String), and defines two public fns x & y which delegate to 
> > `proto/X` & `proto/Y` respectively. Everything is good so far. I can fire 
> > up a REPL, load any of the impl  namespaces (foo, bar, baz), call the 
> > corresponding x or y fn and get the right result.
> >
> > Now, I want to provide a unified API so that the caller doesn’t need to 
> > (potentially) require 3 namespaces. Hence the `someProject.api` ns, which 
> > contains require clauses for all impl namespaces + two multi-methods 
> > `X-with` & `Y-with` with 3 implementations (`defmethod`) each. Each 
> > implementation delegates to the x or y fn in the right impl namespace. In 
> > other words,  `X-with :foo` calls `(foo/x)`, `X-with :bar` calls `(bar/x)` 
> > etc etc. Remember, that calling x or y inside any impl namespace works 
> > correctly, so all I’m doing here is providing a multi-method wrapper. 
> > However, things don’t work as I was expecting in this namespace…Loading 
> > `someProject.api` in a fresh REPL and calling  `X-with :foo` bottoms out at 
> > the protocol extension for X in the baz ns, which is the last require 
> > clause in the api namespace.
> >
> > So basically,  the protocol extensions in each impl namespace work fine 
> > when called from their wrapper fn in the namespace they were defined, but 
> > don’t quite work when the same wrapper fn is called from some other 
> > namespace! What am I missing? :(
> >
> > Many thanks in advance…
> > Dimitris
> >
> >
> > --
> > 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.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/clojure/A549FB15-0B12-4E20-9D98-4F5A56330DC4%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAGokn9%2B1ZiFHBzuS_bwSyrx0DsM_ocu7dk844DnU-h5D3b9fzA%40mail.gmail.com.

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

[Justin Smith]

there is no foo/x unless you defined one - the protocol function is
created by defprotocol and is not owned by the object implementing the
protocol

On Thu, Nov 21, 2019 at 3:29 PM Dimitrios Jim Piliouras
 wrote:
>
> But the call-chain is api/x-with-foo => foo/x => proto/X so it does bottom 
> out in the ns the protocol was defined in. It's just that the middle step 
> could come from 3 different namespaces all containing protocol extensions.
>
> On Thu, 21 Nov 2019, 23:03 Justin Smith,  wrote:
>>
>> it might be helpful to consider that in the jvm methods are not data,
>> and the proto function makes the method into concrete data belongs to
>> the namespace that owns the protocol
>>
>> On Thu, Nov 21, 2019 at 2:58 PM Justin Smith  wrote:
>> >
>> > if you define proto method x, it belongs to the protocol namespace no
>> > matter where it is called, and calling it as if it belonged to the
>> > namespace defining the object extending the protocol will and should
>> > fail
>> >
>> > On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
>> >  wrote:
>> > >
>> > > Hi folks,
>> > >
>> > > This has me completely stumped - I would massively appreciate a helping 
>> > > hand! Suppose the following simple directory structure:
>> > >
>> > >
>> > > — someProject.impl.{foo.clj, bar.clj,baz.clj}
>> > > — someProject.proto.clj
>> > > — someProject.api.clj
>> > >
>> > > `proto.clj` contains a single protocol with two methods - let’s call 
>> > > them X & Y. Each implementation namespace (foo, bar, baz), requires 
>> > > `[someProject.proto :as proto]`,  extends it to 3 types 
>> > > (bytes/chars/String), and defines two public fns x & y which delegate to 
>> > > `proto/X` & `proto/Y` respectively. Everything is good so far. I can 
>> > > fire up a REPL, load any of the impl  namespaces (foo, bar, baz), call 
>> > > the corresponding x or y fn and get the right result.
>> > >
>> > > Now, I want to provide a unified API so that the caller doesn’t need to 
>> > > (potentially) require 3 namespaces. Hence the `someProject.api` ns, 
>> > > which contains require clauses for all impl namespaces + two 
>> > > multi-methods `X-with` & `Y-with` with 3 implementations (`defmethod`) 
>> > > each. Each implementation delegates to the x or y fn in the right impl 
>> > > namespace. In other words,  `X-with :foo` calls `(foo/x)`, `X-with :bar` 
>> > > calls `(bar/x)` etc etc. Remember, that calling x or y inside any impl 
>> > > namespace works correctly, so all I’m doing here is providing a 
>> > > multi-method wrapper. However, things don’t work as I was expecting in 
>> > > this namespace…Loading `someProject.api` in a fresh REPL and calling  
>> > > `X-with :foo` bottoms out at the protocol extension for X in the baz ns, 
>> > > which is the last require clause in the api namespace.
>> > >
>> > > So basically,  the protocol extensions in each impl namespace work fine 
>> > > when called from their wrapper fn in the namespace they were defined, 
>> > > but don’t quite work when the same wrapper fn is called from some other 
>> > > namespace! What am I missing? :(
>> > >
>> > > Many thanks in advance…
>> > > Dimitris
>> > >
>> > >
>> > > --
>> > > 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.
>> > > To view this discussion on the web visit 
>> > > https://groups.google.com/d/msgid/clojure/A549FB15-0B12-4E20-9D98-4F5A56330DC4%40gmail.com.
>>
>> --
>> You received this message because you are subscribed to

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

[Justin Smith]

on rereading I've clearly misunderstood you, I think we need to see
actual code reproducing this error in order to know what failed here

On Thu, Nov 21, 2019 at 3:42 PM Justin Smith  wrote:
>
> there is no foo/x unless you defined one - the protocol function is
> created by defprotocol and is not owned by the object implementing the
> protocol
>
> On Thu, Nov 21, 2019 at 3:29 PM Dimitrios Jim Piliouras
>  wrote:
> >
> > But the call-chain is api/x-with-foo => foo/x => proto/X so it does bottom 
> > out in the ns the protocol was defined in. It's just that the middle step 
> > could come from 3 different namespaces all containing protocol extensions.
> >
> > On Thu, 21 Nov 2019, 23:03 Justin Smith,  wrote:
> >>
> >> it might be helpful to consider that in the jvm methods are not data,
> >> and the proto function makes the method into concrete data belongs to
> >> the namespace that owns the protocol
> >>
> >> On Thu, Nov 21, 2019 at 2:58 PM Justin Smith  wrote:
> >> >
> >> > if you define proto method x, it belongs to the protocol namespace no
> >> > matter where it is called, and calling it as if it belonged to the
> >> > namespace defining the object extending the protocol will and should
> >> > fail
> >> >
> >> > On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
> >> >  wrote:
> >> > >
> >> > > Hi folks,
> >> > >
> >> > > This has me completely stumped - I would massively appreciate a 
> >> > > helping hand! Suppose the following simple directory structure:
> >> > >
> >> > >
> >> > > — someProject.impl.{foo.clj, bar.clj,baz.clj}
> >> > > — someProject.proto.clj
> >> > > — someProject.api.clj
> >> > >
> >> > > `proto.clj` contains a single protocol with two methods - let’s call 
> >> > > them X & Y. Each implementation namespace (foo, bar, baz), requires 
> >> > > `[someProject.proto :as proto]`,  extends it to 3 types 
> >> > > (bytes/chars/String), and defines two public fns x & y which delegate 
> >> > > to `proto/X` & `proto/Y` respectively. Everything is good so far. I 
> >> > > can fire up a REPL, load any of the impl  namespaces (foo, bar, baz), 
> >> > > call the corresponding x or y fn and get the right result.
> >> > >
> >> > > Now, I want to provide a unified API so that the caller doesn’t need 
> >> > > to (potentially) require 3 namespaces. Hence the `someProject.api` ns, 
> >> > > which contains require clauses for all impl namespaces + two 
> >> > > multi-methods `X-with` & `Y-with` with 3 implementations (`defmethod`) 
> >> > > each. Each implementation delegates to the x or y fn in the right impl 
> >> > > namespace. In other words,  `X-with :foo` calls `(foo/x)`, `X-with 
> >> > > :bar` calls `(bar/x)` etc etc. Remember, that calling x or y inside 
> >> > > any impl namespace works correctly, so all I’m doing here is providing 
> >> > > a multi-method wrapper. However, things don’t work as I was expecting 
> >> > > in this namespace…Loading `someProject.api` in a fresh REPL and 
> >> > > calling  `X-with :foo` bottoms out at the protocol extension for X in 
> >> > > the baz ns, which is the last require clause in the api namespace.
> >> > >
> >> > > So basically,  the protocol extensions in each impl namespace work 
> >> > > fine when called from their wrapper fn in the namespace they were 
> >> > > defined, but don’t quite work when the same wrapper fn is called from 
> >> > > some other namespace! What am I missing? :(
> >> > >
> >> > > Many thanks in advance…
> >> > > Dimitris
> >> > >
> >> > >
> >> > > --
> >> > > 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/

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

[Justin Smith]

if I'm not mistaken, the usage of apply in the api ns ensures that the
method will only be found if "opts" is exactly one opt, otherwise the
arity won't be found and that will be reported as no such method

On Fri, Nov 22, 2019 at 12:37 AM Dimitrios Jim Piliouras
 wrote:
>
> Ok, here is the protocol definition:
> https://github.com/jimpil/cryptohash-clj/blob/master/src/cryptohash_clj/proto.clj
>
> Here are the implementations (notice the two public fns at the end of each 
> file):
> https://github.com/jimpil/cryptohash-clj/tree/master/src/cryptohash_clj/impl
>
> And here is the api with the two multi-methods:
> https://github.com/jimpil/cryptohash-clj/blob/master/src/cryptohash_clj/api.clj
>
> Everything works as expected inside the impl namespaces, but not in the api 
> namespace, even though all it does is to delegate to some impl ns.
>
> Thanks again...
>
> Kind regards,
> Dimitris
>
> ps: this repo is WIP
>
>
> On 21 Nov 2019, at 23:43, Justin Smith  wrote:
>
> on rereading I've clearly misunderstood you, I think we need to see
> actual code reproducing this error in order to know what failed here
>
> On Thu, Nov 21, 2019 at 3:42 PM Justin Smith  wrote:
>
>
> there is no foo/x unless you defined one - the protocol function is
> created by defprotocol and is not owned by the object implementing the
> protocol
>
> On Thu, Nov 21, 2019 at 3:29 PM Dimitrios Jim Piliouras
>  wrote:
>
>
> But the call-chain is api/x-with-foo => foo/x => proto/X so it does bottom 
> out in the ns the protocol was defined in. It's just that the middle step 
> could come from 3 different namespaces all containing protocol extensions.
>
> On Thu, 21 Nov 2019, 23:03 Justin Smith,  wrote:
>
>
> it might be helpful to consider that in the jvm methods are not data,
> and the proto function makes the method into concrete data belongs to
> the namespace that owns the protocol
>
> On Thu, Nov 21, 2019 at 2:58 PM Justin Smith  wrote:
>
>
> if you define proto method x, it belongs to the protocol namespace no
> matter where it is called, and calling it as if it belonged to the
> namespace defining the object extending the protocol will and should
> fail
>
> On Thu, Nov 21, 2019 at 1:57 PM Dimitrios Jim Piliouras
>  wrote:
>
>
> Hi folks,
>
> This has me completely stumped - I would massively appreciate a helping hand! 
> Suppose the following simple directory structure:
>
>
> — someProject.impl.{foo.clj, bar.clj,baz.clj}
> — someProject.proto.clj
> — someProject.api.clj
>
> `proto.clj` contains a single protocol with two methods - let’s call them X & 
> Y. Each implementation namespace (foo, bar, baz), requires 
> `[someProject.proto :as proto]`,  extends it to 3 types (bytes/chars/String), 
> and defines two public fns x & y which delegate to `proto/X` & `proto/Y` 
> respectively. Everything is good so far. I can fire up a REPL, load any of 
> the impl  namespaces (foo, bar, baz), call the corresponding x or y fn and 
> get the right result.
>
> Now, I want to provide a unified API so that the caller doesn’t need to 
> (potentially) require 3 namespaces. Hence the `someProject.api` ns, which 
> contains require clauses for all impl namespaces + two multi-methods `X-with` 
> & `Y-with` with 3 implementations (`defmethod`) each. Each implementation 
> delegates to the x or y fn in the right impl namespace. In other words,  
> `X-with :foo` calls `(foo/x)`, `X-with :bar` calls `(bar/x)` etc etc. 
> Remember, that calling x or y inside any impl namespace works correctly, so 
> all I’m doing here is providing a multi-method wrapper. However, things don’t 
> work as I was expecting in this namespace…Loading `someProject.api` in a 
> fresh REPL and calling  `X-with :foo` bottoms out at the protocol extension 
> for X in the baz ns, which is the last require clause in the api namespace.
>
> So basically,  the protocol extensions in each impl namespace work fine when 
> called from their wrapper fn in the namespace they were defined, but don’t 
> quite work when the same wrapper fn is called from some other namespace! What 
> am I missing? :(
>
> Many thanks in advance…
> Dimitris
>
>
> --
> 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

Re: Conceptual difference between map and class

[Justin Smith]

I think it's also important here that Clojure methods are actual Java
methods - Clojure likes to stay close to the host functionality. A map
with a function isn't a class with a method because the JVM bytecode
doesn't let you invoke it that way directly. A Clojure function is not
a method because methods are not first class, it's an Object with a
static .invoke method (and some other details that are less important
here).

This object as hash with functions model is useful for learning (and
there's a lot of scheme and common lisp code that actually works this
way). With some effort, you can do everything with a function in a map
that you can with an object with a method if you are careful to
provide the object of the first arg.

But it's normal in Clojure to use the built in affordances. For real
code, defrecord gives you a new class that operates in a way similar
to this but with lower friction to the underlying bytecode (it
implements actual methods but also acts like a hash map for its
fields). Protocols let you use a hash map for extension (they act like
interfaces for classes, but you can add new implementations
dynamically, letting you do what you would do by adding a function
under a key on a hash, but tracking it on the protocol side).

On Tue, Mar 31, 2020 at 7:39 AM Jason Felice  wrote:
>
> A subtle difference between a map of functions and a Python class is that the 
> class has implicit "self" or "this".  Otherwise, these are semantically the 
> same.  Well, ignoring that Clojure maps are immutable.
>
> In fact, C++ compilers compile methods by inserting a first "this" argument 
> and mangling the name.  Virtual methods (ones which can be overridden) are 
> collected into what is effectively a map attached to the instance.
>
> On Tue, Mar 31, 2020 at 4:41 AM Dieter Van Eessen 
>  wrote:
>>
>> Hello,
>>
>> I've got a clojure and a python piece of code. Both seem to create what can 
>> be considered an instance of a class. Wherein lies the conceptual difference?
>>
>> Python:
>> class MYCLASS():
>> def __init__(self, x):
>>   self.x = x
>> def MYMETHOD(self):
>>  ...
>>
>> def MYFUNCTION():
>> lol = MYCLASS()
>>
>> Clojure:
>> (defn MYCLASS [x]
>>  {:x [x]
>>   :MYMETHOD (fn [] (MYCLASS ...))})
>>
>> (let [lol (MYCLASS ...)])
>>
>> I know its not valid code, but I hope you see what I'm aiming at: isn't 
>> using a map with functions in it just the same as a class?
>> Or is only the user interface of the language conceptually equal, while the 
>> underlying plumbing is completely different?
>> If this is the case, wherein lies the major differences?
>>
>> If one could simply point me in the right direction, I'd already be very 
>> pleased. Most literature I've read so far only explains clojure can be used 
>> this way, but never focuses deeper on the subject.
>>
>> kind regards,
>> Dieter
>>
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/clojure/49cd26ca-48ae-48b4-a5ab-b0f7c711b77e%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clojure/CAB6_SoYCTeKi2teO%3DbgyEB-Vu3C-fCGpX6T%3DXZB8ApmDP-c8vA%40mail.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
--- 
You received this message because you are subs

Re: The following behavior of into function is a bug or the intended result?

[Justin Smith]

PersistentArrayMap is automatically promoted to PersistentHashMap when it 
reaches a specific size. This is done for performance reasons. Neither 
collection is considered ordered, and you should use a different datatype 
if you want ordered data.

On Sunday, August 9, 2015 at 6:31:20 PM UTC-7, Philos Kim wrote:
>
> This works well as expected. The order of input elements is maintained.
>
> (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 
> :h]])
> ; => {1 :a, 2 :b, 3 :c, 4 :d, 5 :e, 6 :f, 7 :g, 8 :h}
>
> However, as soon as the number of the input elements exceeds 9, the order 
> is not maintained any more.
>
> (into (array-map) [[1 :a] [2 :b] [3 :c] [4 :d] [5 :e] [6 :f] [7 :g] [8 :h] 
> [9 :i]])
> ; => {7 :g, 1 :a, 4 :d, 6 :f, 3 :c, 2 :b, 9 :i, 5 :e, 8 :h}
>
> Is this a bug or the intended result?
>

-- 
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: Interop with strange java type: java.lang.String<>

[Justin Smith]

I suspect this is it. Also, remember that internally a varargs string 
method will take an Array of String as its last arg.

On Thursday, August 20, 2015 at 9:35:19 AM UTC-7, squeegee wrote:
>
>
> On Aug 20, 2015, at 3:32 AM, Andy Dwelly > 
> wrote:
>
> Does anyone know how how to create a java.lang.String<> ? Ideally how to 
> convert a Clojure "some string" which is a java.lang.String to a 
> java.lang.String<>.
> Also, although this is merely idle curiosity on my part, does anyone know 
> what a java.lang.String<> actually is? The <> suggests a generic, but 
> java.lang.String is not a container - although the <> is empty of course.
>
>
> I don’t have a complete answer, but maybe these references will help:
>
> I recall seeing a <> in this post:
>
> http://tech.puredanger.com/2011/08/12/subclassing-in-clojure/
>
> and I see it mentioned here:
>
>
> http://dishevelled.net/Tricky-uses-of-Clojure-gen-class-and-AOT-compilation.html
>
> Maybe that argument is an array of Object where the objects are Strings. 
> In other contexts I have seen the class name for an array of Strings 
> displayed as “class [Ljava.lang.String”, but perhaps it’s printed 
> differently by this reflection API.
>
> —Steve
>
>

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

Re: STM and persistent data structures performance on mutli-core archs

[Justin Smith]

One could quantify this with Category Theory. In order to map from one 
domain to another reversibly, the target domain must have at least as many 
elements as the source domain, if not more. An abstraction which simplifies 
by reducing the number of elements in play is guaranteed to be "leaky".

Of course there could be abstractions that work not by reducing elements 
but organizing them so they map more efficiently to human thinking. 
Information theory also has tools that help us quantify when some relation 
or structure is lost in a translation from a domain to its abstraction.

On Tuesday, March 18, 2014 2:23:46 PM UTC-7, François Rey wrote:
>
>  On 18/03/14 18:03, Martin Thompson wrote:
>  
> Our use of language in the technology industry could, for sure, be better. 
> Take simple examples like RAM where random should be "arbitrary", or don't 
> get me started on people who misuse the term "agnostic" ;-)
>
> I would even say our use of abstractions in the tech industry could be 
> better, most notably because of the law of leaky 
> abstractions: 
> how abstractions such as RAM, GC, persistent data structure, etc. always 
> have a limit at which the things they're supposed to abstract come back 
> right in your face and you end up needing to be aware of the abstracted 
> things. I think mechanical sympathy is all about dealing with leaky 
> abstractions. The art of knowing and playing with the limits of our 
> abstractions is what Rich Hickey would call knowing the trade-offs. 
>
> I don't think the law of leaky abstraction has any formal underpinning, 
> but using the concept of trade-off it's about what we gain from using an 
> abstraction, which we often know very well because that's the whole point 
> of using it, and what we loose, which is often the forgotten and darker 
> side. In those terms an abstraction without leakiness is one that does not 
> loose anything, whether in terms of information or capability. Know of any? 
> Isn't the whole point of an abstraction to be hiding certain underlying 
> aspects, therefore loosing seems to be part of the deal, meaning 
> abstractions are leaky by nature? I think they are, but don't ask me for a 
> proof.
>
> The thing is that our industry is based on layers upon layers of 
> abstractions, whether at the physical level (integrated circuits, 
> interfaces, etc.) or at the software level: binary (1GL) abstracted into 
> assembly (2GL), then C language (3GL), etc. Virtual machines is now another 
> level of abstraction which is probably here to stay, at least in terms of 
> flexibility offered. So perhaps a key question is how many levels of 
> abstraction can we afford before the whole thing becomes too difficult to 
> manage. If think we even have situations where leakiness at one level makes 
> another level even more leaky, at which point one needs to reconsider the 
> whole stack of abstractions, perhaps from hardware up to programming 
> language and runtime, and check for the soundness of the trade-offs made at 
> each level, and then provide more than one choice.
>
> So in the end it's all about knowing the trade-off we make at each level 
> of the stack we use. I don't think many of us do, this is becoming more and 
> more obvious as the stack becomes higher and higher. We don't have to be a 
> mechanic to drive a car. But it helps to know what we can expect from it, 
> so we can better choose other modes of transportation when for example we 
> need to travel 1000 km or miles in 4 hours, or travel with 10+ people, or 
> travel where there's no road. End-users of computer programs don't have to 
> know the mechanics. But programmers do if they want to excel at their 
> trade. I don't think we can avoid this: space and time are inescapable 
> dimensions of our material reality and there will always be trade-offs 
> around them.
>  

-- 
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: Idiomatic Clojure for iterating all items of a map

[Justin Smith]

That doseq is a no-op, because str has no side effects and doseq always 
returns nil. Also there is no need to nest doseq calls. for is much like 
doseq except it actually returns the result.

user> (for [lang (:langs langs)
k (keys lang)]
   (str k "  " (k lang)))
(":lang  Clojure" ":version  1.6" ":lang  Erlang" ":version  17")


On Monday, April 21, 2014 8:32:51 AM UTC-7, Hussein B. wrote:
>
> Hi,
>
> For a data structure such as:
>
> (def langs {:langs [ {:lang "Clojure" :version 1.6}
> {:lang "Erlang"  :version 17} ] } )
>
> How to iterate all the items of the maps?
>
> I tried this but it is too imperative to me:
>
> (doseq [lang (:langs langs)
>   (doseq [k (keys lang)]
> (str k "  " (k lang
>
> 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: Idiomatic Clojure for iterating all items of a map

[Justin Smith]

small correction: sometimes one does need to nest a for or doseq call, but 
not for the usual nested iteration case

On Monday, April 21, 2014 8:57:49 AM UTC-7, Justin Smith wrote:
>
> That doseq is a no-op, because str has no side effects and doseq always 
> returns nil. Also there is no need to nest doseq calls. for is much like 
> doseq except it actually returns the result.
>
> user> (for [lang (:langs langs)
> k (keys lang)]
>(str k "  " (k lang)))
> (":lang  Clojure" ":version  1.6" ":lang  Erlang" ":version  17")
>
>
> On Monday, April 21, 2014 8:32:51 AM UTC-7, Hussein B. wrote:
>>
>> Hi,
>>
>> For a data structure such as:
>>
>> (def langs {:langs [ {:lang "Clojure" :version 1.6}
>> {:lang "Erlang"  :version 17} ] } )
>>
>> How to iterate all the items of the maps?
>>
>> I tried this but it is too imperative to me:
>>
>> (doseq [lang (:langs langs)
>>   (doseq [k (keys lang)]
>> (str k "  " (k lang
>>
>> 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: How to interrupt execution and open a debugger/REPL?

[Justin Smith]

On Tuesday, November 12, 2013 4:21:26 AM UTC-8, Lee wrote:
>
>
> On Nov 12, 2013, at 1:58 AM, juan.facorro wrote: 
>
> > Hi Alexandru, 
> > 
> > As Andy pointed out there's the emacs+Ritz option which has quite a few 
> features, but if the main thing you want to do is inspect the locals and 
> the current stack trace, you could use a macro as the one presented in the 
> book The Joy of Clojure (Chapter 8: Macros). 
> > 
> > The macro that's presented there is called break. What it does is it 
> traps the existing locals in a Clojure map when the macro is called and 
> uses their values to eval the forms you input in the breaking repl. The 
> version in the book uses clojure.main/repl  with some options to cange the 
> prompt, the reader and the evaler. 
>
> This is exciting but is there any way to get (break) to be called when an 
> unexpected exception is raised (in the context in which it is raised)? 
>
> That would be my own #1 wish for Clojure debugging. 
>
> Also nice, and FWIW also common in Common Lisp environments from ancient 
> times, would be the ability to force a within-context call to (break) from 
> the keyboard, e.g. when your code might be stuck in an infinite loop and 
> you want to know why. 
>
>  -Lee


Here is a clojure webapp that you run and connect to another clojure 
process.

When an exception happens, the stack trace will appear in the browser, and 
you can use a repl to examine things in the context of that stack frame.

https://github.com/prismofeverything/schmetterling

it is very young, but it works, and doesn't require emacs or even any 
change to the codebase you want to debug (except you need a dt_socket 
opened and you probably want to disable hotspot or your locals may get 
optimized away, making inspection more difficult

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

Typically my first step making a caribou app is to remove the immutant 
dependency. It's pretty straightforward to take it out.

On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:
>
> This is really cool. Very easy to get up and running for first try. I have 
> a few questions on the architecture.
>
> Why Immutant instead of plain ring as the default? I think the number of 
> dependencies could be much lower with it. 
>
> I know it's only alpha.. but I'm asking this on behalf of others who might 
> be thinking the same.
> And, are there plans for NoSQL database support, like MongoDB, MapDB (
> http://www.mapdb.org/ - I just found out about it myself but this is the 
> only decent in-memory NoSQL solution other than Berkeley DB)?
>
> On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:
>>
>> Hello Clojure,
>>
>> Excited to announce today the release of Caribou!  http://let-caribou.in/
>>
>> We have been building web sites and web applications with it for over two 
>> years now and improving it every day.  Currently we have four people 
>> working on it and another ten using it to build things, so it is getting a 
>> lot of real world testing.
>>
>> It has been designed as a collection of independent libraries that could 
>> each be useful on their own, but which come together as a meaningful whole.
>>
>> We have been spending the last couple months getting it ready for a full 
>> open source release, and I am happy to say it is finally ready.  Funded and 
>> supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
>> have four projects using it in production, and several more about to be 
>> launched (as well as over a dozen internal things).
>>
>> Documentation is here:  
>> http://caribou.github.io/caribou/docs/outline.html
>>
>> Source is here:  http://github.com/caribou/caribou (use this for issues, 
>> you don't actually need the source as it is installed through a lein 
>> template).
>>
>> Some of the independently useful libraries Caribou is built on are:
>>
>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>> https://github.com/caribou/polaris
>> * Lichen -- Image resizing to and from s3 or on disk: 
>> https://github.com/caribou/lichen
>> * Schmetterling -- Debugging Clojure processes from the browser:  
>> https://github.com/prismofeverything/schmetterling
>> * Antlers -- Useful extensions to mustache templating (helpers and 
>> blocks, among other things):  https://github.com/caribou/antlers
>> * Groundhog -- Replay http requests: 
>> https://github.com/noisesmith/groundhog
>>
>> And many others.
>>
>> Basically this is an Alpha release, and I am announcing it here first in 
>> order to get as much feedback from the community as possible.  We have made 
>> it as useful as we can for our purposes and recognize that for it to 
>> improve from here, we really need as many people using it and building 
>> things with it as possible.  The documentation also needs to be put through 
>> its paces:  we need to see how well people are able to use it who know 
>> nothing about it, based only on the existing docs.
>>
>> All feedback welcome!  
>>
>> Thanks for reading!  I hope you find it useful.
>>
>

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

Re: Do web apps need Clojure?

[Justin Smith]

Hi. I'm part of the Caribou team, which started as an in-house tool (and 
continues to serve that purpose).

A few advantages of clojure in the webapp space, off the top of my head:

Clojure provides execution efficiency that Ruby or Python cannot match. 
This translates to lowered hosting costs.

The lein tool provides very clean and isolated dependency management, that 
makes setting up dev environments and deployment very straightforward.

Targeting the JVM means that each deploy can be a single jar or war file 
that you upload to the server.

The ring middleware system is a very clean way of including functionality 
in an app.

Working with immutable data structures and threadsafe bindings as a 
pervasive default does a lot for stability, and rules out many of the round 
about ways one of heisenbugs end up in the system.

On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:
>
> Hi Folks,
>
> We’re a Python / Django shop, and some folks are getting excited about 
> using Clojure for building web apps.  Certainly there are numerous 
> open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
> but I think it begs a larger question: *as a rule, do web applications 
> need the power that Clojure brings to the table?*
>
> Other folks on my team are telling me that solutions built with Python / 
> Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
> we have built, and that Clojure offers nothing new to this problem space.  
>
> So, here’s the question: *How are you are actually using Clojure, and why 
> did you choose to use it, particularly in the “web application” space? * 
>
> Thanks,
> Marcus
>
>
>
> marcus blankenship
> \\\ Partner, Problem Solver, Linear Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>  
>

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

Re: Do web apps need Clojure?

[Justin Smith]

Usually elastic beanstalk or ec2 (beanstalk is simpler and trivial to make 
scale, but less flexible so sometimes we need to fall back on using an ec2 
instance). In either case we typically a clojure war into a tomcat 
container. As long as you remember to keep your permgen large enough it is 
pretty simple.

On Wednesday, November 13, 2013 3:49:16 PM UTC-8, Marcus Blankenship wrote:
>
> Thanks, Justin.  These are great points!  I especially like the simplicity 
> of deployment.  Do you folks use Heroku, AWS, or some other hosting service?
>
>
> On Nov 13, 2013, at 3:23 PM, Justin Smith > 
> wrote:
>
> Hi. I'm part of the Caribou team, which started as an in-house tool (and 
> continues to serve that purpose).
>
> A few advantages of clojure in the webapp space, off the top of my head:
>
> Clojure provides execution efficiency that Ruby or Python cannot match. 
> This translates to lowered hosting costs.
>
> The lein tool provides very clean and isolated dependency management, that 
> makes setting up dev environments and deployment very straightforward.
>
> Targeting the JVM means that each deploy can be a single jar or war file 
> that you upload to the server.
>
> The ring middleware system is a very clean way of including functionality 
> in an app.
>
> Working with immutable data structures and threadsafe bindings as a 
> pervasive default does a lot for stability, and rules out many of the round 
> about ways one of heisenbugs end up in the system.
>
> On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:
>>
>> Hi Folks,
>>
>> We’re a Python / Django shop, and some folks are getting excited about 
>> using Clojure for building web apps.  Certainly there are numerous 
>> open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
>> but I think it begs a larger question: *as a rule, do web applications 
>> need the power that Clojure brings to the table?*
>>
>> Other folks on my team are telling me that solutions built with Python / 
>> Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
>> we have built, and that Clojure offers nothing new to this problem space.  
>>
>> So, here’s the question: *How are you are actually using Clojure, and 
>> why did you choose to use it, particularly in the “web application” space? *
>>  
>>
>> Thanks,
>> Marcus
>>
>>
>>
>> marcus blankenship
>> \\\ Partner, Problem Solver, Linear Thinker
>> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>>  
>>
> -- 
> -- 
> 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/groups/opt_out.
>
>
> marcus blankenship
> \\\ Partner, Problem Solver, Linear Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>  
>

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

Re: Do web apps need Clojure?

[Justin Smith]

On Thursday, November 14, 2013 10:23:40 AM UTC-8, Stanislav Sedov wrote:
>
> 3) General lack of decent tools.  The only jvm debugger, jdb, 
> while nice, does not allow you to attach to an already running 
> process like gdb would.  Profiling tools are pretty much GUI 
> only so won't allow you to collect profiled data in an automated 
> way.
>

Both of these statements are false. 

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

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

The your own resources subdirectory is merged over the admin one, the 
structure visible here: caribou admin 
templates

And yes, anything which has the same directory structure in your project is 
merged over the admin templates (this is useful for per-project 
customization, in my experience).

The javascript and css are stashed under resources/public/_admin/, and it 
would probably be a good idea to move all the admin templates under a 
unique subdirectory as well, but it is a more complex change. I am 
seriously considering creating a templates/_admin/ and bumping all admin 
templates under that path.

On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
>
> Hi all, 
>
> I'm just toying around with Caribou.  I successfully created the models 
> of my toy app, and now I started defining routes, pages, and templates. 
> I started with this: 
>
> --8<---cut here---start->8--- 
> (def routes 
>   [["/":home 
> [["login"  :login   []) 
>
> (def pages 
>   {:home  {:GET {:controller 'home  :action 'home  :template "home.html"}} 
>:login {:GET {:controller 'login :action 'login :template 
> "login.html"}}}) 
> --8<---cut here---end--->8--- 
>
> And wow, indeed http://localhost:3/login now shows the page 
> generated by filling out the login.html template like my login action 
> said. 
>
> However, that has also broken the Admin login page.  Visiting 
> http://localhost:3/_admin/login now also shows my custom login page, 
> but the template variables aren't filled out (because that's rendered by 
> the admin controller, not my controller). 
>
> So it seems that template names have to be unique and in order not to 
> interfere with Admin templates.  Is that intended?  I guess no... 
>
> For the time being, I'll prefix my custom templates with the project 
> name in order to have them unique. 
>
> 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

Update: I have created a namespaced-templates branch of caribou-admin, and 
the fix actually looks like it will be a shallow change (if moderately 
tedious given our lack of relative partial paths in templates which gives 
me another idea...).

On Friday, November 15, 2013 6:36:30 AM UTC-8, Justin Smith wrote:
>
> The your own resources subdirectory is merged over the admin one, the 
> structure visible here: caribou admin 
> templates<https://github.com/caribou/caribou-admin/tree/master/resources/templates>
>
> And yes, anything which has the same directory structure in your project 
> is merged over the admin templates (this is useful for per-project 
> customization, in my experience).
>
> The javascript and css are stashed under resources/public/_admin/, and it 
> would probably be a good idea to move all the admin templates under a 
> unique subdirectory as well, but it is a more complex change. I am 
> seriously considering creating a templates/_admin/ and bumping all admin 
> templates under that path.
>
> On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
>>
>> Hi all, 
>>
>> I'm just toying around with Caribou.  I successfully created the models 
>> of my toy app, and now I started defining routes, pages, and templates. 
>> I started with this: 
>>
>> --8<---cut here---start->8--- 
>> (def routes 
>>   [["/":home 
>> [["login"  :login   []) 
>>
>> (def pages 
>>   {:home  {:GET {:controller 'home  :action 'home  :template 
>> "home.html"}} 
>>:login {:GET {:controller 'login :action 'login :template 
>> "login.html"}}}) 
>> --8<---cut here---end--->8--- 
>>
>> And wow, indeed http://localhost:3/login now shows the page 
>> generated by filling out the login.html template like my login action 
>> said. 
>>
>> However, that has also broken the Admin login page.  Visiting 
>> http://localhost:3/_admin/login now also shows my custom login page, 
>> but the template variables aren't filled out (because that's rendered by 
>> the admin controller, not my controller). 
>>
>> So it seems that template names have to be unique and in order not to 
>> interfere with Admin templates.  Is that intended?  I guess no... 
>>
>> For the time being, I'll prefix my custom templates with the project 
>> name in order to have them unique. 
>>
>> 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

Yes, I've made significant progress in moving the templates, but a few of 
the field editing partials are not accounted for yet. Right now most of the 
admin works in the new branch, but a few of the field editors have some 
errors introduced. You are welcome to check out the namespaced-templates 
branch of the caribou-admin 
project<https://github.com/caribou/caribou-admin/tree/namespaced-templates>if 
you would like to help and submit a pull request.

On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote:
>
> Justin Smith > writes: 
>
> Hi Justin, 
>
> > The your own resources subdirectory is merged over the admin one, the 
> > structure visible here: caribou admin 
> > templates<
> https://github.com/caribou/caribou-admin/tree/master/resources/templates> 
>
> Ok, thanks for the clarification.  At least login and logout seem like 
> very likely names to be picked by users, too. 
>
> > Update: I have created a namespaced-templates branch of caribou-admin, 
> > and the fix actually looks like it will be a shallow change (if 
> > moderately tedious given our lack of relative partial paths in 
> > templates which gives me another idea...). 
>
> That looks like a good change to me.  If I'm right, I can still override 
> admin templates by creating a _admin/login.html for example, right? 
>
> 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Caribou: custom templates shadow _admin templates

[Justin Smith]

And yes, you could still customize by overriding the templates in their new 
path (which all being under _admin would not reasonably conflict with an 
app that intends to use the admin).

On Friday, November 15, 2013 10:20:25 AM UTC-8, Justin Smith wrote:
>
> Yes, I've made significant progress in moving the templates, but a few of 
> the field editing partials are not accounted for yet. Right now most of the 
> admin works in the new branch, but a few of the field editors have some 
> errors introduced. You are welcome to check out the namespaced-templates 
> branch of the caribou-admin 
> project<https://github.com/caribou/caribou-admin/tree/namespaced-templates>if 
> you would like to help and submit a pull request.
>
> On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote:
>>
>> Justin Smith  writes: 
>>
>> Hi Justin, 
>>
>> > The your own resources subdirectory is merged over the admin one, the 
>> > structure visible here: caribou admin 
>> > templates<
>> https://github.com/caribou/caribou-admin/tree/master/resources/templates> 
>>
>>
>> Ok, thanks for the clarification.  At least login and logout seem like 
>> very likely names to be picked by users, too. 
>>
>> > Update: I have created a namespaced-templates branch of caribou-admin, 
>> > and the fix actually looks like it will be a shallow change (if 
>> > moderately tedious given our lack of relative partial paths in 
>> > templates which gives me another idea...). 
>>
>> That looks like a good change to me.  If I'm right, I can still override 
>> admin templates by creating a _admin/login.html for example, right? 
>>
>> 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] overload-middleware 0.1.1

[Justin Smith]

I've use many services within apps that are json or xml results served over 
HTTP. This is a common way to integrate third party data or functionality 
into an app (especailly webapps or mobile apps).

On Saturday, November 16, 2013 2:49:46 PM UTC-8, Cedric Greevey wrote:
>
> On Sat, Nov 16, 2013 at 5:06 PM, James Reeves 
> 
> > wrote:
>
>> Web servers are often used to serve information to clients other than web 
>> browsers.
>>
>
> [citation needed] 
>
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

I don't know if this is what Ronen is asking for, but I have had requests 
that we serve an instance with the admin open somewhere, so people can try 
out the whole app without installing it and getting it running locally.

On Sunday, November 17, 2013 11:49:50 AM UTC-8, Ryan Spangler wrote:
>
> Ronen,
>
> No sample app yet!  The screencast goes through building an app from 
> scratch, but a larger example is a great idea.  We'll get something 
> together here in the coming weeks (we have many projects using Caribou, 
> just means pulling something abstract out of one of them).  
>
> On Saturday, November 16, 2013 6:36:50 AM UTC-8, Ronen Cohen wrote:
>>
>> This look great! Is there a sample app anywhere?
>>
>> On Wednesday, November 13, 2013 1:52:10 AM UTC+2, Ryan Spangler wrote:
>>>
>>> Hello Clojure,
>>>
>>> Excited to announce today the release of Caribou!  
>>> http://let-caribou.in/
>>>
>>> We have been building web sites and web applications with it for over 
>>> two years now and improving it every day.  Currently we have four people 
>>> working on it and another ten using it to build things, so it is getting a 
>>> lot of real world testing.
>>>
>>> It has been designed as a collection of independent libraries that could 
>>> each be useful on their own, but which come together as a meaningful whole.
>>>
>>> We have been spending the last couple months getting it ready for a full 
>>> open source release, and I am happy to say it is finally ready.  Funded and 
>>> supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
>>> have four projects using it in production, and several more about to be 
>>> launched (as well as over a dozen internal things).
>>>
>>> Documentation is here:  
>>> http://caribou.github.io/caribou/docs/outline.html
>>>
>>> Source is here:  http://github.com/caribou/caribou (use this for 
>>> issues, you don't actually need the source as it is installed through a 
>>> lein template).
>>>
>>> Some of the independently useful libraries Caribou is built on are:
>>>
>>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>>> https://github.com/caribou/polaris
>>> * Lichen -- Image resizing to and from s3 or on disk: 
>>> https://github.com/caribou/lichen
>>> * Schmetterling -- Debugging Clojure processes from the browser:  
>>> https://github.com/prismofeverything/schmetterling
>>> * Antlers -- Useful extensions to mustache templating (helpers and 
>>> blocks, among other things):  https://github.com/caribou/antlers
>>> * Groundhog -- Replay http requests: 
>>> https://github.com/noisesmith/groundhog
>>>
>>> And many others.
>>>
>>> Basically this is an Alpha release, and I am announcing it here first in 
>>> order to get as much feedback from the community as possible.  We have made 
>>> it as useful as we can for our purposes and recognize that for it to 
>>> improve from here, we really need as many people using it and building 
>>> things with it as possible.  The documentation also needs to be put through 
>>> its paces:  we need to see how well people are able to use it who know 
>>> nothing about it, based only on the existing docs.
>>>
>>> All feedback welcome!  
>>>
>>> Thanks for reading!  I hope you find it useful.
>>>
>>

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

Re: Using xlisp assoc-lists in clojure

[Justin Smith]

Typically in clojure we use hash-maps (represented literally as {}) where 
other lisps would use an alist.

Regarding reading assoc list literals, I wouldn't be surprised if someone 
had written this function already, but I doubt it is in the core language. 
I also don't think it would be hard to implement. It would probably be best 
to write a function that reads in nested xlisp alists and returns nested 
maps.

To add a key to a map in clojure (acons in xlisp) we use assoc. It is 
likely that xlisp allows multiple bindings to the same key in an alist - 
maps do not work that way and you would need something slightly more 
complex than just a map if you need that behavior.

To find a key in a map in clojure (assoc in xplisp) we use get. get is the 
function used if a map or keyword is used in the calling position.

On Sunday, November 17, 2013 11:09:56 PM UTC-8, hpw...@googlemail.com wrote:
>
> Hello,
>
> As a newbie coming from a autolisp/newLISP background I have a question 
> about using xlisp assoc-lists in clojure.
>
> I have huge databases form autolisp (from an autocad enviroment) in the 
> form of nested assoc-lists.
>
> Can I stay with that format and read them from clojure?
>
> The first would be to emulate 'setq' 
> This could be done with 'def' (with a single pair of symbol/expression)
> (By the way: Can a multiform of def be done like (defm symbol1 expression1 
> symboln expressionn) by a macro)
>
> The scond is the use of assoc-lists in clojure:
>
> Is it wise to use them in clojure for huge data-lists?
> How can I access them like I do in autolisp with it's 'assoc'.
> Finding the sublist by its first member.
> I do not see a equivalent command for lists in clojure.
> clojures assoc command is completly different.
> Can it be done with a macro?
>
>
> Regards
>
> Hans-Peter
>
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

Check out resources/config/*.clj. production.clj includes a postgres config 
that you can customize (I notice now that we should include an example 
mysql config in there too actually). Once you have a config set up and 
pointing to an empty db in the appropriate environment, you can use the 
"lein caribou migrate " step to prepare it for caribou usage.

On Monday, November 18, 2013 12:29:44 AM UTC-8, puzzler wrote:
>
> The docs say something about being ready by default to deploy to Heroku.  
> But the default H2 database won't work on Heroku, will it?  I was under the 
> impression that on Heroku, you can't use a database that just saves to the 
> local filesystem, but need to "provision" a postgresql database.  Is that 
> correct?
>
>
>

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

We only include the h2 db to lower friction for creating a project and 
trying it out - I have never used h2 in an actual production app.

On Monday, November 18, 2013 5:23:16 AM UTC-8, Justin Smith wrote:
>
> Check out resources/config/*.clj. production.clj includes a postgres 
> config that you can customize (I notice now that we should include an 
> example mysql config in there too actually). Once you have a config set up 
> and pointing to an empty db in the appropriate environment, you can use the 
> "lein caribou migrate " step to prepare it for caribou usage.
>
> On Monday, November 18, 2013 12:29:44 AM UTC-8, puzzler wrote:
>>
>> The docs say something about being ready by default to deploy to Heroku.  
>> But the default H2 database won't work on Heroku, will it?  I was under the 
>> impression that on Heroku, you can't use a database that just saves to the 
>> local filesystem, but need to "provision" a postgresql database.  Is that 
>> correct?
>>
>>
>>

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

Re: Using xlisp assoc-lists in clojure

[Justin Smith]

The issue, as far as I am concerned, is not that clojure cannot do alists 
as any traditional lisp would (it can, quite easily, as has already been 
shown).

The real question is why you would use a linked list for associative data, 
when you have an associative type with better lookup time and a convenient 
read syntax?

user> (defn alput [m k v] (update-in m [k] conj v))
#'user/alput
user> (alput {} :a 0)
{:a (0)}
user> (alput {} :a 1)
{:a (1)}
user> (defn alget [m k] (first (get m k)))
#'user/alget
user> (alget '{:a (1 0)} :a)
1
user> (defn aldissoc [m k] (update-in m [k] rest))
#'user/aldissoc
user> (aldissoc '{:a (1 0)} :a)
{:a (0)}
user> (aldissoc *1 :a)
{:a ()}

On Wednesday, November 20, 2013 9:19:58 AM UTC-8, Gary Trakhman wrote:
>
> 'Relatively bad at lists' ?
>
> I think the thing that clojure's intentionally bad at is arbitrary nested 
> mutation, so you're forced to be recursive about things and return values 
> (this is how update-in and assoc-in are implemented), but this has nothing 
> to do with data type.
>
> Clojure provides simple (maybe not easy or familiar) components for 
> manipulating data, which includes lists.
>
> We should understand the core principles and tradeoffs the language makes 
> before making judgments like this.
>
>
> On Wed, Nov 20, 2013 at 12:03 PM, >wrote:
>
>> Hello,
>>
>> Thanks for the answers and code hints.
>>
>> What a bit surprise me, is the fact that clojure is announced as 'a lisp' 
>> and is relativ poor on working with lists.
>> A long time ago I learned that 'lisp' was the agronym for 
>> 'ListProcessing'. ;-)
>> As I note, I am a longtime user of newLISP which is compared in 
>> list-processing functions a power horse.
>> But I do not want to blame the language at all, otherwise I would not be 
>> interested.
>> I still have to find the best way to get the wanted job done with minimal 
>> efforts.
>>
>> Regards
>>
>> Hans-Peter
>>
>>
>>
>>>  -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

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

Re: preferred way to dereference a ref: outside or inside dosync?

[Justin Smith]

you may want to make that (defonce generate-keys (get-key-generator))

and even better, add a "start" argument to get-key-generator so you can 
persist across restarts of the vm.

Of course in a real app the key should be serialized to a persistent, 
consistent, and shared data store.

On Friday, November 22, 2013 3:05:06 AM UTC-8, Jim foo.bar wrote:
>
>  On 22/11/13 08:18, Stefan Kamphausen wrote:
>  
> How about
>
> (defn get-key-generator []
>   (let [i (atom 0)]
> (fn [] (swap! i inc
>  
> (def generate-keys (get-key-generator))
>
>
> nice one, much better than mine :) 
>
> thanks Stefan...
>
> Jim
>  

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

[Justin Smith]

I have successfully run a fresh caribou site on Windows 8, with the latest 
default 64 bit jdk from sun. You may need to explicitly supply a -Xmx 
argument to your jvm (I don't know how predictable the default maximums 
are).

You are welcome to post issues on our github pages.

If we made a forum site, we would likely prefer eating our own dog food, 
I've got a commenting plugin for caribou on my TODO list.

On Saturday, November 23, 2013 1:09:22 AM UTC-8, Roman Yakovlev wrote:
>
> Great stuff
>
> Some suggestions and questions
> - forum is needed to disquss features and bugs. Something like 
> http://www.discourse.org/
>  would 
> be super awesome ( no google groups plz ! ) 
> - documentation with user comments, Disquss would be enough for now but it 
> would be great if it can be users driven ( if i want to add some examples 
> or some additional stuff for example) at gihub for example with users pull 
> requests.
>
> There is a problem running Caribou at windows 
>
> -> Running migrations on resources/config/development.clj
> Error occurred during initialization of VM
> Could not reserve enough space for object heap
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Subprocess failed
>
> I have enough memory and space here something else 
> On linux box(ubuntu) it runs ok..
>
> среда, 13 ноября 2013 г., 3:52:10 UTC+4 пользователь Ryan Spangler написал:
>>
>> Hello Clojure,
>>
>> Excited to announce today the release of Caribou!  
>> http://let-caribou.in/
>>
>> We have been building web sites and web applications with it for over two 
>> years now and improving it every day.  Currently we have four people 
>> working on it and another ten using it to build things, so it is getting a 
>> lot of real world testing.
>>
>> It has been designed as a collection of independent libraries that could 
>> each be useful on their own, but which come together as a meaningful whole.
>>
>> We have been spending the last couple months getting it ready for a full 
>> open source release, and I am happy to say it is finally ready.  Funded and 
>> supported by Instrument in Portland, OR:  
>> http://weareinstrument.com/
>>  We have four projects using it in production, and several more about to be 
>> launched (as well as over a dozen internal things).
>>
>> Documentation is here:  
>> http://caribou.github.io/caribou/docs/outline.html
>>
>> Source is here:  
>> http://github.com/caribou/caribou(use
>>  this for issues, you don't actually need the source as it is installed 
>> through a lein template).
>>
>> Some of the independently useful libraries Caribou is built on are:
>>
>> * Polaris -- Routing with data (not macros) and reverse routing! :  
>> https://github.com/caribou/polaris
>> * Lichen -- Image resizing to and from s3 or on disk: 
>> https://github.com/caribou/lichen
>> * Schmetterling -- Debugging Clojure processes from the browser:  
>> https://github.com/prismofeverything/schmetterling
>> * Antlers -- Useful extensions to mustache templating (helpers and 
>> blocks, among other things):  
>> https://github.com/caribou/antlers
>> * Groundhog -- Replay http requests: 
>> https://github.com/noisesmith/groundhog
>>
>> And many others.
>>
>> Basically this is an Alpha release, and I am announcing it here first in 
>> order to get as much feedback from the community as possible.  We have made 
>> it as useful as we can for our purposes and recognize that for it to 
>> improve from here, we really need as many people using it and building 
>> things with it as possible.  The documentation also needs to be put through 
>> its paces:  we need to see how well people are able to use it who know 
>> nothing about it, b

Re: .cljrc

[Justin Smith]

the leinengen project has an example project.clj
https://github.com/technomancy/leiningen/blob/master/sample.project.clj

On Wednesday, November 27, 2013 4:53:02 PM UTC-8, Dave Tenny wrote:
>
> Thanks, I seem to have accomplished what I need for now.  It was a bit 
> frustrating to figure out exactly what I could do in profiles.clj.  For 
> example, I can't find any documentation on :injections, which was key to 
> evaluating some code once I'd specified libraries as dependencies.
>
> Where are the full options of projects.clj and profiles.clj documented?  I 
> can't find it anywhere in the git tree except by way of example in the 
> sample project.clj, and the tutorial.
>
>
> On Mon, Nov 25, 2013 at 5:49 PM, dgrnbrg 
> > wrote:
>
>> Another great feature of Leiningen is the :injections key in project.clj. 
>> This lets you run arbitrary code on the Leiningen-managed JVM startup. I 
>> recommend this when using Spyscope, which is a debugging tool that only 
>> needs to be required before you can use it: 
>> https://github.com/dgrnbrg/spyscope#usage
>>
>> Using :injections is a powerful to customize the default referred vars, 
>> as well.
>>
>> On Monday, November 25, 2013 10:01:12 AM UTC-5, Moritz Ulrich wrote:
>>
>>> Leiningen profiles in ~/.lein/profiles.clj will be merged into the 
>>> current project.clj by leiningen. Also dumented in 
>>> https://github.com/technomancy/leiningen/blob/stable/doc/PROFILES.md
>>>  
>>>
>>> On Mon, Nov 25, 2013 at 3:34 PM, Dave Tenny  wrote: 
>>> > With all my attention on trying to learn things about clojure, I've 
>>> either 
>>> > missed or forgotten how do to a simple thing. 
>>> > 
>>> > As I learn clojure I'm writing a few definitions that represent tools 
>>> I like 
>>> > to use in development. 
>>> > 
>>> > What is the simplest way to have those tools present in arbitrary 
>>> clojure 
>>> > REPLs started with lein repl, emacs cider-jack-in, etc., without 
>>> putting 
>>> > them in project.clj files for every lein project I'm working on ? 
>>> > 
>>> > I just want to load some things into the user (or other default ns if 
>>> my 
>>> > hypothetical .cljrc changes it) namespace and have it happen all the 
>>> time, 
>>> > except when I'm doing release builds and such of a particular project. 
>>> > 
>>> > Suggestions? 
>>> > 
>>> > 
>>> > -- 
>>> > -- 
>>> > 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/groups/opt_out. 
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/7NWXyQsG3WU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Re: Am I missing something?

[Justin Smith]

I happen to be working on the prototype for the caribou plugin layer right 
now (which may or may not be related to what you mean by pluggable). The 
default caribou template combines a number of libs that can in many cases 
be used independently of one another. We use ring and clojure.java.jdbc so 
other things using these tools are generally compatible with a caribou. Any 
elaboration on the choices we make that seem questionable is welcome.

On Wednesday, December 4, 2013 2:53:12 AM UTC-8, James Laver wrote:
>
>
> On 4 Dec 2013, at 05:00, David Nolen > 
> wrote: 
>
> > Did you look at Caribou? It seems more like a "complete" solution - 
> http://let-caribou.in 
>
> I’ve now given this a look over. It seems insane. It makes quite a lot of 
> (IMO) questionable choices and it doesn’t seem terribly pluggable. 
>
> James

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

Re: java.jdbc not working with my jdbc driver

[Justin Smith]

Parenthesis call the thing they wrap as a function. You have getConnection 
wrapped in a redundant set of parenthesis, so the return value of 
getConnection is being called. It is not a function, but it is a 
ConnectionCustom, so you get your error.

Some hints to make clojure code more readable:

classes should be CamelCase, methods should be camelCase, functions should 
be kabob-case.

parens should be separated by a preceding item by a space - (f (g x)) - g 
and x are not args to f, (g x) is the arg to f

no line should contain only parens

On Friday, December 6, 2013 5:08:23 AM UTC-8, Avinash Dongre wrote:
>
> Hi
> I have our own jdbc driver when I am trying to use clojure java.jdbc it is 
> giving me error like below
>
> Exception in thread "main" java.lang.ClassCastException: 
> a.b.my_custom_driver cannot be cast to clojure.lang.IFn
> at clojure.gemfireXD.jdbc$createStatement.invoke(client.clj:13)
> at clojure.gemfireXD.jdbc$eval13.invoke(client.clj:18)
> at clojure.lang.Compiler.eval(Compiler.java:6619)
> at clojure.lang.Compiler.load(Compiler.java:7064)
> at clojure.lang.Compiler.loadFile(Compiler.java:7020)
> at clojure.main$load_script.invoke(main.clj:294)
> at clojure.main$script_opt.invoke(main.clj:356)
> at clojure.main$main.doInvoke(main.clj:440)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.lang.Var.invoke(Var.java:415)
> at clojure.lang.AFn.applyToHelper(AFn.java:161)
> at clojure.lang.Var.applyTo(Var.java:532)
> at clojure.main.main(main.java:37)
>
>
> When I tried following 
>
>
>
> (ns clojure.custom.jdbc
>   (:import [java.sql Connection DriverManager])
>   (:require [clojure.string :as clojure-string]))
>
> (defn getConnecton
>   [url]
>   (clojure.lang.RT/loadClassForName "custom.url.ClientDriver") 
>   (DriverManager/getConnection url))
>
> (defn createStatement
>   [db]
>   (^Statement (.createStatement db)
>   ))
>   
>
> (createStatement((getConnecton "jdbc:mydbServer://localhost:1527/")))
>
> Exception in thread "main" java.lang.ClassCastException: 
> my.custom.implementation.internal.ConnectionCustom cannot be cast to 
> clojure.lang.IFn
> at clojure.gemfireXD.jdbc$eval13.invoke(client.clj:16)
> at clojure.lang.Compiler.eval(Compiler.java:6619)
> at clojure.lang.Compiler.load(Compiler.java:7064)
> at clojure.lang.Compiler.loadFile(Compiler.java:7020)
> at clojure.main$load_script.invoke(main.clj:294)
> at clojure.main$script_opt.invoke(main.clj:356)
> at clojure.main$main.doInvoke(main.clj:440)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.lang.Var.invoke(Var.java:415)
> at clojure.lang.AFn.applyToHelper(AFn.java:161)
> at clojure.lang.Var.applyTo(Var.java:532)
> at clojure.main.main(main.java:37)
>
>
> What I am missing here.
>

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

Re: java.jdbc not working with my jdbc driver

[Justin Smith]

To add some further clarification to the style hints suggested: many of us 
read code in multiple languages, and using formatting that is idiomatic to 
the language being used helps us keep the rules straight. f(a b) is an 
algol family syntax, the lisp family has a direct equivalent of (f a b), 
when you type out (f a (g b)) in a lisp as (f a(g b)) you cause many 
readers to do a double take, because it looks like an algol family function 
invocation on a (which is not being invoked as a function in our lisp 
syntax). Similar issues with camelCase versus kabob-case - If things are 
named unconventionally I have to slow down and double check whether the 
thing in question is really a method or a function (because they follow 
very different rules). And the same with trailing parenthesis - this is 
standard idiom in algol family languages, but when included in lisp family 
code, I have to slow down and consciously read it as lisp, rather than 
automatically knowing which I am seeing based on the paren placement.

On Friday, December 6, 2013 5:30:57 AM UTC-8, Justin Smith wrote:
>
> Parenthesis call the thing they wrap as a function. You have getConnection 
> wrapped in a redundant set of parenthesis, so the return value of 
> getConnection is being called. It is not a function, but it is a 
> ConnectionCustom, so you get your error.
>
> Some hints to make clojure code more readable:
>
> classes should be CamelCase, methods should be camelCase, functions should 
> be kabob-case.
>
> parens should be separated by a preceding item by a space - (f (g x)) - g 
> and x are not args to f, (g x) is the arg to f
>
> no line should contain only parens
>
> On Friday, December 6, 2013 5:08:23 AM UTC-8, Avinash Dongre wrote:
>>
>> Hi
>> I have our own jdbc driver when I am trying to use clojure java.jdbc it 
>> is giving me error like below
>>
>> Exception in thread "main" java.lang.ClassCastException: 
>> a.b.my_custom_driver cannot be cast to clojure.lang.IFn
>> at clojure.gemfireXD.jdbc$createStatement.invoke(client.clj:13)
>> at clojure.gemfireXD.jdbc$eval13.invoke(client.clj:18)
>> at clojure.lang.Compiler.eval(Compiler.java:6619)
>> at clojure.lang.Compiler.load(Compiler.java:7064)
>> at clojure.lang.Compiler.loadFile(Compiler.java:7020)
>> at clojure.main$load_script.invoke(main.clj:294)
>> at clojure.main$script_opt.invoke(main.clj:356)
>> at clojure.main$main.doInvoke(main.clj:440)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.lang.Var.invoke(Var.java:415)
>> at clojure.lang.AFn.applyToHelper(AFn.java:161)
>> at clojure.lang.Var.applyTo(Var.java:532)
>> at clojure.main.main(main.java:37)
>>
>>
>> When I tried following 
>>
>>
>>
>> (ns clojure.custom.jdbc
>>   (:import [java.sql Connection DriverManager])
>>   (:require [clojure.string :as clojure-string]))
>>
>> (defn getConnecton
>>   [url]
>>   (clojure.lang.RT/loadClassForName "custom.url.ClientDriver") 
>>   (DriverManager/getConnection url))
>>
>> (defn createStatement
>>   [db]
>>   (^Statement (.createStatement db)
>>   ))
>>   
>>
>> (createStatement((getConnecton "jdbc:mydbServer://localhost:1527/")))
>>
>> Exception in thread "main" java.lang.ClassCastException: 
>> my.custom.implementation.internal.ConnectionCustom cannot be cast to 
>> clojure.lang.IFn
>> at clojure.gemfireXD.jdbc$eval13.invoke(client.clj:16)
>> at clojure.lang.Compiler.eval(Compiler.java:6619)
>> at clojure.lang.Compiler.load(Compiler.java:7064)
>> at clojure.lang.Compiler.loadFile(Compiler.java:7020)
>> at clojure.main$load_script.invoke(main.clj:294)
>> at clojure.main$script_opt.invoke(main.clj:356)
>> at clojure.main$main.doInvoke(main.clj:440)
>> at clojure.lang.RestFn.invoke(RestFn.java:408)
>> at clojure.lang.Var.invoke(Var.java:415)
>> at clojure.lang.AFn.applyToHelper(AFn.java:161)
>> at clojure.lang.Var.applyTo(Var.java:532)
>> at clojure.main.main(main.java:37)
>>
>>
>> What I am missing here.
>>
>

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

Re: Caribou admin page: No template by the name login.html

[Justin Smith]

This is a known issue 
with 
caribou under Windows, with a potential fix 
upcoming
.

On Saturday, December 14, 2013 8:45:01 AM UTC-8, Niels van Klaveren wrote:
>
> Could it have something to do with the caribou lein template ending up in 
> \.m2\repository\caribou\lein-template ?
>
> All other dependencies end up in my local repository, which is set in both
> .m2\settings.xml  
> and
> lein\profiles.cls  {:user (:local-repo))
>
> No idea why it's the only dependency not respecting either of those 
> settings.
>
> On Saturday, December 14, 2013 5:36:54 PM UTC+1, Niels van Klaveren wrote:
>>
>> Following the steps in the 
>> tutorial, clicking on 
>> the admin login link on the homepage of the running caribou 
>> app results in the following message:
>> No template by the name login.html
>>
>> What could be the problem ?
>>
>> Windows 7 x64, Leiningen 2.3.4 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit 
>> Server VM
>>
>

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

Re: How do I serve clojure pages with nginx

[Justin Smith]

java -jar is fine in production. Jetty, Tomcat, or Immutant will offer some 
conveniences but are not necessary. What is needed (for security reasons) 
is an nginx proxy.

On Wednesday, December 25, 2013 3:42:00 AM UTC-8, Zeynel wrote:
>
> Ok, I worked through the tutorial referenced 
> http://clojure-doc.org/articles/tutorials/basic_web_development.html#build-and-run-itand
>  I created a jar file and ran it with $ java -jar -my-webapp.jar. This 
> works. But my understanding is that this is would not work for production. 
> I need to use nginx as proxy to jetty (or immutant?). I am trying to figure 
> out the correct configuration for jetty and nginx. Each tutorial appears to 
> be different and so far I couldn't make it work.
>
> On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa wrote:
>>
>> Hi Zeynel, 
>>
>> I don't know if setting things up the way I've laid out there is such a 
>> great idea.  What I would do instead is set the port and whatnot in the 
>> jetty configuration inside of ring, assuming that's what you're using 
>> (this assumes a lot about how your app is set up, so let me know if this 
>> doesn't match your setup): 
>>
>> http://ring-clojure.github.io/ring/ring.adapter.jetty.html 
>>
>> Then, I would compile an uberjar with lein, like so: 
>>
>> $ lein uberjar 
>>
>> In your startup script, as Curtis laid out, call the jar file using 
>> something like: 
>>
>> /path/to/java -jar /path/to/uberjar 
>>
>> That will be much simpler than what I have in my tutorial...which I 
>> should really update, now that you mention it! 
>>
>> DD 
>>
>> (2013/12/19 9:28), Zeynel wrote: 
>> > I am following your tutorial, but I am stuck with Jetty configuration. 
>> > My installation does not seem to have a /contexts directory. Where is 
>> it? 
>> > 
>> > On Tuesday, December 17, 2013 9:02:19 AM UTC-4, David Della Costa 
>> wrote: 
>> > 
>> > I have not done this specifically with Nginx but I suspect you 
>> probably 
>> > want something like what I set up with Apache + Jetty: 
>> > 
>> > 
>> https://github.com/ddellacosta/Clojure-under-Jetty-and-Apache#setting-up-jetty-with-apache-httpd
>>  
>> > <
>> https://github.com/ddellacosta/Clojure-under-Jetty-and-Apache#setting-up-jetty-with-apache-httpd>
>>  
>>
>> > 
>> > 
>> > That is, set up Nginx to act as a proxy for Jetty: 
>> > 
>> > http://nginx.org/en/docs/beginners_guide.html#proxy 
>> >  
>> > 
>> > One difference with how I would do it these days (vs. what I wrote 
>> in 
>> > the piece above) is that I would probably simply push out an 
>> uberjar 
>> > with lein which I would run with Java via an init script--for 
>> example, 
>> > if using Ubuntu: 
>> > 
>> > http://upstart.ubuntu.com/cookbook/#run-a-java-application 
>> >  
>> > 
>> > So, I would imagine the basic construction would be something like: 
>> > ring 
>> > app w/jetty or http-kit, packaged as an uberjar (lein uberjar), 
>> then 
>> > set 
>> > up to run via an init script (via upstart in your case) on an 
>> > alternative port, which is proxied by Nginx as in the link above. 
>> > 
>> > Hope this helps-- 
>> > 
>> > DD 
>> > 
>> > (2013/12/17 21:44), Zeynel wrote: 
>> > > I've set up a home server with ubuntu and nginx and I can serve 
>> > static 
>> > > pages. Now I want to add clojure but I am not sure what I need to 
>> > do. I 
>> > > asked the same question in StackOverflow but for some reason it 
>> is 
>> > voted 
>> > > to be 
>> > > closed: 
>> > 
>> http://stackoverflow.com/questions/20632987/how-to-serve-clojure-pages-with-nginx
>>  
>> > <
>> http://stackoverflow.com/questions/20632987/how-to-serve-clojure-pages-with-nginx>
>>  
>>
>> > 
>> > > 
>> > > Can you please direct me to documentation where I can read about 
>> > this? 
>> > > Some issues that I don't understand are: how do I tell nginx that 
>> > I am 
>> > > using clojure? Where do I install clojure, in the server? Where 
>> do I 
>> > > create the clojure files? Thanks. 
>> > > 
>> > > -- 
>> > > -- 
>> > > 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. 
>

Re: Require namespace

[Justin Smith]

Agreed, sticking with require scales better than load-file, and require is 
actually the right way to use functionality in another ns. load-file is a 
clumsy tool and you will hit its limits quickly.

On Sunday, January 5, 2014 8:54:18 AM UTC-8, Tim Visher wrote:
>
> Hi juanghui, 
>
> If you're working out your stuff, more power to you, but I do want to 
> say that you sound quite far off the beaten path of Clojure usage, so 
> just be aware that you may be accomplishing your goal in a 
> non-standard, hard to support way. :) 
>
> On Sat, Jan 4, 2014 at 6:12 AM, jianghui > 
> wrote: 
> > Hi，Thank you so much ；） 
> > I use load-file at last and it works. 
> > 
> > 
> > 2014/1/3 Gary Trakhman > 
> >> 
> >> There's a reasonable blog post here on the matter: 
> >> 
> http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html
>  
> >> 
> >> It's a bit complicated to regurgitate it all in a mailing list response 
> >> :-). 
> >> 
> >> 
> >> On Thu, Jan 2, 2014 at 8:33 AM, > 
> wrote: 
> >>> 
> >>> 
> >>> Hi， 
> >>> 
> >>> I am a newbie of Clojure.I have some confusions of ＂how to require a 
> >>> namespace＂. 
> >>> 
> >>> 1、If I want to call a function of file B.clj  in the file A.clj，does I 
> >>> have to require the namespace of B.clj in A.clj？ 
> >>> 
> >>> 2、In the file A.clj，if I need to call the functions of all *.clj in 
> the 
> >>> special directory，how to require the namespace of *.clj dynamically？ 
> >>> 
> >>> Happy New Year！ 
> >>> Thanks in advance！ 
> >>> 
> >>> -- 
> >>> -- 
> >>> 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/groups/opt_out. 
> >> 
> >> 
> >> -- 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to 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/groups/opt_out. 
> > 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to 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/groups/opt_out. 
>

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

Re: order of returned values from keys and vals

[Justin Smith]

Realistically, how many situations are there where running keys and vals 
independently is preferable to running seq once and using the two element 
vectors that returns?

Usually this way one can avoid walking the whole thing twice.

(into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of 
the idiom I usually use. As a bonus, into uses transients, which can create 
the resulting structure in fewer cycles / less time.

On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>
> Looks like Rich just chimed in with:
>
> "keys order == vals order == seq order "
>
>   Matching Socks 
>  January 31, 2014 7:31 PM
> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
> consistency not mentioned in docstring" was declined, with the comment "The 
> absence of this property in the docs is correct. You should not rely on 
> this."
>
>
>
> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
> -- 
> 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/groups/opt_out.
>  
>
> -- 
> Sam Ritchie (@sritchie)
> Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>  

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

Re: order of returned values from keys and vals

[Justin Smith]

user> (class (keys {:a 0 :b 1}))
clojure.lang.APersistentMap$KeySeq

Are you sure PersistentMap$KeySeq is lazy? I don't really get how a lazy 
sequence over an associative would work in Clojure (at least as clojure 
exists now).

Pardon my ignorance but if this is producing a lazy result, how is it doing 
so?
https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134

On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose Bonnaire-Sergeant 
wrote:
>
> zipmap could also potentially use transients (which would be a nice 
> addition).
>
> keys/vals are also lazy, so I would be surprised if there was any 
> performance
> difference with walking the seq "twice".
>
> Thanks,
> Ambrose
>
> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith 
> > wrote:
>
>> Realistically, how many situations are there where running keys and vals 
>> independently is preferable to running seq once and using the two element 
>> vectors that returns?
>>
>> Usually this way one can avoid walking the whole thing twice.
>>
>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative of 
>> the idiom I usually use. As a bonus, into uses transients, which can create 
>> the resulting structure in fewer cycles / less time.
>>
>>
>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>
>>> Looks like Rich just chimed in with:
>>>
>>> "keys order == vals order == seq order "
>>>
>>>   Matching Socks
>>>  January 31, 2014 7:31 PM
>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
>>> consistency not mentioned in docstring" was declined, with the comment "The 
>>> absence of this property in the docs is correct. You should not rely on 
>>> this."
>>>
>>>
>>>
>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>> -- 
>>> 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/groups/opt_out.
>>>  
>>>
>>> -- 
>>> Sam Ritchie (@sritchie)
>>>  Paddleguru Co-Founder
>>> 703.863.8561
>>> www.paddleguru.com
>>> Twitter <http://twitter.com/paddleguru> // 
>>> Facebook<http://facebook.com/paddleguru>
>>>  
>>  -- 
>> 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/groups/opt_out.
>>
>
>

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

Re: order of returned values from keys and vals

[Justin Smith]

Excellent, thanks for the information.

I just did a benchmark of zipmap over keys and vals vs. into {} over a map, 
and despite my intuition, they are actually nearly identical in 
performance. So if zipmap were using transients zipmap with keys and vals 
would actually be the better performing option here.

user> (def testmap (zipmap (range 1000) (range 2000 3000)))
user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
Evaluation count : 150900 in 60 samples of 2515 calls.
 Execution time mean : 401.458681 µs
Execution time std-deviation : 4.912358 µs
   Execution time lower quantile : 393.882254 µs ( 2.5%)
   Execution time upper quantile : 409.534676 µs (97.5%)
   Overhead used : 2.203076 ns

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers
nil
user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
Evaluation count : 150060 in 60 samples of 2501 calls.
 Execution time mean : 400.684810 µs
Execution time std-deviation : 3.489015 µs
   Execution time lower quantile : 395.127605 µs ( 2.5%)
   Execution time upper quantile : 407.132405 µs (97.5%)
   Overhead used : 2.203076 ns
nil


On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose Bonnaire-Sergeant 
wrote:
>
> It also might help to notice KeySeq defines first/next, but never 
> explicitly walks the seq.
>
> That's left to the user of the KeySeq.
>
> Thanks,
> Ambrose
>
>
> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk 
> 
> > wrote:
>
>> On 2 February 2014 05:14, Justin Smith > >wrote:
>>
>>> Pardon my ignorance but if this is producing a lazy result, how is it 
>>> doing so?
>>>
>>> https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
>>>
>>
>> APersistentMap's KeySeq.create and ValSeq.create are pretty much 
>> equivalent to (map key entry-seq) and (map val entry-seq). The logic 
>> producing entry-seq lives in the individual map types and is indeed lazy.
>>
>> Cheers,
>> Michał
>>  
>>
>>>
>>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
>>>> zipmap could also potentially use transients (which would be a nice 
>>>> addition).
>>>>
>>>> keys/vals are also lazy, so I would be surprised if there was any 
>>>> performance
>>>> difference with walking the seq "twice".
>>>>
>>>> Thanks,
>>>> Ambrose
>>>>
>>>>
>>>> On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith wrote:
>>>>
>>>>> Realistically, how many situations are there where running keys and 
>>>>> vals independently is preferable to running seq once and using the two 
>>>>> element vectors that returns?
>>>>>
>>>>> Usually this way one can avoid walking the whole thing twice.
>>>>>
>>>>> (into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is representative 
>>>>> of the idiom I usually use. As a bonus, into uses transients, which can 
>>>>> create the resulting structure in fewer cycles / less time.
>>>>>
>>>>>
>>>>> On Saturday, February 1, 2014 10:00:33 AM UTC-8, Sam Ritchie wrote:
>>>>>
>>>>>> Looks like Rich just chimed in with:
>>>>>>
>>>>>> "keys order == vals order == seq order "
>>>>>>
>>>>>>   Matching Socks
>>>>>>  January 31, 2014 7:31 PM
>>>>>> Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
>>>>>> consistency not mentioned in docstring" was declined, with the comment 
>>>>>> "The 
>>>>>> absence of this property in the docs is correct. You should not rely on 
>>>>>> this."
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>>>>>> -- 
>>>>>> 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.
>>>&g

Re: order of returned values from keys and vals

[Justin Smith]

In the same repl as the above benchmarks, and yes, this is definitely the 
best so far. I'll have to remember reduce-kv for future usage.

user> (crit/bench (persistent!
   (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
  (transient {})
  testmap)))
Evaluation count : 369540 in 60 samples of 6159 calls.
 Execution time mean : 163.806692 µs
Execution time std-deviation : 1.090315 µs
   Execution time lower quantile : 162.145827 µs ( 2.5%)
   Execution time upper quantile : 165.628330 µs (97.5%)
   Overhead used : 2.203076 ns
nil


On Saturday, February 1, 2014 8:34:52 PM UTC-8, Michał Marczyk wrote:
>
> Oh, sorry, for some reason Gmail didn't alert me to some of the recent 
> messages coming in while I was viewing this thread.
>
>
> On 2 February 2014 05:32, Michał Marczyk 
> > wrote:
>
>> I'd expect
>>
>> (persistent!
>>   (reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
>> (transient {})
>> input-map))
>>
>> to be the fastest solution.
>>
>> Cheers,
>> Michał
>>
>>
>> On 2 February 2014 05:30, Justin Smith > >wrote:
>>
>>> Excellent, thanks for the information.
>>>
>>> I just did a benchmark of zipmap over keys and vals vs. into {} over a 
>>> map, and despite my intuition, they are actually nearly identical in 
>>> performance. So if zipmap were using transients zipmap with keys and vals 
>>> would actually be the better performing option here.
>>>
>>> user> (def testmap (zipmap (range 1000) (range 2000 3000)))
>>> user> (crit/bench (zipmap (keys testmap) (map inc (vals testmap
>>> Evaluation count : 150900 in 60 samples of 2515 calls.
>>>  Execution time mean : 401.458681 µs
>>> Execution time std-deviation : 4.912358 µs
>>>Execution time lower quantile : 393.882254 µs ( 2.5%)
>>>Execution time upper quantile : 409.534676 µs (97.5%)
>>>Overhead used : 2.203076 ns
>>>
>>> Found 1 outliers in 60 samples (1.6667 %)
>>> low-severe 1 (1.6667 %)
>>>  Variance from outliers : 1.6389 % Variance is slightly inflated by 
>>> outliers
>>> nil
>>> user> (crit/bench (into {} (map (fn [[k v]] [k (inc v)]) testmap)))
>>> Evaluation count : 150060 in 60 samples of 2501 calls.
>>>  Execution time mean : 400.684810 µs
>>> Execution time std-deviation : 3.489015 µs
>>>Execution time lower quantile : 395.127605 µs ( 2.5%)
>>>Execution time upper quantile : 407.132405 µs (97.5%)
>>>Overhead used : 2.203076 ns
>>> nil
>>>
>>>
>>> On Saturday, February 1, 2014 8:22:28 PM UTC-8, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
>>>> It also might help to notice KeySeq defines first/next, but never 
>>>> explicitly walks the seq.
>>>>
>>>> That's left to the user of the KeySeq.
>>>>
>>>> Thanks,
>>>> Ambrose
>>>>
>>>>
>>>> On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk 
>>>> wrote:
>>>>
>>>> On 2 February 2014 05:14, Justin Smith  wrote:
>>>>>
>>>>>> Pardon my ignorance but if this is producing a lazy result, how is it 
>>>>>> doing so?
>>>>>> https://github.com/clojure/clojure/blob/
>>>>>> dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/
>>>>>> lang/APersistentMap.java#L134
>>>>>>
>>>>>
>>>>> APersistentMap's KeySeq.create and ValSeq.create are pretty much 
>>>>> equivalent to (map key entry-seq) and (map val entry-seq). The logic 
>>>>> producing entry-seq lives in the individual map types and is indeed lazy.
>>>>>
>>>>> Cheers,
>>>>> Michał
>>>>>  
>>>>>
>>>>>>
>>>>>> On Saturday, February 1, 2014 7:54:32 PM UTC-8, Ambrose 
>>>>>> Bonnaire-Sergeant wrote:
>>>>>>
>>>>>>> zipmap could also potentially use transients (which would be a nice 
>>>>>>> addition).
>>>>>>>
>>>>>>> keys/vals are also lazy, so I would be surprised if there was any 
>>>>>>> performance
>>>>>>> difference with walking the seq "twice".
>>>>>>>
>>>>>

Re: Programming clojure second Edition

[Justin Smith]

if pred is false or nil (the two cases "when" would rule out), it would be 
an error to apply it to an argument

#{\a \b} is a literal set syntax, containing keys \a and \b. {\a \b} is a 
literal hash-map syntax, with one key \a mapped to the value \b. As far as 
index-filter is concerned, it only selects \a, since that is the only key 
you can match.

On Monday, February 3, 2014 7:57:55 AM UTC-8, Jim foo.bar wrote:
>
> a vector is a function of its indices 
> a map is a function of its keys 
> a set is a function of its elements 
>
> does this help at all? 
>
> Jim 
>
>
>
> On 03/02/14 15:29, action wrote: 
> > (defn index-filter [pred coll] 
> >   (when pred 
> > (for [[idx elt] (indexed coll) :when (pred elt)] idx))) 
> > 
> > (index-filter #{\a \b} "abcdef") 
> > -> (0 1) 
> > 
> > but I don't know why use "when pred" in the code, 
> > and why "(index-filter {\a \b} "abcdef")" doesn't work? 
> > -- 
> > 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/groups/opt_out. 
>
>

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