Re: Why does `lein new` default to clojure 1.5.1?

[Cecil Westerhof]

2014-05-05 22:08 GMT+02:00 mynomoto :

> The default lein template has clojure 1.5.1 hardcoded. It will only change
> when it's updated there.
>

​I was wondering the same also. Would it not be a good idea​ to have the
possibility to overrule this?


On Monday, May 5, 2014 4:10:38 PM UTC-3, g vim wrote:
>
> I have Clojure 1.6.0 installed so why does `lein new app myapp` default
>> to Clojure 1.5.1 inside project.clj? Even worse, `lein ancient upgrade
>> :all` doesn't return an upgrade for Clojure 1.5.1
>>
>
-- 
Cecil Westerhof

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

CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

Hello, 

I have this form

(ns forclojure.core)

  (defn secondlast [coll counter]
(let [ number 0
   counter  ( - (count coll)2)]
  (loop [coll counter]
(if (== counter number)
  (first coll)
  (recur (next coll) (+ counter 1 ))

But as soon as I try to send it to REPL I see this message: 

CompilerException java.lang.IllegalArgumentException: Mismatched argument 
count to recur, expected: 1 args, got: 2, 
compiling:(/home/roelof/clojure/forclojure/src/forclojure/core.clj:9:11) 

Roelof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-05 12:17 GMT+02:00 Magnus Therning :

> On Mon, May 5, 2014 at 10:20 AM, Cecil Westerhof 
> wrote:
> > 2014-05-05 8:21 GMT+02:00 Magnus Therning :
> >
> >> any language" ;)  However, choosing language wisely will allow you to
> >> concentrate on solving the 'real' problem at hand, and relieve you
> >> from solving unrelated problems (memory management, dealing with
> >> pointers, etc).  It will also simplify reasoning about your code.  I
> >
> >
> > That is why I do not understand that (where I live) they think you can
> only
> > be a good programmer if you only program in one language.
>
> It sounds like you have a bit of teaching to do ;)  Start with
> printing a few copies of Why FP Matters
> (http://sector0.dk/public_files/why_fp_matters.pdf) and hand them out.
>  Eric Raymond's How to Become a Hacker
> (http://www.catb.org/~esr/faqs/hacker-howto.html) is also a good read,
> pay attention to what he says about LISP:
>
> LISP is worth learning for a different reason — the profound
> enlightenment experience you will have when you finally get it. That
> experience will make you a better programmer for the rest of your
> days, even if you never actually use LISP itself a lot.
>

​I wish it was that easy.

Just an anecdote. I did not get a job because I did not know how to program
in JavaScript​. Because I am a back-ender and in the function there would
be the need to do front-end work also, they gave me a programming exercise.
It did exactly what they asked, but I could not write syntactical correct
JavaScript, because I did not terminate my lines with ';'. Pardon me, the
program runs correctly, but is at the same time syntactical incorrect? How
would that be possible?

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Cecil Westerhof]

2014-05-05 19:48 GMT+02:00 Brian Craft :

> I would never have guessed modularity as a reason to worry about security
> in fp.
>
> I worry about immutability in fp, wrt security. Security requires
> mutability in order to remove sensitive data from memory, and from app
> history. A FIPS
>

​Would forced garbage collection not take care of that?

-- 
Cecil Westerhof

-- 
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: Functional programming and security

[Magnus Therning]

On Tue, May 6, 2014 at 9:45 AM, Cecil Westerhof  wrote:
> 2014-05-05 19:48 GMT+02:00 Brian Craft :
>> I would never have guessed modularity as a reason to worry about security
>> in fp.
>>
>> I worry about immutability in fp, wrt security. Security requires
>> mutability in order to remove sensitive data from memory, and from app
>> history. A FIPS
>
> Would forced garbage collection not take care of that?

I think the combination of zeroizing destructors, weak references, and
forced garbage collection would go a long way.  Then you only need to
convince the FIPS validator/evaluator/thingie that your garbage
collector behaves well so that sensitive data is scrubbed in a timely
manner.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

-- 
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Benjamin R. Haskell]

`loop` expects a vector of binding forms (with initial values), not just a
vector of names.

(loop [coll counter]; means there is one `loop` binding named `coll`,
with the initial value of `counter`

To fix that problem directly:

(loop [collcoll  ; coll starts with an initial value of its value
outside the loop
   counter counter]  ; counter starts with an initial value of its
value outside the loop
;; rest of code here ...

Then you're left with an extra `let` (which was serving a similar purpose
to `loop` initialization?), and the whole `loop` is possibly superfluous,
because a function can be the target of a `recur`.

On Tue, May 6, 2014 at 3:25 AM, Roelof Wobben  wrote:

> Hello,
>
> I have this form
>
> (ns forclojure.core)
>
>   (defn secondlast [coll counter]
> (let [ number 0
>counter  ( - (count coll)2)]
>   (loop [coll counter]
> (if (== counter number)
>   (first coll)
>   (recur (next coll) (+ counter 1 ))
>
> But as soon as I try to send it to REPL I see this message:
>
> CompilerException java.lang.IllegalArgumentException: Mismatched argument
> count to recur, expected: 1 args, got: 2,
> compiling:(/home/roelof/clojure/forclojure/src/forclojure/core.clj:9:11)
>
> Roelof
>
>  --
> 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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

Op dinsdag 6 mei 2014 10:43:40 UTC+2 schreef Benjamin R. Haskell:
>
> `loop` expects a vector of binding forms (with initial values), not just a 
> vector of names.
>
> (loop [coll counter]; means there is one `loop` binding named `coll`, 
> with the initial value of `counter`
>
> To fix that problem directly:
>
> (loop [collcoll  ; coll starts with an initial value of its value 
> outside the loop
>counter counter]  ; counter starts with an initial value of its 
> value outside the loop
> ;; rest of code here ...
>
> Then you're left with an extra `let` (which was serving a similar purpose 
> to `loop` initialization?), and the whole `loop` is possibly superfluous, 
> because a function can be the target of a `recur`.
>
>
 oke, so I could do (loop [ coll coll counter 0]  instead of the let ?
 And what do you mean with superfluous ??

Roelof

-- 
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: Functional programming and security

[Luc Prefontaine]

Reading this thread convinced me.
I will not write any information on
any support except my brain cells
and will not share it to avoid any
leaks.

I will also forget it immediately so
no one can scrub my brain to
recover it

Going to erase everything I wrote and
learned in 
the last past 30 years right now...

Seriously, when concerns about
security reaches the garbage collector
which operates in live memory,
I wonder why we bother entering
any information in a computer...

Any security related discussion
reaches a point were sanity is left
far behind don't you agree ? :)))

What was I writing a few seconds ago ?

Luc P.

> On Tue, May 6, 2014 at 9:45 AM, Cecil Westerhof  
> wrote:
> > 2014-05-05 19:48 GMT+02:00 Brian Craft :
> >> I would never have guessed modularity as a reason to worry about security
> >> in fp.
> >>
> >> I worry about immutability in fp, wrt security. Security requires
> >> mutability in order to remove sensitive data from memory, and from app
> >> history. A FIPS
> >
> > Would forced garbage collection not take care of that?
> 
> I think the combination of zeroizing destructors, weak references, and
> forced garbage collection would go a long way.  Then you only need to
> convince the FIPS validator/evaluator/thingie that your garbage
> collector behaves well so that sensitive data is scrubbed in a timely
> manner.
> 
> /M
> 
> -- 
> Magnus Therning  OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org   jabber: mag...@therning.org
> twitter: magthe   http://therning.org/magnus
> 
> -- 
> 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.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Phillip Lord]

Gregg Reynolds  writes:
> That sounds about right to me; communication (writing) skills, mainly.  Of
> course, my degree is in the humanities, so I would say that.  Now I think
> of computation as a new addition to the classic liberal arts.
>
> I'm beginning to think that the Clojure documentation system may be
> optimal.  Not "best possible", just optimal: does what it does (meets
> programmer needs) just well enough to survive.  

I think that the counter argument to that is that many other programming
languages have a richer documentation system than Clojure, and many
programmers use them.

To be clear, Clojure's documentation system is an unstructured string,
the arglists metadata and (arguably) the private metadata.

Trivial things that I would like to be able to do that I cannot do (in a
way which will be reliably interpreted).

 - Add hyperlinks
 - Distinguish between symbols (or names of vars) and normal words.
 - Distinguish between code (examples) and normal words
 - Have access to basic "markdown" style typography.

Less trivial things that I would like to be able to do:
 - transclude documentation from secondary files, so that the developer
   of a piece of code sees a short piece of documentation, while users
   of code can see something longer.
 - expand the documentation system as I see fit; i.e. the documentation
   system should be designed to an abstraction, not an implementation.


> If it were genuinely failing us in some important way, it would be
> changed.

This is, I think, a variant of the no true Scotsman fallacy. You can
say, about any complaint about documentation system are wrong, because
if they were right, it would be changed. By definition I can produce no
counter examples.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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: JSON authentication with cemerick/friend?

[Ivan Schuetz]

Thanks. I just found out that my middlewares work, I just had to reorder 
them like this:

(def app
  (->
  (handler/api app-routes)
 (friend/authenticate {:credential-fn (partial 
creds/bcrypt-credential-fn users)
:login-url "/login"
:workflows [
(ajax-login)
]})

  (format/wrap-restful-format)

  (middleware/wrap-json-body)
  (middleware/wrap-json-params)
  (middleware/wrap-json-response)

  )
  )

Now I don't need slurp... still had to change this line in ajax-login, 
since the format using these middlewares is a bit different:

  (if-let [{:keys [username password] :as creds} (get-in 
request [:params :json-params])]

with:

  (if-let [{:keys [username password] :as creds} 
(clojure.walk/keywordize-keys(:json-params request))]






Am Dienstag, 6. Mai 2014 08:03:47 UTC+2 schrieb Erik Bakstad:
>
> We're using a custom jsonparam-extractor middleware that basically does 
> this:
>
> (update-in req [:params] assoc :json-params (read-json (slurp (:body req)) 
> true))
>
> I should probably have clarified this, sorry.
>
> Also, we're not using interactive-form so I haven't tested if the two 
> workflows work together. It shouldn't be a problem to make them work 
> together though.
>
> kl. 02:31:30 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>>
>> Sorry. I mean accepts the request map as an argument. This map doesn't 
>> contain the parameters.
>>
>>
>> Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:
>>>
>>> The snippet provided by Eric doesn't use the body... it returns a 
>>> function that accepts params as argument, but they were not being passed... 
>>> body was set instead, that's why I added slurp.
>>>
>>> So maybe there's something wrong with the 
>>>  (middleware/wrap-json-params), because it's evidently not having effect.
>>>
>>>
>>> Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:

 (middleware/wrap-json-params) slurps the body up completely - this 
 is a mutation, so you won't be able to access the body again.

   Ivan Schuetz
  May 5, 2014 3:49 PM
 Concerning the workflow with the ajax-login... for some reason the 
 middleware to set params with json body of my POST isn't working.

 As a workaround I added this to ajax-login, to parse the params:

 (checore/parse-string (slurp (:body request)) true)  



 I had also to remove the interactive-form workflow I had... now my 
 middleware looks like this:


(friend/authenticate {:credential-fn (partial 
 creds/bcrypt-credential-fn users)
 :login-url "/login"
 :workflows [
 (ajax-login)
 ]})



 I do have the middlewares supposedly responsible for setting :params 
 ... not idea why this is not being done. This is the complete block:

 (def app
   (->
   (handler/api app-routes)

   (format/wrap-restful-format)
 
   (middleware/wrap-json-body)
   (middleware/wrap-json-params)
   (middleware/wrap-json-response)

(friend/authenticate {:credential-fn (partial 
 creds/bcrypt-credential-fn users)
 :login-url "/login"
 :workflows [
 (ajax-login)
 ]})

   )
   )

 But well, it works for now.



 Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
 -- 
 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.
   Ivan Schuetz
  April 25, 2014 10:53 AM
 Also I couldn't find which library you're using for "get-headers" 
 function... or is it a self made one?

 I found a get-headers in ring-servlet...
 https://github.com/ring-clojure/ring/tree/master/ring-servlet

 Added this dependency [ring/ring-servlet "1.3.0-beta1"] didn't work

 And also in a 

Re: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

I changed everything to this :

(ns forclojure.core)
  (defn secondlast [coll]
(let [number 0 ]
  (loop [coll coll counter (- (count coll)2)]
(if (== counter number)
  (first coll)
  (recur (next coll) (+ number 1))


But now I get a loop which never ends.

Roelof


Op dinsdag 6 mei 2014 10:51:09 UTC+2 schreef Roelof Wobben:
>
>
>
> Op dinsdag 6 mei 2014 10:43:40 UTC+2 schreef Benjamin R. Haskell:
>>
>> `loop` expects a vector of binding forms (with initial values), not just 
>> a vector of names.
>>
>> (loop [coll counter]; means there is one `loop` binding named `coll`, 
>> with the initial value of `counter`
>>
>> To fix that problem directly:
>>
>> (loop [collcoll  ; coll starts with an initial value of its value 
>> outside the loop
>>counter counter]  ; counter starts with an initial value of its 
>> value outside the loop
>> ;; rest of code here ...
>>
>> Then you're left with an extra `let` (which was serving a similar purpose 
>> to `loop` initialization?), and the whole `loop` is possibly superfluous, 
>> because a function can be the target of a `recur`.
>>
>>
>  oke, so I could do (loop [ coll coll counter 0]  instead of the let ?
>  And what do you mean with superfluous ??
>
> Roelof
>
>

-- 
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[James Reeves]

Well, == should be =, but more importantly you're mixing up number and
counter.

Step through your code one bit at a time:

1. You set number to 0
2. You set counter to (count coll) - 2
3. If number and counter are not equal...
4. Recur with the next part of the list, and set the counter to (+ number 1)

See how you've got counter and number mixed up?

- James


On 6 May 2014 11:24, Roelof Wobben  wrote:

> I changed everything to this :
>
> (ns forclojure.core)
>   (defn secondlast [coll]
> (let [number 0 ]
>   (loop [coll coll counter (- (count coll)2)]
>
> (if (== counter number)
>   (first coll)
>   (recur (next coll) (+ number 1))
>
>
> But now I get a loop which never ends.
>
> Roelof
>
>
> Op dinsdag 6 mei 2014 10:51:09 UTC+2 schreef Roelof Wobben:
>
>>
>>
>> Op dinsdag 6 mei 2014 10:43:40 UTC+2 schreef Benjamin R. Haskell:
>>>
>>> `loop` expects a vector of binding forms (with initial values), not just
>>> a vector of names.
>>>
>>> (loop [coll counter]; means there is one `loop` binding named
>>> `coll`, with the initial value of `counter`
>>>
>>> To fix that problem directly:
>>>
>>> (loop [collcoll  ; coll starts with an initial value of its
>>> value outside the loop
>>>counter counter]  ; counter starts with an initial value of its
>>> value outside the loop
>>> ;; rest of code here ...
>>>
>>> Then you're left with an extra `let` (which was serving a similar
>>> purpose to `loop` initialization?), and the whole `loop` is possibly
>>> superfluous, because a function can be the target of a `recur`.
>>>
>>>
>>  oke, so I could do (loop [ coll coll counter 0]  instead of the let ?
>>  And what do you mean with superfluous ??
>>
>> Roelof
>>
>>  --
> 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: Converting sequence from sort into a list

[Dave Tenny]

In my case I was just trying to ensure a list type for a java API, though
perhaps the clojure reflection layer would have converted a non list seq to
a list to match the call, I don't know.



On Mon, May 5, 2014 at 9:01 PM, Sean Corfield  wrote:

> My question would be: why do you specifically need a list? i.e., why isn't
> a sequence good enough?
>
> Sean
>
> On May 3, 2014, at 6:30 AM, Dave Tenny  wrote:
> > After nosing around all I've come up with via clojure mechanisms is to
> use (apply list (sort ...)).
> > It seems to work well enough for lists of arbitrary size (subject to
> usual memory/size limitations of large lists).
> >
> > I also considered some native java abuse such as
> java.util.Arrays.asList(Enumeration),
> > though I didn't quickly find a way to convert the clojure.lang.ArraySeq
> from my sort() in testing to an Enumeration.
> >
> > Guess I'm set for now, I was just hoping to avoid consing a new list on
> my sort result in order to get a specific collection type.
>
>
>

-- 
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: JSON authentication with cemerick/friend?

[Erik Bakstad]

You can also pass inn options to wrap-json-body so you don't have to use 
keywordize-keys:

(def app
  (wrap-json-body handler {:keywords? true :bigdecimals? true}))


kl. 12:04:10 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>
> Thanks. I just found out that my middlewares work, I just had to reorder 
> them like this:
>
> (def app
>   (->
>   (handler/api app-routes)
>  (friend/authenticate {:credential-fn (partial 
> creds/bcrypt-credential-fn users)
> :login-url "/login"
> :workflows [
> (ajax-login)
> ]})
>
>   (format/wrap-restful-format)
> 
>   (middleware/wrap-json-body)
>   (middleware/wrap-json-params)
>   (middleware/wrap-json-response)
>
>   )
>   )
>
> Now I don't need slurp... still had to change this line in ajax-login, 
> since the format using these middlewares is a bit different:
>
>   (if-let [{:keys [username password] :as creds} (get-in 
> request [:params :json-params])]
>
> with:
>
>   (if-let [{:keys [username password] :as creds} 
> (clojure.walk/keywordize-keys(:json-params request))]
>
>
>
>
>
>
> Am Dienstag, 6. Mai 2014 08:03:47 UTC+2 schrieb Erik Bakstad:
>>
>> We're using a custom jsonparam-extractor middleware that basically does 
>> this:
>>
>> (update-in req [:params] assoc :json-params (read-json (slurp (:body 
>> req)) true))
>>
>> I should probably have clarified this, sorry.
>>
>> Also, we're not using interactive-form so I haven't tested if the two 
>> workflows work together. It shouldn't be a problem to make them work 
>> together though.
>>
>> kl. 02:31:30 UTC+2 tirsdag 6. mai 2014 skrev Ivan Schuetz følgende:
>>>
>>> Sorry. I mean accepts the request map as an argument. This map doesn't 
>>> contain the parameters.
>>>
>>>
>>> Am Dienstag, 6. Mai 2014 02:17:52 UTC+2 schrieb Ivan Schuetz:

 The snippet provided by Eric doesn't use the body... it returns a 
 function that accepts params as argument, but they were not being 
 passed... 
 body was set instead, that's why I added slurp.

 So maybe there's something wrong with the 
  (middleware/wrap-json-params), because it's evidently not having effect.


 Am Dienstag, 6. Mai 2014 01:18:54 UTC+2 schrieb Sam Ritchie:
>
> (middleware/wrap-json-params) slurps the body up completely - this 
> is a mutation, so you won't be able to access the body again.
>
>   Ivan Schuetz
>  May 5, 2014 3:49 PM
> Concerning the workflow with the ajax-login... for some reason the 
> middleware to set params with json body of my POST isn't working.
>
> As a workaround I added this to ajax-login, to parse the params:
>
> (checore/parse-string (slurp (:body request)) true)  
>
>
>
> I had also to remove the interactive-form workflow I had... now my 
> middleware looks like this:
>
>
>(friend/authenticate {:credential-fn (partial 
> creds/bcrypt-credential-fn users)
> :login-url "/login"
> :workflows [
> (ajax-login)
> ]})
>
>
>
> I do have the middlewares supposedly responsible for setting :params 
> ... not idea why this is not being done. This is the complete block:
>
> (def app
>   (->
>   (handler/api app-routes)
>
>   (format/wrap-restful-format)
> 
>   (middleware/wrap-json-body)
>   (middleware/wrap-json-params)
>   (middleware/wrap-json-response)
>
>(friend/authenticate {:credential-fn (partial 
> creds/bcrypt-credential-fn users)
> :login-url "/login"
> :workflows [
> (ajax-login)
> ]})
>
>   )
>   )
>
> But well, it works for now.
>
>
>
> Am Freitag, 25. April 2014 18:53:42 UTC+2 schrieb Ivan Schuetz:
> -- 
> 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://gr

Re: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

Op dinsdag 6 mei 2014 12:40:24 UTC+2 schreef James Reeves:
>
> Well, == should be =, but more importantly you're mixing up number and 
> counter.
>
> Step through your code one bit at a time:
>
> 1. You set number to 0
> 2. You set counter to (count coll) - 2
> 3. If number and counter are not equal...
> 4. Recur with the next part of the list, and set the counter to (+ number 
> 1)
>
> See how you've got counter and number mixed up?
>


Yep, 

So I change it to this : 

 (defn secondlast [coll]
(let [number 0 ]
  (loop [coll coll counter (- (count coll)2)]
(if (= counter number)
  (first coll)
  (recur (next coll) (+ number 1))

But when I do  (secondlast (list 1 2 3 4 5))
I still do not get a answer, 

Roelof


> - James
>
>
> On 6 May 2014 11:24, Roelof Wobben >wrote:
>
>> I changed everything to this :
>>
>> (ns forclojure.core)
>>   (defn secondlast [coll]
>> (let [number 0 ]
>>   (loop [coll coll counter (- (count coll)2)]
>>
>> (if (== counter number)
>>   (first coll)
>>   (recur (next coll) (+ number 1))
>>
>>
>> But now I get a loop which never ends.
>>
>> Roelof
>>
>>
>> Op dinsdag 6 mei 2014 10:51:09 UTC+2 schreef Roelof Wobben:
>>
>>>
>>>
>>> Op dinsdag 6 mei 2014 10:43:40 UTC+2 schreef Benjamin R. Haskell:

 `loop` expects a vector of binding forms (with initial values), not 
 just a vector of names.

 (loop [coll counter]; means there is one `loop` binding named 
 `coll`, with the initial value of `counter`

 To fix that problem directly:

 (loop [collcoll  ; coll starts with an initial value of its 
 value outside the loop
counter counter]  ; counter starts with an initial value of its 
 value outside the loop
 ;; rest of code here ...

 Then you're left with an extra `let` (which was serving a similar 
 purpose to `loop` initialization?), and the whole `loop` is possibly 
 superfluous, because a function can be the target of a `recur`.


>>>  oke, so I could do (loop [ coll coll counter 0]  instead of the let ?
>>>  And what do you mean with superfluous ??
>>>
>>> Roelof
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[James Reeves]

You've still got number and counter mixed up. Try going through the loop
you've made and writing down their values:

1. coll (list 1 2 3 4 5), number 0, counter 3
2. coll (list 2 3 4 5), number 0, counter 1
3. coll (list 3 4 5), number 0, counter 2
4. coll (list 4 5), number 0, counter 3
5. coll (list 5), number 0, counter 4
6. coll nil, number 0, counter 5
7. coll nil, number 0, counter 6
...

And from there it keeps going.

When writing software, you need to have an accurate mental model of the
program you're writing. If your program isn't doing what you expect it to,
then your mental model is broken. At that point you need to step through
the code you've written and work out exactly what it does each step.

- James


On 6 May 2014 12:03, Roelof Wobben  wrote:

>
>
> Op dinsdag 6 mei 2014 12:40:24 UTC+2 schreef James Reeves:
>
>> Well, == should be =, but more importantly you're mixing up number and
>> counter.
>>
>> Step through your code one bit at a time:
>>
>> 1. You set number to 0
>> 2. You set counter to (count coll) - 2
>> 3. If number and counter are not equal...
>> 4. Recur with the next part of the list, and set the counter to (+ number
>> 1)
>>
>> See how you've got counter and number mixed up?
>>
>
>
> Yep,
>
> So I change it to this :
>
>  (defn secondlast [coll]
> (let [number 0 ]
>   (loop [coll coll counter (- (count coll)2)]
> (if (= counter number)
>
>   (first coll)
>   (recur (next coll) (+ number 1))
>
> But when I do  (secondlast (list 1 2 3 4 5))
> I still do not get a answer,
>
> Roelof
>
>
>> - James
>>
>>
>> On 6 May 2014 11:24, Roelof Wobben  wrote:
>>
>>> I changed everything to this :
>>>
>>> (ns forclojure.core)
>>>   (defn secondlast [coll]
>>> (let [number 0 ]
>>>   (loop [coll coll counter (- (count coll)2)]
>>>
>>> (if (== counter number)
>>>   (first coll)
>>>   (recur (next coll) (+ number 1))
>>>
>>>
>>> But now I get a loop which never ends.
>>>
>>> Roelof
>>>
>>>
>>> Op dinsdag 6 mei 2014 10:51:09 UTC+2 schreef Roelof Wobben:
>>>


 Op dinsdag 6 mei 2014 10:43:40 UTC+2 schreef Benjamin R. Haskell:
>
> `loop` expects a vector of binding forms (with initial values), not
> just a vector of names.
>
> (loop [coll counter]; means there is one `loop` binding named
> `coll`, with the initial value of `counter`
>
> To fix that problem directly:
>
> (loop [collcoll  ; coll starts with an initial value of its
> value outside the loop
>counter counter]  ; counter starts with an initial value of its
> value outside the loop
> ;; rest of code here ...
>
> Then you're left with an extra `let` (which was serving a similar
> purpose to `loop` initialization?), and the whole `loop` is possibly
> superfluous, because a function can be the target of a `recur`.
>
>
  oke, so I could do (loop [ coll coll counter 0]  instead of the let ?
  And what do you mean with superfluous ??

 Roelof

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

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

Re: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

As far as I understand recur is going back to the loop  so number is never 
going back to 0 
but I see the problem (-(count coll)2 is changing it value and that schould 
not happen. 
So I think I have to set the initial value of counter in the let. 

what schould happen is this 

   collnumbercounter 
1)   [1,2,3.4.5) 0 3
2)   [2.3,4,5]1 3
3)   [3,4,5]   2 3
4) [ 4,5]   3 3

so the (first coll) is executed which is 4. 

Am I at the right track now. 



Roelof

-- 
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Roelof Wobben]

Found the answer :

(defn secondlast [coll]
(let [number 0
  counter (- (count coll)2) ]
  (loop [coll coll counter counter number number]
(if (= counter number)
  (first coll)
  (recur (next coll) counter (+ number 1))

and without the loop there will be : (first(drop(reverse v)) 

Roelof


Op dinsdag 6 mei 2014 13:36:53 UTC+2 schreef Roelof Wobben:
>
> As far as I understand recur is going back to the loop  so number is never 
> going back to 0 
> but I see the problem (-(count coll)2 is changing it value and that 
> schould not happen. 
> So I think I have to set the initial value of counter in the let. 
>
> what schould happen is this 
>
>collnumbercounter 
> 1)   [1,2,3.4.5) 0 3
> 2)   [2.3,4,5]1 3
> 3)   [3,4,5]   2 3
> 4) [ 4,5]   3 3
>
> so the (first coll) is executed which is 4. 
>
> Am I at the right track now. 
>
>
>
> Roelof
>
>

-- 
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[Gary Trakhman]

Last + butlast?

On Tuesday, May 6, 2014, Roelof Wobben  wrote:

> Found the answer :
>
> (defn secondlast [coll]
> (let [number 0
>   counter (- (count coll)2) ]
>   (loop [coll coll counter counter number number]
> (if (= counter number)
>   (first coll)
>   (recur (next coll) counter (+ number 1))
>
> and without the loop there will be : (first(drop(reverse v))
>
> Roelof
>
>
> Op dinsdag 6 mei 2014 13:36:53 UTC+2 schreef Roelof Wobben:
>>
>> As far as I understand recur is going back to the loop  so number is
>> never going back to 0
>> but I see the problem (-(count coll)2 is changing it value and that
>> schould not happen.
>> So I think I have to set the initial value of counter in the let.
>>
>> what schould happen is this
>>
>>collnumbercounter
>> 1)   [1,2,3.4.5) 0 3
>> 2)   [2.3,4,5]1 3
>> 3)   [3,4,5]   2 3
>> 4) [ 4,5]   3 3
>>
>> so the (first coll) is executed which is 4.
>>
>> Am I at the right track now.
>>
>>
>>
>> Roelof
>>
>>  --
> 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.

is there a performance test tool by clojure

[Zhi Yang]

is there a performance test tool by clojure like scala Gatling

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

Re: is there a performance test tool by clojure

[Andrey Antukh]

Hi!

https://github.com/hugoduncan/criterium  this is a good candidate.

Greetings
Andrey


2014-05-06 15:06 GMT+02:00 Zhi Yang :

> is there a performance test tool by clojure like scala Gatling
>
> --
> 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.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

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

Wrapping functions of Java interfaces with inheritance chains

[fs]

Disclaimer: I'm new to Clojure programming.

I work on some Clojure wrapper functions for a Java API that mainly 
consists of interfaces.

I wonder what the 'usual way of doing things' is regarding inheritance 
chains.

Let's say there's an interface called *Element* that has a *getId()*function. A 
second interface, called 
*SubElement,* extends *Element*. I have two clojure namespaces for these 
two interfaces: *foo.element* and *foo.sub-element*. 

In foo.element there is a wrapper for the getId() function:

(defn get-id
  [^Element element]
  (.getId element))

Now my question is regarding foo.sub-element. Should I just redefine get-id 
in there? 

(defn get-id
  [^SubElement element]
  (.getId element))

Or should I do:

(defn get-id
  [^Element element]
  (element/get-id element))

Or should I use potemkin in there?

(potemkin/import-fn element/get-id)

Or should I not re-wrap this function call and work with both namespaces 
when dealing with SubElements? 

What are the pros and cons to these different approaches? Thanks.


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

Measure HTTP response times

[emptya45]

Hi,

I am developing a primitive web load test tool using a HTTP client and STM. 

I wondered if there was a Clojure library I could use that would give me 
individual HTTP response times?

Many Thanks

Paul


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

Re: is there a performance test tool by clojure

[Zhi Yang]

thanks, this is mainly for benchmark expression, what I need is a jmeter 
like app performance tool

On Tuesday, May 6, 2014 9:06:11 PM UTC+8, Zhi Yang wrote:
>
> is there a performance test tool by clojure like scala Gatling
>

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

Re: is there a performance test tool by clojure

[François Rey]

On 06/05/14 15:32, Zhi Yang wrote:
thanks, this is mainly for benchmark expression, what I need is a 
jmeter like app performance tool

In that case:
https://github.com/ptaoussanis/timbre

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is there a performance test tool by clojure

[François Rey]

On 06/05/14 15:34, François Rey wrote:

On 06/05/14 15:32, Zhi Yang wrote:
thanks, this is mainly for benchmark expression, what I need is a 
jmeter like app performance tool

In that case:
https://github.com/ptaoussanis/timbre

Looking at what Gatling provides in scalaland I guess you may be 
interested in load testing, in which case The Grinder 
 may complete your toolbox since it 
support scenario scripting in clojure 
.


--
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: Measure HTTP response times

[François Rey]

You may want to check timbre and/or The Grinder 
, the latter being a full-featured java 
tool that supports scenario scripting in clojure 
.


--
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[James Reeves]

Yes, except there's no need to pass counter into the loop if it doesn't
change.

(And naming a constant value "counter" is a little weird).

- James


On 6 May 2014 13:07, Roelof Wobben  wrote:

> Found the answer :
>
>
> (defn secondlast [coll]
> (let [number 0
>   counter (- (count coll)2) ]
>   (loop [coll coll counter counter number number]
>
> (if (= counter number)
>   (first coll)
>   (recur (next coll) counter (+ number 1))
>
> and without the loop there will be : (first(drop(reverse v))
>
> Roelof
>
>
> Op dinsdag 6 mei 2014 13:36:53 UTC+2 schreef Roelof Wobben:
>
>> As far as I understand recur is going back to the loop  so number is
>> never going back to 0
>> but I see the problem (-(count coll)2 is changing it value and that
>> schould not happen.
>> So I think I have to set the initial value of counter in the let.
>>
>> what schould happen is this
>>
>>collnumbercounter
>> 1)   [1,2,3.4.5) 0 3
>> 2)   [2.3,4,5]1 3
>> 3)   [3,4,5]   2 3
>> 4) [ 4,5]   3 3
>>
>> so the (first coll) is executed which is 4.
>>
>> Am I at the right track now.
>>
>>
>>
>> Roelof
>>
>>

-- 
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: Functional programming and security

[Cecil Westerhof]

Seriously, when concerns about

> security reaches the garbage collector
> which operates in live memory,
> I wonder why we bother entering
> any information in a computer...
>

​On a desktop probably not an issue, but on a server that can run for a
very long time and has a lot of more hands touching it, it could be
different.



> Any security related discussion
> reaches a point were sanity is left
> far behind don't you agree ? :)))
>

​Better to paranoid as to easy going. But you need to be careful that you
do not go full blown over the top.

-- 
Cecil Westerhof

-- 
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: CompilerException java.lang.IllegalArgumentException: Mismatched argument count to recur

[James Reeves]

On 6 May 2014 13:09, Gary Trakhman  wrote:

> Last + butlast?


Yeah, there are a few more concise solutions to this problem if you're
familiar with the standard library:

  (last (butlast coll))

  (second (reverse coll))

  (peek (pop (vec coll)))

And a more efficient loop-solution would just keep the previous value
stored until the end of the loop is reached:

  (loop [prev nil, coll (seq coll)]
(if (next coll)
  (recur (first coll) (next coll)
  prev))

- James



>
>
> On Tuesday, May 6, 2014, Roelof Wobben  wrote:
>
>> Found the answer :
>>
>> (defn secondlast [coll]
>> (let [number 0
>>   counter (- (count coll)2) ]
>>   (loop [coll coll counter counter number number]
>> (if (= counter number)
>>   (first coll)
>>   (recur (next coll) counter (+ number 1))
>>
>> and without the loop there will be : (first(drop(reverse v))
>>
>> Roelof
>>
>>
>> Op dinsdag 6 mei 2014 13:36:53 UTC+2 schreef Roelof Wobben:
>>>
>>> As far as I understand recur is going back to the loop  so number is
>>> never going back to 0
>>> but I see the problem (-(count coll)2 is changing it value and that
>>> schould not happen.
>>> So I think I have to set the initial value of counter in the let.
>>>
>>> what schould happen is this
>>>
>>>collnumbercounter
>>> 1)   [1,2,3.4.5) 0 3
>>> 2)   [2.3,4,5]1 3
>>> 3)   [3,4,5]   2 3
>>> 4) [ 4,5]   3 3
>>>
>>> so the (first coll) is executed which is 4.
>>>
>>> Am I at the right track now.
>>>
>>>
>>>
>>> Roelof
>>>
>>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Tue, May 6, 2014 at 4:53 AM, Phillip Lord
wrote:

> Gregg Reynolds  writes:
> > That sounds about right to me; communication (writing) skills, mainly.
>  Of
> > course, my degree is in the humanities, so I would say that.  Now I think
> > of computation as a new addition to the classic liberal arts.
> >
> > I'm beginning to think that the Clojure documentation system may be
> > optimal.  Not "best possible", just optimal: does what it does (meets
> > programmer needs) just well enough to survive.
>
> I think that the counter argument to that is that many other programming
> languages have a richer documentation system than Clojure, and many
> programmers use them.
>
> To be clear, Clojure's documentation system is an unstructured string,
> the arglists metadata and (arguably) the private metadata.
>

I would add comment syntax.  Technically maybe not part of a doc "system",
but I have yet to meet a comment that doesn't count as documentation in
some sense.

>
> Trivial things that I would like to be able to do that I cannot do (in a
> way which will be reliably interpreted).
>
>  - Add hyperlinks
>  - Distinguish between symbols (or names of vars) and normal words.
>  - Distinguish between code (examples) and normal words
>  - Have access to basic "markdown" style typography.
>

I'm undecided on these.  They would obviously be useful, but on the other
hand minimalism has its virtues.  In the base case of reading code with a
plaintext editor, I usually find embedded doco with lots of markup annoying
and an impediment to code reading.  I think I'm inclined to favor keeping
markup out of code but I'm keeping an open mind about it.


>
> Less trivial things that I would like to be able to do:
>  - transclude documentation from secondary files, so that the developer
>of a piece of code sees a short piece of documentation, while users
>of code can see something longer.
>  - expand the documentation system as I see fit; i.e. the documentation
>system should be designed to an abstraction, not an implementation.
>

All good; but personally I would want a way to do this kind of thing
without mixing a lot of "doc system" code in with the algorithm code.

For what it's worth, I generally prefer manpages for API and language
documentation.  Very fast, with good search capabilities.  My main
complaint about the Clojure doc ecosystem is that I can't do something like
$ man clj-doseq to see docs on doseq.

At the moment I'm leaning toward DITA for heavy-duty documentation, in part
because it would allow generation of manpages.  You can see an example at
leiningen-doc  - pdf output
examples are in doc/pdf.  It's mostly an outline at the moment, but if you
look at the driver file
ugbook.ditamapand
the files in the ug directory you can get a quick idea of how it
works.  Once you get the hang of it you can quickly write doco in a
language specifically designed for tech documentation (and extend it if you
wish).

That puts me in a small (infinitesimal?) minority, I reckon, but DITA is
evolving and growing, at least among professional tech writers.  An obvious
research topic is how Clojure and DITA might be made to play nice together.

More generally:  I'm inclined to think that the "native" doc support in
Clojure ("doc features" of the language itself) should be kept to a
minimum, and fancier stuff made available as add-ons.

Related: I think we need a better language for talking about
documentation.  Just consider the many ways people discover and access
documentation of various kinds, and their various reasons and purposes.
What "documentation" ought to look like (norms of content, organization,
functionality of the discovery/access system, etc.) may be different in
each case, so we need a concise language that allows us to clearly relate
needs to uses/purposes and so forth.  But currently our language is
relatively impoverished.  "Documentation" as commonly used covers just
about everything, so it is inevitable that major disagreements will arise
from people using the term with different ideas in mind.  Addressing this
need for clear articulation is part of the idea behind
codegenres.


> > If it were genuinely failing us in some important way, it would be
> > changed.
>
> This is, I think, a variant of the no true Scotsman fallacy. You can
> say, about any complaint about documentation system are wrong, because
> if they were right, it would be changed. By definition I can produce no
> counter examples.
>

Does that mean I win?  ;)

Actually I was thinking in terms of evolution rather than definition.
Since version 1 of clojure lots of unmet needs have been identified and
then met; the language has evolved in response to genuine needs (meaning:
new stuff is actually used to do useful things).  Since that hasn't
happened much (to my knowledge) with respect

Re: Proposing a new Clojure documentation system (in Clojure)

[Mars0i]

On Tuesday, May 6, 2014 4:53:36 AM UTC-5, Phillip Lord wrote:
>
> Gregg Reynolds > writes: 
> > That sounds about right to me; communication (writing) skills, mainly. 
>  Of 
> > course, my degree is in the humanities, so I would say that.  Now I 
> think 
> > of computation as a new addition to the classic liberal arts. 
> > 
> > I'm beginning to think that the Clojure documentation system may be 
> > optimal.  Not "best possible", just optimal: does what it does (meets 
> > programmer needs) just well enough to survive.   
>
> I think that the counter argument to that is that many other programming 
> languages have a richer documentation system than Clojure, and many 
> programmers use them. 
>
> To be clear, Clojure's documentation system is an unstructured string, 
> the arglists metadata and (arguably) the private metadata. 
>
> Trivial things that I would like to be able to do that I cannot do (in a 
> way which will be reliably interpreted). 
>
>  - Add hyperlinks 
>  - Distinguish between symbols (or names of vars) and normal words. 
>  - Distinguish between code (examples) and normal words 
>  - Have access to basic "markdown" style typography. 
>
> Less trivial things that I would like to be able to do: 
>  - transclude documentation from secondary files, so that the developer 
>of a piece of code sees a short piece of documentation, while users 
>of code can see something longer. 
>  - expand the documentation system as I see fit; i.e. the documentation 
>system should be designed to an abstraction, not an implementation. 
>

To me all of this seems reasonable, especially the first group of items.  
None of the ones in the first group, at least, require immediate changes to 
existing docstrings.  In another post, Gregg Reynolds worries that 
implementing items in the first group would clutter up docstrings when read 
as raw text.  Maybe that's something to worry about, but a limited amount 
of well-known markup is easy to read raw.  Some people in recent threads 
are interested in more elaborate proposals.  That's when I start to wonder 
whether this is an attempt to replace a problem that's difficult to 
"program" (getting programmers to think in different, better ways about 
documentation) with one that's simpler (software tools or elaborate rules 
for documentation practice).

-- 
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: Wrapping functions of Java interfaces with inheritance chains

[Alex Miller]

On Tuesday, May 6, 2014 6:53:51 AM UTC-5, f...@kimchi.io wrote:
>
> Disclaimer: I'm new to Clojure programming.
>

Welcome!
 

> I work on some Clojure wrapper functions for a Java API that mainly 
> consists of interfaces.
>
> I wonder what the 'usual way of doing things' is regarding inheritance 
> chains.
>
> Let's say there's an interface called *Element* that has a *getId()*function. 
> A second interface, called 
> *SubElement,* extends *Element*. I have two clojure namespaces for these 
> two interfaces: *foo.element* and *foo.sub-element*. 
>

I suspect you probably don't actually need two namespaces for this, but it 
depends on the api and your wrapping needs.

In foo.element there is a wrapper for the getId() function:
>
> (defn get-id
>   [^Element element]
>   (.getId element))
>

ok
 

>
> Now my question is regarding foo.sub-element. Should I just redefine 
> get-id in there? 
>
> (defn get-id
>   [^SubElement element]
>   (.getId element))
>

There is no reason to do this - your prior get-id is fine. A SubElement is 
an Element and Java turns these into the same virtual call either way. 
 

>
> Or should I do:
>
> (defn get-id
>   [^Element element]
>   (element/get-id element))
>

There is no need to wrap a function like this.
 

> Or should I use potemkin in there?
>
> (potemkin/import-fn element/get-id)
>

And I definitely wouldn't go to potemkin for this.
 

> Or should I not re-wrap this function call and work with both namespaces 
> when dealing with SubElements? 
>

When you need to get the id, call the function in the element ns. If you 
need something SubElement specific, call the functions in sub-element. You 
may find that all of the functions in both ns'es could really go in Element.

You may also consider not wrapping the api directly but instead 
transforming your Java objects into Clojure data, working with it, then 
transforming it back to Java if needed. There are obvious costs with 
transformation and memory so this only sometimes makes sense, can't say 
without knowing more about the API and the usage of it. One quick-and-dirty 
tool for this is the "bean" function which takes a Java object and returns 
a Clojure map based on it's "bean" properties (get*, is*).

In general, rather than having explicit getter functions, Clojure 
information entities (as maps or records) typically use keywords as keys 
(the "fields" of the entity) and leverage the ability of keywords to invoke 
themselves on a map as a getter function. I mention this because to take 
advantage of this common pattern, you would need to do the transformation 
from Java object to Clojure map/record. Again, hard to say whether that 
makes sense for you.

 

>
> What are the pros and cons to these different approaches? Thanks.
>
>
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[Jeremy Wright]

It's been a long time, but I'm finally getting back to this idea. Starting 
from the ground up, I've written a blog post on getting Clojure up and 
running on the BeagleBone Black. In a future blog post I'll circle back 
around to this discussion, probably attempting to combine the concepts from 
Carin Meier's drone presentation with Kevin's PyBBIO Clojure port. I will 
probably leave I2C out of the mix for now.

http://innovationsts.com/?p=4779

Of course, any feedback on the blog post is appreciated.

On Thursday, September 5, 2013 9:50:06 PM UTC-4, Jeremy Wright wrote:
>
> Thanks Kevin. I guess it really doesn't have to be an either-or thing. A 
> mix of I2C and PyBBIO could be used as needed. I'm going to start by 
> experimenting a little with I2C and then go from there.
>
> On Thursday, September 5, 2013 5:05:55 AM UTC-4, red...@gmail.com wrote:
>>
>> Fiddling with the pins via the filesystem is where I started, but PyBBIO 
>> mmaps the pins so you can flip them by reading/writing directly to 
>> memory, and I "ported" that to clojure using 
>> https://github.com/hiredman/beaglebone-jni-utils and 
>> https://github.com/hiredman/blackbox/blob/master/src/blackbox/gpio.clj. 
>>
>> I have not done anything with I2C, the last thing I did was work on 
>> wiring the beaglebone to a mini arduino driving an ultrasonic range 
>> finder. I used a java library, I think was called rxtx, for reading data 
>> from the serial port. 
>>
>> On 9/4/13 2:45 PM, Jeremy Wright wrote: 
>> > Thanks for the slide deck Kevin. I'm not sure I've found all the slides 
>> > yet, but it's great information. Do you have any links or information 
>> on 
>> > Clojure robotics work you've done since the 2012 Conj? Any thoughts on 
>> > using the GPIO pins through the file system versus using I2C (or maybe 
>> SPI)? 
>> > 
>> > On Wednesday, September 4, 2013 3:59:33 PM UTC-4, red...@gmail.comwrote: 
>> >> 
>> >> I also have a vertigo inducing slide deck to go with the robot 
>> lightening 
>> >> talk (which I didn't end up using) 
>> >> http://thelibraryofcongress.s3.amazonaws.com/conj2012-robot/index.html 
>> >> 
>> >> On Sunday, September 1, 2013 8:21:46 PM UTC-7, Jeremy Wright wrote: 
>> >>> 
>> >>> Here are some updates on my own research. 
>> >>> 
>> >>>1. This post<
>> http://thelibraryofcongress.s3.amazonaws.com/beagleboneled.html>is a 
>> little over a year old, but has the type of information on the 
>> >>>BeagleBone I'm looking for. It covers doing some simple I/O using 
>> Clojure. 
>> >>>The author states that he's unsure what he's doing on the hardware 
>> side of 
>> >>>things, but it's a start. 
>> >>>2. This post<
>> http://nakkaya.com/2011/03/15/clojure-on-the-beagleboard/>says it's easy 
>> to get Clojure working on the Beagleboard, but is a couple 
>> >>>of years old and doesn't give too much detail. I do like that the 
>> author 
>> >>>does some benchmarking that could be adapted to the BeagleBone 
>> Black though. 
>> >>>3. This post<
>> http://blog.gonzih.me/blog/2012/09/07/clojure-on-beaglebone-openjdk-vs-oracle-embedded-jre-benchmark/>is
>>  
>> about a year old, and gives a benchmark comparison of OpenJDK vs 
>> >>>Oracle's Embedded JRE on a BeagleBone. 
>> >>>4. Videos of Kevin Downey (less than a year old) showing a robot 
>> >>>using Clojure on a BeagleBone. He gives some insight into how to 
>> make using 
>> >>>the Bone's I/O system in Clojure a little easier. 
>> >>>1. Video 1 of 3  
>> >>>   2. Video 2 of 3  
>> >>>   3. Video 3 of 3  
>> >>>5. Kevin Downey's Beaglebone robot code on Github<
>> https://github.com/hiredman/blackbox> 
>> >>>. 
>> >>>6. Kevin Downey mentioned clojure-jna<
>> https://github.com/Chouser/clojure-jna> which 
>> >>>should make working with native code (to do I/O) on the Bone a 
>> little 
>> >>>easier. The clojure-jna code on GitHub is about 4 years old 
>> though, and I 
>> >>>may have read something about a newer replacement on this mailing 
>> list. I 
>> >>>can't remember for sure though. 
>> >>> 
>> >>> That's what I've found so far. The information has some age on it and 
>> is 
>> >>> focused on the older BeagleBone and Beagleboard. It's good 
>> information to 
>> >>> get started with though I think. 
>> >>> 
>> >>> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote: 
>>  
>>  I recently watched Carin Meier's OSCON talk The Joy of Flying Robots 
>>  with Clojure  and it 
>> made 
>>  me wonder about Clojure on embedded systems. A quick search on this 
>> list 
>>  didn't turn up much so I thought I'd ask. How much work has been 
>> done with 
>>  Clojure on either Java friendly microcontroller systems (i.e. 
>> Systronix), 
>>  or on som

Re: Proposing a new Clojure documentation system (in Clojure)

[Mars0i]

On Tuesday, May 6, 2014 9:39:47 AM UTC-5, Gregg Reynolds wrote:
>
> For what it's worth, I generally prefer manpages for API and language 
> documentation.  Very fast, with good search capabilities.  
>

I agree, but I suspect that this is a minority view.
 

> My main complaint about the Clojure doc ecosystem is that I can't do 
> something like $ man clj-doseq to see docs on doseq.
>

I have a script named 'cloman':

#!/bin/sh
echo "(doc $1)" | clojure | less

It's slow compared to real manpages, of course, because of Clojure's slow 
startup.  

-- 
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: find the last and the nth item without using last or nth

[Roelof Wobben]

I tried this problem again.

So I did this: 

(defn nth* [coll, number]
   (let [acc 0]
   (loop [coll coll acc]
 (if == acc number))
   (first coll)
   (recur (next coll) (+acc 1 ))

but when I do : 
(nth* (1,2,3,4,5)2)) I see a cannot cast error message.

Is this because Clojure cannot figure out what the coll and what the number 
is ?

Roelof



Op woensdag 30 april 2014 12:53:01 UTC+2 schreef James Reeves:

> On 30 April 2014 11:41, Roelof Wobben >wrote:
>>
>>
>> Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves:
>>>
>>>
>>> Consider how you might add a counter to the loop. You'll want to 
>>> increment the counter, then stop when it reaches the desired number.
>>>
>>
>>
>> So without checking it so out of my head I would do this 
>>
>>  (defn last* [coll, number]
>>(loop [coll coll]
>>  (if == counter number))
>>(first coll)
>>(recur (next coll) (+counter 1 ))
>>
>
> Essentially yes. You need to initiate the counter to zero, and you still 
> need a condition to make sure you don't go past the end of the seq (in case 
> n is more than the length of the list), but you've basically got it.
>
> - James
>

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

Re: clojure.zip: skip a node

[Alex Miller]

I wrote this article long ago which hints about this at the end:
https://www.ibm.com/developerworks/library/j-treevisit/

The approach I have taken for editing trees with zippers is to do a 
post-walk from end to beginning - that way you're always done transforming 
and will not walk into your edited subtrees. The article does talk a little 
about how to separate navigation from transformation; it's not particularly 
hard. You want to start from your rightmost node, which you can get from a 
repeated application of zip/rightmost or last of zip/rights. Then 
repeatedly call prev till you reach a node without a parent at that point 
convert the loc to a node in the termination.

I can dig up actual code for this later if you're interested.

Alex


On Monday, May 5, 2014 6:01:04 PM UTC-5, Pascal Germroth wrote:
>
> Hi,
>
> I'm using clojure.zip to edit a tree by visiting each location using 
> zip/next, possibly using zip/replace to alter the tree.
> There are cases where I replace a part of the tree with another tree that 
> will/must not be visited, but I couldn't find a good way to skip nodes, 
> since
> (zip/next (zip/replace loc new-subtree)) will walk right into my new tree, 
> and I can't use (zip/right (zip/replace loc new-subtree)) as the replaced 
> location might already be the rightmost.
>
> Is there a built-in function I missed, or a zip enhancement library I 
> could use?
>
> (defn skip
>   "returns the next location that is not a child of this one"
>   [loc]
>   (if (or (z/end? loc) (nil? loc))
> loc
> (loop [loc loc]
>   (or (z/right loc)
>   (recur (z/up loc))
>
> I came up with this replacement, does that seem like a good idea, or am I 
> using zip completely wrong (because what I really would like to do is 
> iterate backwards through the tree, starting at the end, using zip/prev; 
> but there's also no function to just jump to the end as far as I can tell)
>
>
> Cheers,
>
> -- 
> pascal
>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Phillip Lord]

Gregg Reynolds  writes:
>> I think that the counter argument to that is that many other programming
>> languages have a richer documentation system than Clojure, and many
>> programmers use them.
>>
>> To be clear, Clojure's documentation system is an unstructured string,
>> the arglists metadata and (arguably) the private metadata.
>>
>
> I would add comment syntax.  Technically maybe not part of a doc "system",
> but I have yet to meet a comment that doesn't count as documentation in
> some sense.


True, and, to some extent, it inherits the ";" vs ";;" comment
distinction. But, again, there is not structure. This is an unstructured
string also. Compare Emacs Lisp, for example, which uses semi-structure
in the comments to drive many of its features.

>> Trivial things that I would like to be able to do that I cannot do (in a
>> way which will be reliably interpreted).
>>
>>  - Add hyperlinks
>>  - Distinguish between symbols (or names of vars) and normal words.
>>  - Distinguish between code (examples) and normal words
>>  - Have access to basic "markdown" style typography.
>>
>
> I'm undecided on these.  They would obviously be useful, but on the other
> hand minimalism has its virtues.  In the base case of reading code with a
> plaintext editor, I usually find embedded doco with lots of markup annoying
> and an impediment to code reading.  I think I'm inclined to favor keeping
> markup out of code but I'm keeping an open mind about it.

I've used this example before; consider this unstructured string from
`cons`.

Returns a new seq where x is the first element and seq is
the rest.


So, cons returns a seq where x is the first element, and seq is the
rest? Which means that cons returns the same (constantly x) for which
(rest (constantly x)) could be said to equal (constantly x), as a
infinite string of x's is the same as an infinite string of x's one
shorter.

Although Clojure will take an infinite amount of time to test this for
you.




>
> At the moment I'm leaning toward DITA for heavy-duty documentation, in part
> because it would allow generation of manpages.  You can see an example at
> leiningen-doc  - pdf output
> examples are in doc/pdf.  It's mostly an outline at the moment, but if you
> look at the driver file
> ugbook.ditamapand
> the files in the ug directory you can get a quick idea of how it
> works.  Once you get the hang of it you can quickly write doco in a
> language specifically designed for tech documentation (and extend it if you
> wish).
>
> That puts me in a small (infinitesimal?) minority, I reckon, but DITA is
> evolving and growing, at least among professional tech writers.  An obvious
> research topic is how Clojure and DITA might be made to play nice together.

I was never a great fan of writing XML by hand, to be honest (which is
what this appears to be). The first example that I looked at:

https://github.com/mobileink/leiningen-doc/blob/master/ug/classpath.dita

incidentally, appears to be ill-formed, having two "" tags.
XML is hard to write.


>> > If it were genuinely failing us in some important way, it would be
>> > changed.
>>
>> This is, I think, a variant of the no true Scotsman fallacy. You can
>> say, about any complaint about documentation system are wrong, because
>> if they were right, it would be changed. By definition I can produce no
>> counter examples.
>>
>
> Does that mean I win?  ;)

Yes, but only if you can prove that you are a true Scotsman.



> Actually I was thinking in terms of evolution rather than definition.
> Since version 1 of clojure lots of unmet needs have been identified and
> then met; the language has evolved in response to genuine needs (meaning:
> new stuff is actually used to do useful things).  Since that hasn't
> happened much (to my knowledge) with respect to doc features, I conclude
> that those features are at least minimally sufficient ("optimal" was a bad
> choice of words) to contribute to "survival".  I'm pretty sure Rich Hickey
> would reject any proposed changes to the language that did not meet a
> genuine unmet need, and the Clojure community is sufficiently active and
> competent and imaginative, that I'm strongly inclined to believe that, were
> the doc features genuinely deficient or inadequate in some way, the
> language would have evolved in some way to remedy the problem.


Many features added to Clojure come from other languages -- consider the
requirement (or otherwise) for keyword arguments. People feel the lack
of these features early on, when they try and port other code (or just
their mind) to a new language.

Documentation is about scalability; it only hits when you have a
reasonable amount of code (especially external libraries). It also hits
newcomers most.

So, perhaps, the time is now.

Phil

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To p

Re: find the last and the nth item without using last or nth

[James Reeves]

You have a number of typos, syntax errors and missing brackets in your
source code. It should be:

(defn nth* [coll number]
  (loop [coll coll, acc 0]
(if (= acc number)
  (first coll)
  (recur (next coll) (+ acc 1)

Additionally, you're using an unquoted list to test. Use a vector or quote
the list:

(nth* [1 2 3 4 5] 2)

- James


On 6 May 2014 16:05, Roelof Wobben  wrote:

> I tried this problem again.
>
> So I did this:
>
> (defn nth* [coll, number]
>(let [acc 0]
>(loop [coll coll acc]
>  (if == acc number))
>(first coll)
>(recur (next coll) (+acc 1 ))
>
> but when I do :
> (nth* (1,2,3,4,5)2)) I see a cannot cast error message.
>
> Is this because Clojure cannot figure out what the coll and what the
> number is ?
>
> Roelof
>
>
>
> Op woensdag 30 april 2014 12:53:01 UTC+2 schreef James Reeves:
>
>> On 30 April 2014 11:41, Roelof Wobben  wrote:
>>>
>>>
>>> Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves:


 Consider how you might add a counter to the loop. You'll want to
 increment the counter, then stop when it reaches the desired number.

>>>
>>>
>>> So without checking it so out of my head I would do this
>>>
>>>  (defn last* [coll, number]
>>>(loop [coll coll]
>>>  (if == counter number))
>>>(first coll)
>>>(recur (next coll) (+counter 1 ))
>>>
>>
>> Essentially yes. You need to initiate the counter to zero, and you still
>> need a condition to make sure you don't go past the end of the seq (in case
>> n is more than the length of the list), but you've basically got it.
>>
>> - James
>>
>

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

Re: find the last and the nth item without using last or nth

[Roelof Wobben]

Thanks,

Roelof


Op dinsdag 6 mei 2014 17:11:52 UTC+2 schreef James Reeves:

> You have a number of typos, syntax errors and missing brackets in your 
> source code. It should be:
>
> (defn nth* [coll number]
>   (loop [coll coll, acc 0]
> (if (= acc number)
>   (first coll)
>   (recur (next coll) (+ acc 1)
>
> Additionally, you're using an unquoted list to test. Use a vector or quote 
> the list:
>
> (nth* [1 2 3 4 5] 2)
>
> - James
>
>
> On 6 May 2014 16:05, Roelof Wobben >wrote:
>
>> I tried this problem again.
>>
>> So I did this: 
>>
>> (defn nth* [coll, number]
>>(let [acc 0]
>>(loop [coll coll acc]
>>  (if == acc number))
>>(first coll)
>>(recur (next coll) (+acc 1 ))
>>
>> but when I do : 
>> (nth* (1,2,3,4,5)2)) I see a cannot cast error message.
>>
>> Is this because Clojure cannot figure out what the coll and what the 
>> number is ?
>>
>> Roelof
>>
>>
>>
>> Op woensdag 30 april 2014 12:53:01 UTC+2 schreef James Reeves:
>>
>>> On 30 April 2014 11:41, Roelof Wobben  wrote:


 Op woensdag 30 april 2014 12:14:39 UTC+2 schreef James Reeves:
>
>
> Consider how you might add a counter to the loop. You'll want to 
> increment the counter, then stop when it reaches the desired number.
>


 So without checking it so out of my head I would do this 

  (defn last* [coll, number]
(loop [coll coll]
  (if == counter number))
(first coll)
(recur (next coll) (+counter 1 ))

>>>
>>> Essentially yes. You need to initiate the counter to zero, and you still 
>>> need a condition to make sure you don't go past the end of the seq (in case 
>>> n is more than the length of the list), but you've basically got it.
>>>
>>> - James
>>>
>>
>

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

Re: Proposing a new Clojure documentation system (in Clojure)

[Phillip Lord]

Mars0i  writes:
>>  - Add hyperlinks 
>>  - Distinguish between symbols (or names of vars) and normal words. 
>>  - Distinguish between code (examples) and normal words 
>>  - Have access to basic "markdown" style typography. 
>>
>> Less trivial things that I would like to be able to do: 
>>  - transclude documentation from secondary files, so that the developer 
>>of a piece of code sees a short piece of documentation, while users 
>>of code can see something longer. 
>>  - expand the documentation system as I see fit; i.e. the documentation 
>>system should be designed to an abstraction, not an implementation. 
>>
>
> To me all of this seems reasonable, especially the first group of items.  
> None of the ones in the first group, at least, require immediate changes to 
> existing docstrings.  

They do, IF they are to be machine interpretable.

Emacs docstrings using `this' convention to identify other function or
variable names. I can use this convention in my clojure docstrings.
In emacs, the help system can make these hyperlinkable. Clojure
won't.

To have this work, we need a minimal standard. Nothing more complex, but
at least that.

Phil

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

Re: clojure.zip: skip a node

[Pascal Germroth]

On Tuesday, May 6, 2014 4:07:11 PM UTC+1, Alex Miller wrote:
>
> I wrote this article long ago which hints about this at the end:
> https://www.ibm.com/developerworks/library/j-treevisit/
>

I started from that actually, very helpful article.

I have since noticed a bug in my previous skip function where it would loop 
infinitely when skipping from the rightmost location.
The fix includes an end function, so I can no just iterate backwards using 
that as you suggested.

Leaving this here for future reference, in case anybody comes across the 
same problem:

(defn end
  "returns the location loc where (end? (next loc)) is true."
  [loc]
  (loop [loc loc]
(let [loc (z/rightmost loc)]
  (if (z/branch? loc)
(recur (z/down loc))
loc

(defn skip
  "returns the next location that is not a child of this one"
  [start-loc]
  (loop [loc start-loc]
(cond
  ; can't skip, jump to end
  (nil? loc) (z/next (end start-loc))
  ; at end
  (z/end? loc) loc
  ; go to right/up
  true (or (z/right loc)
   (recur (z/up loc))
 

>
> The approach I have taken for editing trees with zippers is to do a 
> post-walk from end to beginning - that way you're always done transforming 
> and will not walk into your edited subtrees. The article does talk a little 
> about how to separate navigation from transformation; it's not particularly 
> hard. You want to start from your rightmost node, which you can get from a 
> repeated application of zip/rightmost or last of zip/rights. Then 
> repeatedly call prev till you reach a node without a parent at that point 
> convert the loc to a node in the termination.
>
> I can dig up actual code for this later if you're interested.
>
> Alex
>
>
> On Monday, May 5, 2014 6:01:04 PM UTC-5, Pascal Germroth wrote:
>>
>> Hi,
>>
>> I'm using clojure.zip to edit a tree by visiting each location using 
>> zip/next, possibly using zip/replace to alter the tree.
>> There are cases where I replace a part of the tree with another tree that 
>> will/must not be visited, but I couldn't find a good way to skip nodes, 
>> since
>> (zip/next (zip/replace loc new-subtree)) will walk right into my new 
>> tree, and I can't use (zip/right (zip/replace loc new-subtree)) as the 
>> replaced location might already be the rightmost.
>>
>> Is there a built-in function I missed, or a zip enhancement library I 
>> could use?
>>
>> (defn skip
>>   "returns the next location that is not a child of this one"
>>   [loc]
>>   (if (or (z/end? loc) (nil? loc))
>> loc
>> (loop [loc loc]
>>   (or (z/right loc)
>>   (recur (z/up loc))
>>
>> I came up with this replacement, does that seem like a good idea, or am I 
>> using zip completely wrong (because what I really would like to do is 
>> iterate backwards through the tree, starting at the end, using zip/prev; 
>> but there's also no function to just jump to the end as far as I can tell)
>>
>>
>> Cheers,
>>
>> -- 
>> pascal
>>
>

-- 
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: Wrapping functions of Java interfaces with inheritance chains

[fs]

Thank you for your in-depth answer!

My problem is that in this case, the sub-interfaces are actually very 
distinct from each other and it would make sense to have separate 
namespaces for them. So, SubElementA is really very different from 
SubElementB. Ironically the same API has another inheritance hierarchy 
where it indeed makes sense to do the opposite and only provide one 
namespace because those interfaces are thematically very similar to each 
other.

The main reason for re-exposing the base interface methods was that 
somebody who works with my wrapper wouldn't have to remember that 
SubElementA and SubElementB are extensions of a base Element interface. So 
in a sense there would be less of a 'cognitive overhead' for him or her, 
and one fewer namespace to import.

On your suggestions about Clojure-ifying the wrapper: I'm actually working 
on another library that does this, and depends on the wrapper library in 
question.

Again, thank you very much for taking the time to answer my question.





On Tuesday, May 6, 2014 4:54:23 PM UTC+2, Alex Miller wrote:
>
>
> On Tuesday, May 6, 2014 6:53:51 AM UTC-5, f...@kimchi.io wrote:
>>
>> Disclaimer: I'm new to Clojure programming.
>>
>
> Welcome!
>  
>
>> I work on some Clojure wrapper functions for a Java API that mainly 
>> consists of interfaces.
>>
>> I wonder what the 'usual way of doing things' is regarding inheritance 
>> chains.
>>
>> Let's say there's an interface called *Element* that has a 
>> *getId()*function. A second interface, called 
>> *SubElement,* extends *Element*. I have two clojure namespaces for these 
>> two interfaces: *foo.element* and *foo.sub-element*. 
>>
>
> I suspect you probably don't actually need two namespaces for this, but it 
> depends on the api and your wrapping needs.
>
> In foo.element there is a wrapper for the getId() function:
>>
>> (defn get-id
>>   [^Element element]
>>   (.getId element))
>>
>
> ok
>  
>
>>
>> Now my question is regarding foo.sub-element. Should I just redefine 
>> get-id in there? 
>>
>> (defn get-id
>>   [^SubElement element]
>>   (.getId element))
>>
>
> There is no reason to do this - your prior get-id is fine. A SubElement is 
> an Element and Java turns these into the same virtual call either way. 
>  
>
>>
>> Or should I do:
>>
>> (defn get-id
>>   [^Element element]
>>   (element/get-id element))
>>
>
> There is no need to wrap a function like this.
>  
>
>> Or should I use potemkin in there?
>>
>> (potemkin/import-fn element/get-id)
>>
>
> And I definitely wouldn't go to potemkin for this.
>  
>
>> Or should I not re-wrap this function call and work with both namespaces 
>> when dealing with SubElements? 
>>
>
> When you need to get the id, call the function in the element ns. If you 
> need something SubElement specific, call the functions in sub-element. You 
> may find that all of the functions in both ns'es could really go in Element.
>
> You may also consider not wrapping the api directly but instead 
> transforming your Java objects into Clojure data, working with it, then 
> transforming it back to Java if needed. There are obvious costs with 
> transformation and memory so this only sometimes makes sense, can't say 
> without knowing more about the API and the usage of it. One quick-and-dirty 
> tool for this is the "bean" function which takes a Java object and returns 
> a Clojure map based on it's "bean" properties (get*, is*).
>
> In general, rather than having explicit getter functions, Clojure 
> information entities (as maps or records) typically use keywords as keys 
> (the "fields" of the entity) and leverage the ability of keywords to invoke 
> themselves on a map as a getter function. I mention this because to take 
> advantage of this common pattern, you would need to do the transformation 
> from Java object to Clojure map/record. Again, hard to say whether that 
> makes sense for you.
>
>  
>
>>
>> What are the pros and cons to these different approaches? Thanks.
>>
>>
>>

-- 
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: Functional programming and security

[Gary Trakhman]

My 'Network Security' Professor once said to the class, 'There is no
security without physical security'.  Protecting data from being read in
memory means you've already lost.


On Tue, May 6, 2014 at 5:19 AM, Luc Prefontaine  wrote:

> Reading this thread convinced me.
> I will not write any information on
> any support except my brain cells
> and will not share it to avoid any
> leaks.
>
> I will also forget it immediately so
> no one can scrub my brain to
> recover it
>
> Going to erase everything I wrote and
> learned in
> the last past 30 years right now...
>
> Seriously, when concerns about
> security reaches the garbage collector
> which operates in live memory,
> I wonder why we bother entering
> any information in a computer...
>
> Any security related discussion
> reaches a point were sanity is left
> far behind don't you agree ? :)))
>
> What was I writing a few seconds ago ?
>
> Luc P.
>
> > On Tue, May 6, 2014 at 9:45 AM, Cecil Westerhof 
> wrote:
> > > 2014-05-05 19:48 GMT+02:00 Brian Craft :
> > >> I would never have guessed modularity as a reason to worry about
> security
> > >> in fp.
> > >>
> > >> I worry about immutability in fp, wrt security. Security requires
> > >> mutability in order to remove sensitive data from memory, and from app
> > >> history. A FIPS
> > >
> > > Would forced garbage collection not take care of that?
> >
> > I think the combination of zeroizing destructors, weak references, and
> > forced garbage collection would go a long way.  Then you only need to
> > convince the FIPS validator/evaluator/thingie that your garbage
> > collector behaves well so that sensitive data is scrubbed in a timely
> > manner.
> >
> > /M
> >
> > --
> > Magnus Therning  OpenPGP: 0xAB4DFBA4
> > email: mag...@therning.org   jabber: mag...@therning.org
> > twitter: magthe   http://therning.org/magnus
> >
> > --
> > 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.
> >
> --
> Luc Prefontaine sent by ibisMail!
>
> --
> 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: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Tue, May 6, 2014 at 10:11 AM, Phillip Lord
wrote:

> Gregg Reynolds  writes:
> >> I think that the counter argument to that is that many other programming
> >> languages have a richer documentation system than Clojure, and many
> >> programmers use them.
> >>
> >> To be clear, Clojure's documentation system is an unstructured string,
> >> the arglists metadata and (arguably) the private metadata.
> >>
> >
> > I would add comment syntax.  Technically maybe not part of a doc
> "system",
> > but I have yet to meet a comment that doesn't count as documentation in
> > some sense.
>
>
> True, and, to some extent, it inherits the ";" vs ";;" comment
> distinction. But, again, there is not structure. This is an unstructured
> string also. Compare Emacs Lisp, for example, which uses semi-structure
> in the comments to drive many of its features.
>

I'm ok with some kind of structure for comments and docstrings, but I would
relegate it to an add-on, not part of the Clojure language definition.
We're effectively talking about adding a second syntax.  The original
poster (Val?) suggested using Clojure syntax for the documentation
language, but I'm not so sure about that yet; haven't thought about it
enough.  In principle I would think it would not be too terribly difficult
to hack a clojure parser to support a documentation mini-language for
comments and docstrings, effectively yielding a kind of clojure-docs
processor.

>> Trivial things that I would like to be able to do that I cannot do (in a
> >> way which will be reliably interpreted).
> >>
> >>  - Add hyperlinks
> >>  - Distinguish between symbols (or names of vars) and normal words.
> >>  - Distinguish between code (examples) and normal words
> >>  - Have access to basic "markdown" style typography.
> >>
> >
> > I'm undecided on these.  They would obviously be useful, but on the other
> > hand minimalism has its virtues.  In the base case of reading code with a
> > plaintext editor, I usually find embedded doco with lots of markup
> annoying
> > and an impediment to code reading.  I think I'm inclined to favor keeping
> > markup out of code but I'm keeping an open mind about it.
>
> I've used this example before; consider this unstructured string from
> `cons`.
>
> Returns a new seq where x is the first element and seq is
> the rest.
>
>
> So, cons returns a seq where x is the first element, and seq is the
> rest? Which means that cons returns the same (constantly x) for which
> (rest (constantly x)) could be said to equal (constantly x), as a
> infinite string of x's is the same as an infinite string of x's one
> shorter.
>

I would call that an example of sloppy documentation since it uses "seq" as
both a type name and a data name.  Support for structured strings can't
prevent that.

Here's a concrete best-practices suggestion: follow the lead of Haskell and
other functional languages in using x, y, z as generic type names, and x:xs
(where 'xs' is plural of x) to indicate a list of xs; for seqs, maybe
x::xs.  So I would rewrite your example to something like:  "[x y::ys] ->
x::y::ys"

Which leads to another suggestion: for documentation purposes, use "xs" (or
"ys", etc) instead of "coll", as the doc currently does.  For example, for
first,
instead of
first function

Usage: (first coll)

Returns the first item in the collection. Calls seq on its
argument. If coll is nil, returns nil.

We would have:

first x::xs -> x
first nil -> nil

To indicate that it calls seq on its arg, maybe something like:

first xs == first seq xs -> first x::xs -> x

where

seq xs -> x::xs  ;; by convention, 'xs' means 'collection of somethings'
and 'x::xs' means "sequence of somethings"
seq nil -> nil

I guess the point is that good, clear, concise, well-defined conventions
can solve a lot of problems before we even get to the issue of supporting
structured doc text.


> Although Clojure will take an infinite amount of time to test this for
> you.
>
>
>
>
> >
> > At the moment I'm leaning toward DITA for heavy-duty documentation, in
> part
> > because it would allow generation of manpages.  You can see an example at
> > leiningen-doc  - pdf output
> > examples are in doc/pdf.  It's mostly an outline at the moment, but if
> you
> > look at the driver file
> > ugbook.ditamap<
> https://github.com/mobileink/leiningen-doc/blob/master/ugbook.ditamap>and
> > the files in the ug directory you can get a quick idea of how it
> > works.  Once you get the hang of it you can quickly write doco in a
> > language specifically designed for tech documentation (and extend it if
> you
> > wish).
> >
> > That puts me in a small (infinitesimal?) minority, I reckon, but DITA is
> > evolving and growing, at least among professional tech writers.  An
> obvious
> > research topic is how Clojure and DITA might be made to play nice
> together.
>
> I was never a great fan of writing XML by

Re: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Sat, May 3, 2014 at 3:46 PM, Val Waeselynck wrote:

> All right, I'll give it a try, here are some thoughts :
>
> I think it's too hard make precise requirements for advanced features in
> advance; I'd rather find a way to let usage drive us in the right
> direction. However, there are a few principles that we know will be wise to
> follow :
>
>- encouraging separation of concerns
>- avoiding duplication of logic
>
> And indeed as a programming language, Clojure follow these very well in
> many respects.
>
>   Applying these to the topic of documentation, I think it's a good idea
> to make the documentation system/process separate the concerns of writing
> quality code and making understandable. That seems to make a case towards
> documenting with tests/examples/schemas and against literate programming
> (was that your point, Gregg?)
>
Hi Val, sorry for getting back to you so late (was in the process of moving
to a new apartment the last few weeks so had intermittent web access).

My original comment on litprog ("bad bad bad") was admittedly a little
strong.  I think its bad for some things, fine for others.  And it's
possible litprog conventions will evolve to address the problems some of us
see with using it for programming in the large etc.

As for documenting with "tests/examples/schemas", I'm somewhere in that
general vicinity, but I think much more needs to be said about just what
that means, and what sort of norms should apply in each case.  See for
example https://github.com/mobileink/codegenres/wiki/Tests-as-Documentation(and
feel free to edit, it's just ideas now).

BTW, I discovered the links at
https://github.com/mobileink/codegenres/wikiwere broken; they're fixed
now.

- and maybe also against using types for documenting, but that's really my
> own personal feeling and I don't have any evidence for it.
>

Not sure what you mean; I consider type annotations (hints, whatever)
essential to good documentation.

-Gregg

-- 
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: Functional programming and security

[Gregg Reynolds]

If you want a friend, get a dog.  If you want security, get a big
mean-looking dog who barks a lot.


Sorry, couldn't resist.


On Tue, May 6, 2014 at 11:04 AM, Gary Trakhman wrote:

> My 'Network Security' Professor once said to the class, 'There is no
> security without physical security'.  Protecting data from being read in
> memory means you've already lost.
>
>
> On Tue, May 6, 2014 at 5:19 AM, Luc Prefontaine <
> lprefonta...@softaddicts.ca> wrote:
>
>> Reading this thread convinced me.
>> I will not write any information on
>> any support except my brain cells
>> and will not share it to avoid any
>> leaks.
>>
>> I will also forget it immediately so
>> no one can scrub my brain to
>> recover it
>>
>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Sean Corfield]

On May 6, 2014, at 8:11 AM, Phillip Lord  wrote:
> I've used this example before; consider this unstructured string from
> `cons`.
> 
> Returns a new seq where x is the first element and seq is
> the rest.

Just because one (or several) of the clojure.core function docstrings are 
poorly written, doesn't mean Clojure's current documentation system is broken. 
This simply comes back to developers needing to write _better_ documentation, 
not _more_ documentation.

Adding complexity and weaving heapings of prose in amongst the code isn't going 
to make the developer that wrote the above rewrite it in a better way. You'll 
just end up with more bad documentation getting in the way of what the code 
actually does. Bad documentation is worse than no documentation. At least with 
no documentation, the code doesn't lie.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Proposing a new Clojure documentation system (in Clojure)

[Mark Engelberg]

On Tue, May 6, 2014 at 9:56 AM, Sean Corfield  wrote:

> > Returns a new seq where x is the first element and seq is
> > the rest.
>
> Adding complexity and weaving heapings of prose in amongst the code isn't
> going to make the developer that wrote the above rewrite it in a better
> way. You'll just end up with more bad documentation getting in the way of
> what the code actually does. Bad documentation is worse than no
> documentation. At least with no documentation, the code doesn't lie.
>

Sean, I think you missed the point of that example.  The point was that the
docstring actually makes sense if it were written as:

Returns a new seq where `x` is the first element and `seq` is the rest.

Note how using standard markdown syntax helps distinguish the reference to
the `seq` arg and the more generic use of the term seq.

I think the Clojure community's lack of meaningful support for markdown in
docstrings is a glaring weakness that is fairly easy to rectify.  In the
meantime, I've begun using markdown syntax in my own docstrings, figuring
that someday the tools will eventually catch up and support it.

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Tim Daly]

> Less trivial things that I would like to be able to do: 
>  - transclude documentation from secondary files, so that the developer 
>of a piece of code sees a short piece of documentation, while users 
>of code can see something longer. 
>  - expand the documentation system as I see fit; i.e. the documentation 
>system should be designed to an abstraction, not an
>  implementation. 

   - include diagrams and pictures
   It is easy to show the red-black tree rebalance algorithm
 with a few pictures whereas the words are rather opaque. 
 Stacks and immutable copy algorithms are also easy in diagrams.
 You CAN do this with "ascii-art" but it IS the late 90s and some
 lucky few of us have 640x480 color terminals.

Tim



-- 
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: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel

[Timothy Baldridge]

First of all, this shouldn't work at all, since you aren't requiring
core.async, so you shouldn't be getting anything about that library at all.
Perhaps you need to reload your repl, or perhaps there's something missing
in your gist?

Thanks,

Timothy


On Mon, May 5, 2014 at 3:15 PM, Valentin Luchko  wrote:

> Here is the gist
> https://gist.github.com/valichek/ba510de9ff2cf3d0c502
>
> P.S. sorry if my first post was odd
> понедельник, 5 мая 2014 г., 20:03:09 UTC+3 пользователь Valentin Luchko
> написал:
>
>> Could you explain me why after
>> clients;; => {#> /0:0:0:0:0:0:0:1%0:<->/0:0:0:0:0:0:0:1%0:60071>
>> true}
>> (into {} clients) ; => #> channels.ManyToManyChannel@5d9c832a>
>> I get > implementation of method: :take! of protocol: 
>> #'clojure.core.async.impl.protocols/ReadPort
>> found for class: nil
>> AsyncChannel is from http-kit
>>
>> and
>> (merge {} clients) ;; #> channels.ManyToManyChannel@5d9c832a>
>>
>> How {#/0:0:0:0:0:0:0:1%0:60071>
>> true} is transformed to #> channels.ManyToManyChannel@5d9c832a>?
>> I suspect it is because I use AsyncChannel as a key, but what is going on?
>>
>>
>>
>>
>>  --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Tim Daly]

> Compare Emacs Lisp, for example, which uses semi-structure
> in the comments to drive many of its features.

Speaking of Emacs, there are (at least) two doc systems available,
the emacs "info" system and org-mode. Both of those evolved due to
a need for a better documentation system. 

The claim has been made that what exists is all we need since, if
there was MORE we need then a doc system would arise. Several dozen
have arisen and are in use.

Wouldn't a gif of Rich's Ant system running make the whole point
of the code perfectly obvious? Wouldn't it be even better if, when
you changed the code, the gif updated to reflect the new change?
We have Clojurescript and browsers have a canvas element.

Given that I only have a 640x480 terminal I guess ascii ants would
be ok :-)


-- 
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: Proposing a new Clojure documentation system (in Clojure)

[John Gabriele]

On Tuesday, May 6, 2014 1:41:25 PM UTC-4, puzzler wrote:
>
> On Tue, May 6, 2014 at 9:56 AM, Sean Corfield 
> > wrote:
>
>>
>>
> Sean, I think you missed the point of that example.  The point was that 
> the docstring actually makes sense if it were written as:
>
> Returns a new seq where `x` is the first element and `seq` is the rest.
>
> Note how using standard markdown syntax helps distinguish the reference to 
> the `seq` arg and the more generic use of the term seq.  
>
> I think the Clojure community's lack of meaningful support for markdown in 
> docstrings is a glaring weakness that is fairly easy to rectify.  In the 
> meantime, I've begun using markdown syntax in my own docstrings, figuring 
> that someday the tools will eventually catch up and support it.
>
>
Using markdown in docstrings would be fantastic. This would enable tools 
like codox and autodoc to produce nice-looking html output from docstrings, 
instead of just docstring here output.

And the difference between the current Clojure docstrings and updated 
markdown-formatted docstrings is pretty minimal. Heck, I bet that 
markdown-i-fying the docstrings would even provide an easy on-ramp for a 
lot of folks (myself included) to get involved in the patch submission 
process...

Incidentally, I see that the [Rust](http://www.rust-lang.org/) folks use 
markdown-formatted docstrings. Have a look at some of [their API 
docs](http://static.rust-lang.org/doc/master/std/index.html). Very nice.

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[u1204]

> Here's a concrete best-practices suggestion: follow the lead of Haskell and
> other functional languages in using x, y, z as generic type names, and x:xs
> (where 'xs' is plural of x) to indicate a list of xs; for seqs, maybe
> x::xs.  So I would rewrite your example to something like:  "[x y::ys] ->
> x::y::ys"

If you're citing Haskell's system as "best practice" perhaps we might
simply adopt their "literate" tools and techniques? 

Tim

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Sean Corfield]

On May 6, 2014, at 10:41 AM, Mark Engelberg  wrote:
> Sean, I think you missed the point of that example.

No, I was simply responding to Philip's assertion that the docstring was poorly 
written.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clojure.test parameterized tests

[Brian Craft]

Using the "testing" macro introduces the same problem with fixtures. 
Fixtures don't run except around things defined with deftest.

Anyone have an example of a test 1) parameterized, and 2) with working 
fixture?

Someone suggested the Expectations lib, but I don't see any fixture support 
there. Anyone using Expectations that can point me to the right place?


On Friday, May 2, 2014 11:38:27 AM UTC-7, Brian Craft wrote:
>
> Wow, I never would have figured that out from the docs. Thanks.
>
> Just found a different problem with my solution: nested tests, as 
> described in the docs, prevent the use of fixtures. You have to add 
> test-ns-hook when using nested tests, and then fixtures aren't run.
>
> On Friday, May 2, 2014 11:05:56 AM UTC-7, Karsten Schmidt wrote:
>>
>> You can use the `testing` macro and wrap it in a function, which accepts 
>> your type/protocol implementation or even individual protocol methods as 
>> args. Example here:
>>
>> https://github.com/thi-ng/geom/blob/master/test/core.org#callable-contexts
>> On 2 May 2014 18:08, "Brian Craft"  wrote:
>>
>>> Thanks. I did something similar. I have different implementations per 
>>> db, so use a global *db* var:
>>>
>>> (ct/deftest run-tests
>>>   (matrix1)) ; matrix1 tests against *db*
>>>
>>> (ct/deftest test-h2
>>>   (binding [*db* (h2/create-db2 "test" {:subprotocol "h2:mem"})]
>>> (run-tests)))
>>>
>>> (defn test-ns-hook []
>>>   (test-h2))
>>>
>>> Clumsy, but seems to be the only option.
>>>
>>> On Friday, May 2, 2014 8:29:23 AM UTC-7, Chris Price wrote:

 I have been curious about this too.  I was playing around with it a few 
 weeks ago and came up with this:

 https://github.com/cprice404/clj-shared-test-sandbox/blob/
 master/test/shared_tests_foo/core_test.clj

 Which is pretty gross; it uses `binding` + a dynamic var in the shared 
 test namespace, and then it calls `clojure.test/run-tests` from inside of 
 a 
 `deftest`.  I'm sure there's got to be a better way, but that was as far 
 as 
 I got in the small amount of time that I was able to spend on it.

 On Thursday, May 1, 2014 5:58:51 PM UTC-7, Brian Craft wrote:
>
> I have a number of tests that I would like to run against different 
> implementations of a protocol. In clojure.test there doesn't appear to be 
> a 
> way to parameterize a test over the implementations. Is there a good way 
> to 
> do this?
>
  -- 
>>> 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.

In Lein, is it possible to run a specific test suite?

[Hussein B.]

Hi,

I'm using clojure.test and Lein. Is it possible to run a specific test suit 
? I don't want to run the whole test each time.

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: Proposing a new Clojure documentation system (in Clojure)

[Tim Daly]

Gregg,

> My original comment on litprog ("bad bad bad") was admittedly a little
> strong.  I think its bad for some things, fine for others.  And it's
> possible litprog conventions will evolve to address the problems some of us
> see with using it for programming in the large etc.

Could you explain what "some of the problems some of us see with using
it for programming in the large" might be? It is hard to refute 
"bad bad bad" and other assertions without specific examples.

Axiom (1.2 million lines of lisp) is being rewritten into a literate
program. So far I can't think of a problem. Clojure is being reworked
into literate form already and I can't see a problem other than trying
to understand and explain code I didn't write (reading code is hard).

The Clojure community isn't ready to make the leap into a literate
world. I understand that. But Clojure is still at the stage of writing
new code for new uses. There are few people who need to modify code
written by programmers who left the community. That's when the need
will arise for clearly communicating ideas to other humans.

The technical debt has not come due ... but it will. 

Tim





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

data.xml namespace aware?

[Timothy Washington]

Hi there,


*A)* I'm just writing some SOAP XML, trying to use
data.xml.
This SO 
thread
outlines
how to write out namespace aware XML. But the example is for a namespace on
an attribute. I'm combing through the code now, but does anyone know how to
set this up?


*B)* There's actually this Fuller XML
Supportproposal
(referring to this
thread),
and this Namespaced XML
proposal. But I
don't see that namespaces are fully implemented in any of
the core libs.

I only see this ArmageDOM  lib,
which supports namespaces. Anything else out there that I've missed?


Thanks

Tim Washington
Interruptsoftware.com 

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

Re: In Lein, is it possible to run a specific test suite?

[Alex Miller]

Sure! You might try doing "lein help test" to give you a bunch more info 
about creating custom test sets based on selector tags but you can also

Run tests in a namespace:

  lein test :only my.test.ns

Run specific test:

  lein test :only my.test.ns/test-foo

Alex

On Tuesday, May 6, 2014 2:22:15 PM UTC-5, Hussein B. wrote:
>
> Hi,
>
> I'm using clojure.test and Lein. Is it possible to run a specific test 
> suit ? I don't want to run the whole test each time.
>
> 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: Proposing a new Clojure documentation system (in Clojure)

[Tim Daly]

> Adding complexity and weaving heapings of prose in amongst the code
> isn't going to make the developer that wrote the above rewrite it in a
> better way. You'll just end up with more bad documentation getting in
> the way of what the code actually does. Bad documentation is worse than
> no documentation. At least with no documentation, the code doesn't
> lie.

Bad documentation should have to leap the same hurdles as bad code.
Code review ought to be able to push back against bad documentation
just as easily as it screams at bad code. 

There is the famous "WTFs per minute" cartoon that can be applied to
documentation. Doing regular doc reviews might provide full employment
for English majors :-)

In fact, working on a WTF code review social process in Clojure might be
the most effective step toward better code and documentation overall.
Of course, this would have to be instituted by Rich and company since
they control the sources.

We could post code snippets (ref my prior post) which need explanation
and do a "community documentation upgrade" on the Clojure sources.

Tim

-- 
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: data.xml namespace aware?

[Timothy Washington]

Got a bit further here. I want to be able to get tag namespaces without a
:root tag (that includes the namespace definition). Assume the below code
has (require '[clojure.data.xml :as xml]).


Working with attributes is fine.

(def e1 (xml/element :use {:xmlns:xlink "http://testing";,
   :xlink:href "#whiskers",
   :transform "scale(-1 1) translate(-140 0)"}))


Namespace prefixes is possible with tags; however, I had to add the
unwanted :root tag (that includes ns definition)

(def e2 (xml/element :root {:xmlns:thing "http://thing"}
 (xml/element :thing:use {})))

(def e3 (xml/element :root {:xmlns:thing "http://thing"}
 (xml/sexp-as-element
  [:thing:first {}
   [:thing:second {}]])))

(defn print-esequel [elem]
  (println (xml/indent-str elem)))



The resulting XML is close. But we want the tag namespaces, without the
root node

user> (print-esequel process/e2)


http://thing";>
  


user> (print-esequel process/e3)


http://thing";>
  

  




Tim Washington
Interruptsoftware.com 


On Tue, May 6, 2014 at 3:24 PM, Timothy Washington wrote:

> Hi there,
>
>
> *A)* I'm just writing some SOAP XML, trying to use 
> data.xml.
> This SO 
> thread
>  outlines
> how to write out namespace aware XML. But the example is for a namespace on
> an attribute. I'm combing through the code now, but does anyone know how to
> set this up?
>
>
> *B)* There's actually this Fuller XML 
> Supportproposal 
> (referring to this
> thread),
> and this Namespaced 
> XMLproposal. But I don't 
> see that namespaces are fully implemented in any of
> the core libs.
>
> I only see this ArmageDOM  lib,
> which supports namespaces. Anything else out there that I've missed?
>
>
> Thanks
>
> Tim Washington
> Interruptsoftware.com 
>
>
>
>

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

Re: data.xml namespace aware?

[Timothy Washington]

Ok, scratch that. I got it working, lol :)

Sorry for the false alarm. For future reference, this:

(def e4 (xml/sexp-as-element
 [:thing:first {:xmlns:thing "http://thing"}
 [:thing:second {}]]))


...gives you this:

user> (process/print-esequel process/e4)


http://thing";>
  




Tim Washington
Interruptsoftware.com 


On Tue, May 6, 2014 at 3:45 PM, Timothy Washington wrote:

> Got a bit further here. I want to be able to get tag namespaces without a
> :root tag (that includes the namespace definition). Assume the below code
> has (require '[clojure.data.xml :as xml]).
>
>
> Working with attributes is fine.
>
> (def e1 (xml/element :use {:xmlns:xlink "http://testing";,
>:xlink:href "#whiskers",
>:transform "scale(-1 1) translate(-140 0)"}))
>
>
> Namespace prefixes is possible with tags; however, I had to add the
> unwanted :root tag (that includes ns definition)
>
> (def e2 (xml/element :root {:xmlns:thing "http://thing"}
>  (xml/element :thing:use {})))
>
> (def e3 (xml/element :root {:xmlns:thing "http://thing"}
>  (xml/sexp-as-element
>   [:thing:first {}
>[:thing:second {}]])))
>
> (defn print-esequel [elem]
>   (println (xml/indent-str elem)))
>
>
>
> The resulting XML is close. But we want the tag namespaces, without the
> root node
>
> user> (print-esequel process/e2)
>
> 
> http://thing";>
>   
> 
>
> user> (print-esequel process/e3)
>
> 
> http://thing";>
>   
> 
>   
> 
>
>
>
> Tim Washington
> Interruptsoftware.com 
>
>
> On Tue, May 6, 2014 at 3:24 PM, Timothy Washington wrote:
>
>> Hi there,
>>
>>
>> *A)* I'm just writing some SOAP XML, trying to use 
>> data.xml.
>> This SO 
>> thread
>>  outlines
>> how to write out namespace aware XML. But the example is for a namespace on
>> an attribute. I'm combing through the code now, but does anyone know how to
>> set this up?
>>
>>
>> *B)* There's actually this Fuller XML 
>> Supportproposal 
>> (referring to this
>> thread),
>> and this Namespaced 
>> XMLproposal. But I don't 
>> see that namespaces are fully implemented in any of
>> the core libs.
>>
>> I only see this ArmageDOM lib, 
>> which supports namespaces. Anything else out there that I've missed?
>>
>>
>> Thanks
>>
>> Tim Washington
>> Interruptsoftware.com 
>>
>>
>>
>>
>

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

Re: Problem when trying to import SAT4J java class

[Ronan BARZIC]

Thank - That fixed the problem - I was using an example from "Clojure
Programming" (P 328) and they didn't use square braquets - probably a typo ?

Ronan






On Mon, May 5, 2014 at 10:50 PM, Jason Felice wrote:

> The form should be:
>
> (:import [org.sat4j.core Vec]) ; note the square braces.
>
>
> On Mon, May 5, 2014 at 3:29 PM, Ronan BARZIC  wrote:
>
>> Hi,
>>
>> I'm trying to use the SAT4J java library (http://www.sat4j.org) from
>> Clojure.
>> I've create a clojure app with "lein new app sat4j-app"
>>
>> I've edited the project.clj file to :
>>
>> (defproject sat4j-app "0.1.0-SNAPSHOT"
>>   :description "FIXME: write description"
>>   :url "http://example.com/FIXME";
>>   :license {:name "Eclipse Public License"
>> :url "http://www.eclipse.org/legal/epl-v10.html"}
>>   :dependencies [
>>  [org.clojure/clojure "1.5.1"]
>>  [org.ow2.sat4j/org.ow2.sat4j.sat "2.3.5"]
>>  [org.ow2.sat4j/org.ow2.sat4j.core "2.3.5"]
>>  ]
>>   :main sat4j-app.core
>>   :profiles {:uberjar {:aot :all}})
>>
>> If I run lein deps, I can see that leiningen can find the sta4j modules :
>> 
>> Retrieving
>> org/ow2/sat4j/org.ow2.sat4j.sat/2.3.5/org.ow2.sat4j.sat-2.3.5.pom from
>> central
>> Retrieving
>> org/ow2/sat4j/org.ow2.sat4j.pom/2.3.5/org.ow2.sat4j.pom-2.3.5.pom from
>> central
>> Retrieving org/ow2/ow2/1.5/ow2-1.5.pom from central
>> Retrieving
>> org/ow2/sat4j/org.ow2.sat4j.core/2.3.5/org.ow2.sat4j.core-2.3.5.pom from
>> central
>> 
>>
>> And I can compile and run the default code (no sat4j import yet).
>> The problem occurs when I try to use import in my main clojure code :
>>
>> (ns sat4j-app.core
>>   (:gen-class)
>>   (:import org.ow2.sat4j/org.ow2.sat4j.core Vec ))
>>
>> I then get a Class not found exception (Vec is suppoed to be defined in
>> the core module)
>> I don't know which syntax to use in the import statement.
>> I've also tried (:import org.ow2.sat4j.core Vec ), (:import
>> org.ow2.sat4j.core.Vec ) without success.
>>
>> To make think even more confusing, I did a local build of sat4j and I
>> found (using javadoc html page) that the Vec class is defined as
>> org.sat4j.core.Vec
>> not org.ow2.sat4j.core.Vec.
>> So I tried (:import org.sat4j.core.Vec ) and (:import org.sat4j.core Vec
>> ) without success.
>>
>> Any clue ?
>>
>>
>> Thank you
>>
>>
>> Ronan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/4XbuiyUw1ac/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Immutable or Effectively Immutable?

[Mike Fikes]

Are the persistent immutable data structures in Clojure "truly" immutable 
(using final fields, relying on constructor freezing), or are they mean to 
be merely effectively immutable (as defined in JICP)?

-- 
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: Immutable or Effectively Immutable?

[Andy Fingerhut]

I haven't read JICP that you refer to, but I believe that they are
effectively immutable.

See a post by me in this thread titled "Clojure Concurrency and Custom
Types" from March 2013 for how to stay within Clojure, but I believe
requiring Java interop calls, to mutate in place Clojure's immutable data
structures:


https://mail.google.com/mail/u/0/#search/label%3Aclojure+concurrency+and+custom+types/13d9d40bc9dd658a

I have never seen code like that in any Clojure libraries I have looked at,
though.

Andy


On Tue, May 6, 2014 at 2:11 PM, Mike Fikes  wrote:

> Are the persistent immutable data structures in Clojure "truly" immutable
> (using final fields, relying on constructor freezing), or are they mean to
> be merely effectively immutable (as defined in JICP)?
>
> --
> 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: Proposing a new Clojure documentation system (in Clojure)

[Mars0i]

On Tuesday, May 6, 2014 2:22:13 PM UTC-5, da...@axiom-developer.org wrote:
>
> Gregg, 
>
> > My original comment on litprog ("bad bad bad") was admittedly a little 
> > strong.  I think its bad for some things, fine for others.  And it's 
> > possible litprog conventions will evolve to address the problems some of 
> us 
> > see with using it for programming in the large etc. 
>
> Could you explain what "some of the problems some of us see with using 
> it for programming in the large" might be? It is hard to refute 
> "bad bad bad" and other assertions without specific examples. 
>
> Axiom (1.2 million lines of lisp) is being rewritten into a literate 
> program. So far I can't think of a problem. Clojure is being reworked 
> into literate form already and I can't see a problem other than trying 
> to understand and explain code I didn't write (reading code is hard). 
>
> The Clojure community isn't ready to make the leap into a literate 
> world. I understand that. But Clojure is still at the stage of writing 
> new code for new uses. There are few people who need to modify code 
> written by programmers who left the community. That's when the need 
> will arise for clearly communicating ideas to other humans. 
>
> The technical debt has not come due ... but it will. 
>
> Tim 
>

Previous posts in this and related threads make it clear that some people 
dislike literate programming as a general requirement.  I am one of them.  
At the same time, I think that literate programming is probably a Good 
Thing in certain contexts.  Some kinds of coding probably benefit from 
L.P.  At the very least L.P. a good thing in some contexts simply in that 
some people like it.  So I support it use in appropriate contexts--e.g. for 
projects carried out by people who like it, or for projects that would seem 
to derive special benefits from it.  I don't believe that L.P. is either 
necessary or sufficient for good documentation, and I would be dismayed if 
it were adopted as a general norm for Clojure.

-- 
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: Functional programming and security

[Mars0i]

On Monday, May 5, 2014 3:20:41 AM UTC-5, Cecil Westerhof wrote:
>
>
> ​That is why I do not understand that (where I live) they think you can 
> only be a good programmer if you only program in one language.
>

If I had to come up with a rule of thumb along this dimension it would be: 
Any truly experienced programmer can't remember how many languages s/he has 
programmed in.   (No doubt that statement is often false, like any easily 
stated rule of thumb (including this one).)

-- 
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: http-kit AsyncChannel and clojure.core.async.impl.channels.ManyToManyChannel

[dgrnbrg]

The core of the matter is that http-kit's async channels are 
these: 
https://github.com/http-kit/http-kit/blob/master/src/java/org/httpkit/server/AsyncChannel.java

And core.async's are 
these: 
https://github.com/clojure/core.async/blob/master/src/main/clojure/cljs/core/async/impl/channels.cljs#L27

You need to write your own glue code to interface these libraries together.

On Tuesday, May 6, 2014 2:32:09 PM UTC-4, tbc++ wrote:
>
> First of all, this shouldn't work at all, since you aren't requiring 
> core.async, so you shouldn't be getting anything about that library at all. 
> Perhaps you need to reload your repl, or perhaps there's something missing 
> in your gist?
>
> Thanks,
>
> Timothy
>
>
> On Mon, May 5, 2014 at 3:15 PM, Valentin Luchko 
> > wrote:
>
>> Here is the gist
>> https://gist.github.com/valichek/ba510de9ff2cf3d0c502
>>
>> P.S. sorry if my first post was odd
>> понедельник, 5 мая 2014 г., 20:03:09 UTC+3 пользователь Valentin Luchko 
>> написал:
>>
>>> Could you explain me why after 
>>> clients;; => {#>> /0:0:0:0:0:0:0:1%0:<->/0:0:0:0:0:0:0:1%0:60071> 
>>> true}
>>> (into {} clients) ; => #>> channels.ManyToManyChannel@5d9c832a>
>>> I get >> implementation of method: :take! of protocol: 
>>> #'clojure.core.async.impl.protocols/ReadPort 
>>> found for class: nil
>>> AsyncChannel is from http-kit
>>>
>>> and
>>> (merge {} clients) ;; #>> channels.ManyToManyChannel@5d9c832a>
>>>
>>> How {#/0:0:0:0:0:0:0:1%0:60071> 
>>> true} is transformed to #>> channels.ManyToManyChannel@5d9c832a>?
>>> I suspect it is because I use AsyncChannel as a key, but what is going 
>>> on?
>>>  
>>>
>>>
>>>
>>>  -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Immutable or Effectively Immutable?

[Alex Miller]

The Clojure persistent data structures are truly immutable - all fields are 
final and referred objects are not mutated after construction so that 
freeze occurs.  One obvious exception are the transient variants 
(http://clojure.org/transients). You can look at the code 
in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - 
any of the Persistent*.java.

On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>
> Are the persistent immutable data structures in Clojure "truly" immutable 
> (using final fields, relying on constructor freezing), or are they mean to 
> be merely effectively immutable (as defined in JICP)?
>

-- 
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: Immutable or Effectively Immutable?

[Timothy Baldridge]

And hash codes are not final as they are calculated on-the-fly on most of
the Clojure data structures.

Timothy


On Tue, May 6, 2014 at 5:49 PM, Alex Miller  wrote:

> The Clojure persistent data structures are truly immutable - all fields
> are final and referred objects are not mutated after construction so that
> freeze occurs.  One obvious exception are the transient variants (
> http://clojure.org/transients). You can look at the code in
> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any
> of the Persistent*.java.
>
>
> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>
>> Are the persistent immutable data structures in Clojure "truly" immutable
>> (using final fields, relying on constructor freezing), or are they mean to
>> be merely effectively immutable (as defined in JICP)?
>>
>  --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Immutable or Effectively Immutable?

[Andy Fingerhut]

Alex, I may be unfamiliar with the definitions of truly immutable and
effectively immutable being used here, but if I can mutate the contents of
a Java Object array that is a final field after an object is constructed,
does it really matter that much if it is final?  It is trivially easy to
mutate using Java access.  Here is the example that I mentioned earlier in
this thread, copied here for convenience:

user=> (def v [1 2 3])
#'user/v
user=> (class v)
clojure.lang.PersistentVector
user=> v
[1 2 3]
user=> (aset (.tail v) 1 -2)
-2
user=> v
[1 -2 3]

Andy


On Tue, May 6, 2014 at 4:49 PM, Alex Miller  wrote:

> The Clojure persistent data structures are truly immutable - all fields
> are final and referred objects are not mutated after construction so that
> freeze occurs.  One obvious exception are the transient variants (
> http://clojure.org/transients). You can look at the code in
> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any
> of the Persistent*.java.
>
>
> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>
>> Are the persistent immutable data structures in Clojure "truly" immutable
>> (using final fields, relying on constructor freezing), or are they mean to
>> be merely effectively immutable (as defined in JICP)?
>>
>  --
> 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: clojure.test parameterized tests

[Sean Corfield]

http://jayfields.com/expectations/in-context.html

On May 6, 2014, at 12:14 PM, Brian Craft  wrote:
> Someone suggested the Expectations lib, but I don't see any fixture support 
> there. Anyone using Expectations that can point me to the right place?




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Immutable or Effectively Immutable?

[Michał Marczyk]

vec with a short array of objects is a special case in that it simply
puts the existing array in a PersistentVector wrapper:

user=> (def arr (object-array 16))
#'user/arr
user=> (doseq [i (range 16)] (aset arr i i))
nil
user=> (def v (vec arr))
#'user/v
user=> v
[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]
user=> (aset arr 0 :foo)
:foo
user=> v
[:foo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]

This works for up to 32 objects, as that is the number that fits in a PV tail.

No member access syntax here -- not sure if object-array/aset count as interop.

NB. vec's docstring is explicit about this.


On 7 May 2014 02:35, Andy Fingerhut  wrote:
> Alex, I may be unfamiliar with the definitions of truly immutable and
> effectively immutable being used here, but if I can mutate the contents of a
> Java Object array that is a final field after an object is constructed, does
> it really matter that much if it is final?  It is trivially easy to mutate
> using Java access.  Here is the example that I mentioned earlier in this
> thread, copied here for convenience:
>
> user=> (def v [1 2 3])
> #'user/v
> user=> (class v)
> clojure.lang.PersistentVector
> user=> v
> [1 2 3]
> user=> (aset (.tail v) 1 -2)
> -2
> user=> v
> [1 -2 3]
>
> Andy
>
>
> On Tue, May 6, 2014 at 4:49 PM, Alex Miller  wrote:
>>
>> The Clojure persistent data structures are truly immutable - all fields
>> are final and referred objects are not mutated after construction so that
>> freeze occurs.  One obvious exception are the transient variants
>> (http://clojure.org/transients). You can look at the code in
>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any of
>> the Persistent*.java.
>>
>>
>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>
>>> Are the persistent immutable data structures in Clojure "truly" immutable
>>> (using final fields, relying on constructor freezing), or are they mean to
>>> be merely effectively immutable (as defined in JICP)?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Immutable or Effectively Immutable?

[Mike Fikes]

Hi Andy,

Marking Java fields as final has semantics with respect to threading, 
defined in the JLS in section 17.5 
(http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#17.5)

If you do this, then it makes it possible to freely pass a "truly" 
immutable object instance to another thread and be guaranteed that that 
other thread will see the value initialized for that field in the 
constructor.

If you don't do this, then the object can still be "effectively" immutable, 
which essentially means that you can pass the object to another thread, so 
long as you do it in a safe manner (using a volatile, or some 
synchronization mechanism).

JCIP helps clarify all of this unfortunately complex topic.

The important thing (and key to Closure), is that, if you are implementing 
the class that you want to be immutable, then if you can mark everything as 
final, then you truly achieve the benefits immutability give you with 
concurrency (in short, you need no synchronization whatsoever). If you fail 
to do this, then you have "effective" immutability, which is good, but 
complex and comes with caveats on how you can safely pass objects between 
threads.

JCIP is a great book. But, the approach taken by Clojure makes a lot of the 
complicated concerns covered by the book largely ignorable, IMHO.

On Tuesday, May 6, 2014 8:35:43 PM UTC-4, Andy Fingerhut wrote:
>
> Alex, I may be unfamiliar with the definitions of truly immutable and 
> effectively immutable being used here, but if I can mutate the contents of 
> a Java Object array that is a final field after an object is constructed, 
> does it really matter that much if it is final?  It is trivially easy to 
> mutate using Java access.  Here is the example that I mentioned earlier in 
> this thread, copied here for convenience:
>
> user=> (def v [1 2 3])
> #'user/v
> user=> (class v)
> clojure.lang.PersistentVector
> user=> v
> [1 2 3]
> user=> (aset (.tail v) 1 -2)
> -2
> user=> v
> [1 -2 3]
>
> Andy
>
>
> On Tue, May 6, 2014 at 4:49 PM, Alex Miller 
> > wrote:
>
>> The Clojure persistent data structures are truly immutable - all fields 
>> are final and referred objects are not mutated after construction so that 
>> freeze occurs.  One obvious exception are the transient variants (
>> http://clojure.org/transients). You can look at the code in 
>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - 
>> any of the Persistent*.java.
>>
>>
>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>
>>> Are the persistent immutable data structures in Clojure "truly" 
>>> immutable (using final fields, relying on constructor freezing), or are 
>>> they mean to be merely effectively immutable (as defined in JICP)?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Proposing a new Clojure documentation system (in Clojure)

[Gregg Reynolds]

On Tue, May 6, 2014 at 2:22 PM, Tim Daly  wrote:

> Gregg,
>
> > My original comment on litprog ("bad bad bad") was admittedly a little
> > strong.  I think its bad for some things, fine for others.  And it's
> > possible litprog conventions will evolve to address the problems some of
> us
> > see with using it for programming in the large etc.
>
> Could you explain what "some of the problems some of us see with using
> it for programming in the large" might be? It is hard to refute
> "bad bad bad" and other assertions without specific examples.
>

Hi Tim,

I'm afraid it may take me a few days to find the time to respond properly.
In the meantime, aside from some of the responses in this thread, see
http://stackoverflow.com/questions/2545136/is-literate-programming-dead .

And here's a bit from Knuth (http://www-cs-faculty.stanford.edu/~uno/lp.html
):

"Literate programming  is a methodology
that combines a programming language with a documentation language, thereby
making programs more robust, more portable, more easily maintained, and
arguably more fun to write than programs that are written only in a
high-level language."

"[T]hereby"???  This is an obvious non-sequitur.  To my knowledge neither
Knuth nor anybody else has ever produced a shred of evidence in support of
this kind of claim.   Probably because it is false on the face of it.  Note
the implicit claim, that litprog is an "effective methodology" that, when
followed, "thereby" results in all sorts of smooth buttery goodness
(compare "effective procedure").  But litprog is a norm or style, not a
methodology.  It provides no rules (methods) that all by themselves bestow
excellence on your text.  You can write crappy literate programs.

He continues: "The main idea is to treat a program as a piece of
literature, addressed to human beings rather than to a computer."  *Rather*
than to a computer?  I think not; nobody is interested in programs,
literate or not, that computers do not understand.  Furthermore, program
text is, has always been, and always will be a form of literary text, by
definition.  Knuth's use of the term "literate programming" is a mere
rhetorical trick since it (falsely) implies that programming that does not
conform to his (very personal) notion of what counts as literate is ipso
facto illiterate.

Ross Williams (funnel web guy) (from http://www.literateprogramming.com/):

"A traditional computer program consists of a text file containing program
code. Scattered in amongst the program code are comments which describe the
various parts of the code...In literate programming the emphasis is
reversed. Instead of writing code containing documentation, the literate
programmer writes documentation containing code."

I consider this a major part of what "classic litprog" means, and I think
it is preposterous, to be honest.  Just think of code and documentation as
text and commentary.  One writes commentary about texts, not the other way
around.

Of course, this is not necessarily what everybody has in mind when they
hear "literate programming".  In fact I gather it is not uncommon for
people to use "literate programming" to refer to tools that merely support
some kind of structured documentation syntax mixed in with code together
with some kind of tools to support fancy typesetting.  On that view
javadocs counts as literate programming.  But I think that's a confusing
abuse of terminology, since that isn't what litprog originally meant.

There's a lot more to be said about it, of course, but that'll have to do
for now.

And on the other hand, I'm entirely pragmatic about this stuff.  If
something works and people use it, who am I to argue?  I just don't think
it (classic litprog) works, at least not for certain important classes of
problem (programming in the large, with distributed very heterogenous
groups of programmers, etc.)  But there are lots of good docs tools that
draw inspiration and techniques from classic litprog even if they
themselves don't fit the profile precisley.


> Axiom (1.2 million lines of lisp) is being rewritten into a literate
> program. So far I can't think of a problem. Clojure is being reworked
> into literate form already


That's news to me.  Are you saying the core Clojure team is rewriting
Clojure in *classic* litprog style?  That would flabber my gast, to put it
mildly.

-Gregg

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

Re: Immutable or Effectively Immutable?

[Mike Fikes]

Thanks!

I initially saw that the count field of ArrayNode (in PersistentHashMap) is 
non-final and also mutated in at least one case, and began to question 
things.

But, for that particular example, if that field is only mutated in the case 
of editing transients, then for the non-transient case ArrayNode is 
effectively immutable but also safely published by any truly immutable data 
structures by being referred to in final fields.

Excellent! I had to look for myself, and now I feel much more comfortable 
that Clojure is built upon the bedrock it needs to be :)

On Tuesday, May 6, 2014 7:49:07 PM UTC-4, Alex Miller wrote:
>
> The Clojure persistent data structures are truly immutable - all fields 
> are final and referred objects are not mutated after construction so that 
> freeze occurs.  One obvious exception are the transient variants (
> http://clojure.org/transients). You can look at the code in 
> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - any 
> of the Persistent*.java.
>
> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>
>> Are the persistent immutable data structures in Clojure "truly" immutable 
>> (using final fields, relying on constructor freezing), or are they mean to 
>> be merely effectively immutable (as defined in JICP)?
>>
>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Timothy Baldridge]

>> Clojure is being reworked into literate form already

Proof of this claim?




On Tue, May 6, 2014 at 7:32 PM, Gregg Reynolds  wrote:

> On Tue, May 6, 2014 at 2:22 PM, Tim Daly  wrote:
>
>> Gregg,
>>
>> > My original comment on litprog ("bad bad bad") was admittedly a little
>> > strong.  I think its bad for some things, fine for others.  And it's
>> > possible litprog conventions will evolve to address the problems some
>> of us
>> > see with using it for programming in the large etc.
>>
>> Could you explain what "some of the problems some of us see with using
>> it for programming in the large" might be? It is hard to refute
>> "bad bad bad" and other assertions without specific examples.
>>
>
> Hi Tim,
>
> I'm afraid it may take me a few days to find the time to respond
> properly.  In the meantime, aside from some of the responses in this
> thread, see
> http://stackoverflow.com/questions/2545136/is-literate-programming-dead .
>
> And here's a bit from Knuth (
> http://www-cs-faculty.stanford.edu/~uno/lp.html):
>
> "Literate programming  is a
> methodology that combines a programming language with a documentation
> language, thereby making programs more robust, more portable, more easily
> maintained, and arguably more fun to write than programs that are written
> only in a high-level language."
>
> "[T]hereby"???  This is an obvious non-sequitur.  To my knowledge neither
> Knuth nor anybody else has ever produced a shred of evidence in support of
> this kind of claim.   Probably because it is false on the face of it.  Note
> the implicit claim, that litprog is an "effective methodology" that, when
> followed, "thereby" results in all sorts of smooth buttery goodness
> (compare "effective procedure").  But litprog is a norm or style, not a
> methodology.  It provides no rules (methods) that all by themselves bestow
> excellence on your text.  You can write crappy literate programs.
>
> He continues: "The main idea is to treat a program as a piece of
> literature, addressed to human beings rather than to a computer."  *Rather*
> than to a computer?  I think not; nobody is interested in programs,
> literate or not, that computers do not understand.  Furthermore, program
> text is, has always been, and always will be a form of literary text, by
> definition.  Knuth's use of the term "literate programming" is a mere
> rhetorical trick since it (falsely) implies that programming that does not
> conform to his (very personal) notion of what counts as literate is ipso
> facto illiterate.
>
> Ross Williams (funnel web guy) (from http://www.literateprogramming.com/):
>
> "A traditional computer program consists of a text file containing program
> code. Scattered in amongst the program code are comments which describe the
> various parts of the code...In literate programming the emphasis is
> reversed. Instead of writing code containing documentation, the literate
> programmer writes documentation containing code."
>
> I consider this a major part of what "classic litprog" means, and I think
> it is preposterous, to be honest.  Just think of code and documentation as
> text and commentary.  One writes commentary about texts, not the other way
> around.
>
> Of course, this is not necessarily what everybody has in mind when they
> hear "literate programming".  In fact I gather it is not uncommon for
> people to use "literate programming" to refer to tools that merely support
> some kind of structured documentation syntax mixed in with code together
> with some kind of tools to support fancy typesetting.  On that view
> javadocs counts as literate programming.  But I think that's a confusing
> abuse of terminology, since that isn't what litprog originally meant.
>
> There's a lot more to be said about it, of course, but that'll have to do
> for now.
>
> And on the other hand, I'm entirely pragmatic about this stuff.  If
> something works and people use it, who am I to argue?  I just don't think
> it (classic litprog) works, at least not for certain important classes of
> problem (programming in the large, with distributed very heterogenous
> groups of programmers, etc.)  But there are lots of good docs tools that
> draw inspiration and techniques from classic litprog even if they
> themselves don't fit the profile precisley.
>
>
>> Axiom (1.2 million lines of lisp) is being rewritten into a literate
>> program. So far I can't think of a problem. Clojure is being reworked
>> into literate form already
>
>
> That's news to me.  Are you saying the core Clojure team is rewriting
> Clojure in *classic* litprog style?  That would flabber my gast, to put it
> mildly.
>
> -Gregg
>
>
> --
> 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
>

Re: Immutable or Effectively Immutable?

[Alex Miller]

Yes, there may be a few special cases out there, but largely around 
transients. The transient case constrains the mutability to a thread so 
still simplifies the concurrency safety story immensely.

On Tuesday, May 6, 2014 8:44:53 PM UTC-5, Mike Fikes wrote:
>
> Thanks!
>
> I initially saw that the count field of ArrayNode (in PersistentHashMap) 
> is non-final and also mutated in at least one case, and began to question 
> things.
>
> But, for that particular example, if that field is only mutated in the 
> case of editing transients, then for the non-transient case ArrayNode is 
> effectively immutable but also safely published by any truly immutable data 
> structures by being referred to in final fields.
>
> Excellent! I had to look for myself, and now I feel much more comfortable 
> that Clojure is built upon the bedrock it needs to be :)
>
> On Tuesday, May 6, 2014 7:49:07 PM UTC-4, Alex Miller wrote:
>>
>> The Clojure persistent data structures are truly immutable - all fields 
>> are final and referred objects are not mutated after construction so that 
>> freeze occurs.  One obvious exception are the transient variants (
>> http://clojure.org/transients). You can look at the code in 
>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - 
>> any of the Persistent*.java.
>>
>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>
>>> Are the persistent immutable data structures in Clojure "truly" 
>>> immutable (using final fields, relying on constructor freezing), or are 
>>> they mean to be merely effectively immutable (as defined in JICP)?
>>>
>>

-- 
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: Proposing a new Clojure documentation system (in Clojure)

[u1204]

Gregg,

I realize that literate programming isn't going to catch on in the
Clojure community any time soon. LP shared the "epiphany" feature
of Lisp. That is, you don't "get it" until the "AH HA!" moment,
and then you wonder why anyone programs any other way. You can't get
the Lisp AH HA! without writing Lisp, so many Java programmers will
never "get" Clojure. You can't get LP without writing LP, so many
programmers will never get LP. Oh well. I am trying to refocus on the
goal of "deep thinking" the documentation problem in Clojure.



My more recent posts have moved on from LP and have been focused on
finding criteria to judge whether proposed solutions actually address
useful goals. Parent tried to do that in his thesis. See my prior post.

There are many different audiences that need Clojure documentation. Some
are core maintainers who have to understand the Java code. Some are
programmers who need to understand the language. Some are library
maintainers who need to explain their use case. Some are people who join
a company using Clojure. Some are language designers who need to
understand principles like immutability, simplicity, STM, etc.

There are thousands of useful programs in github. Most of them are
dead because the original programmers are gone and nobody knows their
use case nor how to maintain and modify them. Once the original team
moves on even popular projects die. Even programs written by famous
people with huge amounts of influence die. Witness Arc by Paul Graham,
or Pascal which took over the world in the last century. Without Rich,
wither Clojure?

I really like Clojure and I want it to live. I believe that unless
we focus SOME effort on making it easy to maintain, modify, use, and
understand then Clojure will suffer the fate of Pascal, Arc, and that ilk.





>  To my knowledge neither
> Knuth nor anybody else has ever produced a shred of evidence in support of
> this kind of claim.

I can't speak to your knowledge but there are numerous examples. As to
the cited stackoverflow claim that LP is not used in projects or teaching...

Here is PROJECT example from SAGE, a python-based computer algebra
system in Number Theory:

"Another thing I've been enjoying lately is literate programming. 
 Amazingly it turns out to be faster to write a literate program 
 than an ordinary program because debugging takes almost no time."

-- Bill Hart, SAGE Mailing list, May 3, 2010

Here is a TEACHING example from Spring 2014:

John Kitchin is a professor of Chemical Engineering at CMU.  He is
teaching CMU students to use literate programming and uses it in all of
his courses. He recently gave a talk at PyCon

http://www.youtube.com/watch?v=1-dUkyn_fZA




> Are you saying the core Clojure team is rewriting
> Clojure in *classic* litprog style?  That would flabber my gast, to put it
> mildly.

No, "the core Clojure team" is NOT rewriting Clojure in *classic*
litprog style. I am, with the help of others. See
PDF: http://daly.axiom-developer.org/clojure.pdf
SRC: http://daly.axiom-developer.org/clojure.pamphlet

If you follow the instructions you can type 'make' which extracts
Clojure source code, compiles it, extracts and runs the test cases,
and puts you into a REPL. It also re-creates the PDF. The whole
process takes under a minute. LP is trivial to learn and use.

The cycle is to edit the file (code or natural language), type
'make', and your new code is built, tested, and ready to run. At
the same time the PDF of the book is recreated from the same source
so it is "up to the minute". Rinse and repeat.

The format supports images, hyperlinks, a table of contents, an
index, a bibliography, appendicies, diagrams, audio, and video. 

The hard part is "reading the code" and trying to reverse engineer
what the core Clojure team wrote. This is code written by the best
in the business. Despite that and contrary to popular belief, reading
someone else's code is NOT easy to do.

Tim










-- 
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: twitter-api and streaming calls

[Andrew Fitzgerald]

I had someone email me today asking for a code snippet of using the java 
twitter api, so I'll repost it here.
I'm fairly new to clojure so forgive me for the ugliness/lack of idiomatic 
code. It's a port of the java example code at 
https://github.com/twitter/hbc/blob/master/hbc-example/src/main/java/com/twitter/hbc/example/FilterStreamExample.java

with some additional logic to dump messages onto rabbitmq.

Clojure code here https://www.refheap.com/85199

Cheers,
Andrew Fitzgerald


On Friday, May 2, 2014 3:40:06 AM UTC-4, Simon Katz wrote:
>
> Thanks Andrew and Gary. You've saved me a lot of time!
>
>
> On Friday, 2 May 2014 02:43:51 UTC+1, Gary Trakhman wrote:
>>
>> Oh, nice, I was concerned about reconnections and backfill issues, if I 
>> have to change anything substantial again I'll reimplement on top of the 
>> java api that provides this out of the box.
>>
>>
>> On Thu, May 1, 2014 at 9:13 PM, Andrew Fitzgerald 
>> wrote:
>>
>>> I had the same (very frustrating issue) recently. I ended up just using 
>>> the official twitter API which is written in Java 
>>> https://github.com/twitter/hbc
>>>
>>>
>>> On Thursday, May 1, 2014 6:59:04 PM UTC-4, Simon Katz wrote:

 Hi,

 I'm playing with twitter-api (https://github.com/adamwynne/twitter-api) 
 and streaming calls. I've also tried twitter-streaming-client (
 https://github.com/mccraigmccraig/twitter-streaming-client).

 With the examples each of those provide, I'm getting *EOFException: 
 JSON error (end-of-file)* errors.

 I can of course post more details, but I'm hoping someone else might 
 have come across this and be able to give me a pointer as to what's 
 happening.

 I wonder if perhaps something's changed in the Twitter API recently to 
 break things.

 __
 Simon

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

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

Re: Immutable or Effectively Immutable?

[Alex Miller]

Hey Andy,

It does matter with regard to visibility across threads - your example does 
not use a synchronization mechanism and there is no guarantee that other 
threads will ever see those changes (so don't ever ever do that :). But if 
you stick to the normal Clojure apis, all is good. I'd highly recommend 
reading JCIP to dive into the details. 

Final field freeze is particularly weird and it baked my noodle when I 
first encountered it - here's a blog I wrote about it approx 697 years ago 
in internet time (and Brian Goetz backs me up in the comments :)
http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/

Alex


On Tuesday, May 6, 2014 7:35:43 PM UTC-5, Andy Fingerhut wrote:
>
> Alex, I may be unfamiliar with the definitions of truly immutable and 
> effectively immutable being used here, but if I can mutate the contents of 
> a Java Object array that is a final field after an object is constructed, 
> does it really matter that much if it is final?  It is trivially easy to 
> mutate using Java access.  Here is the example that I mentioned earlier in 
> this thread, copied here for convenience:
>
> user=> (def v [1 2 3])
> #'user/v
> user=> (class v)
> clojure.lang.PersistentVector
> user=> v
> [1 2 3]
> user=> (aset (.tail v) 1 -2)
> -2
> user=> v
> [1 -2 3]
>
> Andy
>
>
> On Tue, May 6, 2014 at 4:49 PM, Alex Miller 
> > wrote:
>
>> The Clojure persistent data structures are truly immutable - all fields 
>> are final and referred objects are not mutated after construction so that 
>> freeze occurs.  One obvious exception are the transient variants (
>> http://clojure.org/transients). You can look at the code in 
>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - 
>> any of the Persistent*.java.
>>
>>
>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>
>>> Are the persistent immutable data structures in Clojure "truly" 
>>> immutable (using final fields, relying on constructor freezing), or are 
>>> they mean to be merely effectively immutable (as defined in JICP)?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Immutable or Effectively Immutable?

[Alex Miller]

True! Hash codes are a special case - the pattern they use is sometimes 
called the "racy single-check idiom" and is discussed in Effective Java in 
Item 71 or on an internet near you. The canonical example of this is 
java.lang.String. The trick is that if you don't have a non-0 hash code, 
compute it yourself and stash it. If threads happen to see it, they can use 
it! If they don't see it, they compute it themselves. If two threads race, 
they write the *same* value, so everyone is fine. One important aspect is 
that the hash code must be an int which can be written atomically; if it 
was a long, you'd potentially be subject to long tearing.  

As of Clojure 1.6, Symbols also use this idiom for hasheq. Keywords do not 
- the assumption with keywords is that they are likely to be used as keys 
and so the hasheq is pre-computed and cached during construction (but 
keywords are re-used so this is only done once per keyword).


On Tuesday, May 6, 2014 7:07:37 PM UTC-5, tbc++ wrote:
>
> And hash codes are not final as they are calculated on-the-fly on most of 
> the Clojure data structures. 
>
> Timothy
>
>
> On Tue, May 6, 2014 at 5:49 PM, Alex Miller 
> > wrote:
>
>> The Clojure persistent data structures are truly immutable - all fields 
>> are final and referred objects are not mutated after construction so that 
>> freeze occurs.  One obvious exception are the transient variants (
>> http://clojure.org/transients). You can look at the code in 
>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang - 
>> any of the Persistent*.java.
>>
>>
>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>
>>> Are the persistent immutable data structures in Clojure "truly" 
>>> immutable (using final fields, relying on constructor freezing), or are 
>>> they mean to be merely effectively immutable (as defined in JICP)?
>>>
>>  -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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