date:20140506

2014-05-05 22:08 GMT+02:00 mynomoto mynom...@gmail.com:

 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

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

2014-05-05 12:17 GMT+02:00 Magnus Therning mag...@therning.org:

 On Mon, May 5, 2014 at 10:20 AM, Cecil Westerhof cldwester...@gmail.com
 wrote:
  2014-05-05 8:21 GMT+02:00 Magnus Therning mag...@therning.org:
 
  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

2014-05-05 19:48 GMT+02:00 Brian Craft craft.br...@gmail.com:

 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

2014-05-06 Thread Magnus Therning

On Tue, May 6, 2014 at 9:45 AM, Cecil Westerhof cldwester...@gmail.com wrote:
 2014-05-05 19:48 GMT+02:00 Brian Craft craft.br...@gmail.com:
 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

2014-05-06 Thread 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 rwob...@hotmail.com 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



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

2014-05-06 Thread 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 cldwester...@gmail.com 
 wrote:
  2014-05-05 19:48 GMT+02:00 Brian Craft craft.br...@gmail.com:
  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 Prefontainelprefonta...@softaddicts.ca 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)

2014-05-06 Thread Phillip Lord

Gregg Reynolds d...@mobileink.com 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?

2014-05-06 Thread 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 netty adapter library
  [ring-netty-adapter 0.0.3]

 Also didn't work... for now I commented this line out, since it's not 
 necessary to get my curl test working. But it would be nice if you provide 
 the dependencies.



 Am Donnerstag, 24. April 2014 08:51:29 UTC+2 schrieb Erik Bakstad:
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this

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

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

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 rwob...@hotmail.com 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

2014-05-06 Thread 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 s...@corfield.org 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 dave.te...@gmail.com 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?

2014-05-06 Thread 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://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 netty adapter library
  [ring-netty-adapter 0.0.3]

 Also didn't work... for now I commented this line out, since it's not 
 necessary to

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



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 rwo...@hotmail.com javascript: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.comjavascript:
 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 javascript:
 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 javascript:.
 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

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 rwob...@hotmail.com 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 rwo...@hotmail.com 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

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

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

2014-05-06 Thread Gary Trakhman

Last + butlast?

On Tuesday, May 6, 2014, Roelof Wobben rwob...@hotmail.com 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.comjavascript:_e(%7B%7D,'cvml','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.comjavascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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.comjavascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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

2014-05-06 Thread 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

2014-05-06 Thread 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 zhi.y...@yottaa.com:

 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 - Андрей Антух - andrei.anto...@kaleidos.net / n...@niwi.be

http://www.niwi.be http://www.niwi.be/page/about/
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

2014-05-06 Thread 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

2014-05-06 Thread 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

2014-05-06 Thread 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

2014-05-06 Thread 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

2014-05-06 Thread 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 
http://grinder.sourceforge.net/ may complete your toolbox since it 
support scenario scripting in clojure 
http://grinder.sourceforge.net/g3/clojure.html.


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

2014-05-06 Thread François Rey

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


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

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 rwob...@hotmail.com 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

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

On 6 May 2014 13:09, Gary Trakhman gary.trakh...@gmail.com 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 rwob...@hotmail.com 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)

On Tue, May 6, 2014 at 4:53 AM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:

 Gregg Reynolds d...@mobileink.com 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 https://github.com/mobileink/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.ditamaphttps://github.com/mobileink/leiningen-doc/blob/master/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
codegenreshttps://github.com/mobileink/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 to doc features, I

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



On Tuesday, May 6, 2014 4:53:36 AM UTC-5, Phillip Lord wrote:

 Gregg Reynolds d...@mobileink.com javascript: 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


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

2014-05-06 Thread 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.htmlis 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 https://www.youtube.com/watch?v=XMIKfOmAMjQ
2. Video 2 of 3 https://www.youtube.com/watch?v=QPN2DFrlrYo
3. Video 3 of 3 https://www.youtube.com/watch?v=iQK9p0XV2IY
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 http://www.youtube.com/watch?v=Ty9QDqV-_Ak 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.
Systronixhttp://www.systronix.com/),
or on something like a Beaglebone or Beagleboard? I'm very new to
Clojure,
so I don't yet understand the challenges that Clojure would face
trying to
run on a system that may not support all the JVM's features.

Any thoughts on this? Any links you can give me on what's been/being
done?

Thanks.

--
And what is

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

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

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 rwo...@hotmail.com javascript: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

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)

2014-05-06 Thread Phillip Lord

Gregg Reynolds d...@mobileink.com 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 https://github.com/mobileink/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.ditamaphttps://github.com/mobileink/leiningen-doc/blob/master/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 /concept 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 post to this group, send email to clojure@googlegroups.com
Note that posts from

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

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 rwob...@hotmail.com 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 rwo...@hotmail.com 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

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 rwo...@hotmail.com javascript: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 rwo...@hotmail.com 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)

2014-05-06 Thread Phillip Lord

Mars0i marsh...@logical.net 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

2014-05-06 Thread 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

2014-05-06 Thread 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

2014-05-06 Thread 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 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

 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 cldwester...@gmail.com
 wrote:
   2014-05-05 19:48 GMT+02:00 Brian Craft craft.br...@gmail.com:
   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 Prefontainelprefonta...@softaddicts.ca 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)

On Tue, May 6, 2014 at 10:11 AM, Phillip Lord
phillip.l...@newcastle.ac.ukwrote:

 Gregg Reynolds d...@mobileink.com 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
firsthttp://clojure.github.io/clojure/clojure.core-api.html#clojure.core/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 https://github.com/mobileink/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.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:

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

On Sat, May 3, 2014 at 3:46 PM, Val Waeselynck val.vval...@gmail.comwrote:

 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

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 gary.trakh...@gmail.comwrote:

 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)

2014-05-06 Thread Sean Corfield

On May 6, 2014, at 8:11 AM, Phillip Lord phillip.l...@newcastle.ac.uk 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)

2014-05-06 Thread Mark Engelberg

On Tue, May 6, 2014 at 9:56 AM, Sean Corfield s...@corfield.org 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)

 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

2014-05-06 Thread 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 akme...@gmail.com 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;; = {#AsyncChannel 
 /0:0:0:0:0:0:0:1%0:-/0:0:0:0:0:0:0:1%0:60071
 true}
 (into {} clients) ; = #ManyToManyChannel clojure.core.async.impl.
 channels.ManyToManyChannel@5d9c832a
 I get IllegalArgumentException java.lang.IllegalArgumentException: No
 implementation of method: :take! of protocol: 
 #'clojure.core.async.impl.protocols/ReadPort
 found for class: nil
 AsyncChannel is from http-kit

 and
 (merge {} clients) ;; #ManyToManyChannel clojure.core.async.impl.
 channels.ManyToManyChannel@5d9c832a

 How {#AsyncChannel /0:0:0:0:0:0:0:1%0:-/0:0:0:0:0:0:0:1%0:60071
 true} is transformed to #ManyToManyChannel clojure.core.async.impl.
 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)

 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)

2014-05-06 Thread 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 se...@corfield.orgjavascript:
  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 predocstring here/pre 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)

2014-05-06 Thread 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)

2014-05-06 Thread Sean Corfield

On May 6, 2014, at 10:41 AM, Mark Engelberg mark.engelb...@gmail.com 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

2014-05-06 Thread 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 craft...@gmail.com 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?

2014-05-06 Thread 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)

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?

2014-05-06 Thread Timothy Washington

Hi there,


*A)* I'm just writing some SOAP XML, trying to use
data.xmlhttps://github.com/clojure/data.xml.
This SO 
threadhttp://stackoverflow.com/questions/10868050/clojure-data-xml-create-key-named-xlinkhref
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
Supporthttp://dev.clojure.org/display/DXML/Fuller+XML+supportproposal
(referring to this
threadhttps://groups.google.com/forum/#!msg/clojure-dev/3_jkBrdQKgs/dUwtevWqlwkJ),
and this Namespaced XML
http://dev.clojure.org/display/DXML/Namespaced+XMLproposal. But I
don't see that namespaces are fully implemented in any of
the core libs.

I only see this ArmageDOM https://github.com/pepijndevos/ArmageDOM lib,
which supports namespaces. Anything else out there that I've missed?


Thanks

Tim Washington
Interruptsoftware.com http://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?

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)

 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?

2014-05-06 Thread 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)

?xml version=1.0 encoding=UTF-8?
root xmlns:thing=http://thing;
  thing:use/
/root

user (print-esequel process/e3)

?xml version=1.0 encoding=UTF-8?
root xmlns:thing=http://thing;
  thing:first
thing:second/
  /thing:first
/root



Tim Washington
Interruptsoftware.com http://interruptsoftware.com


On Tue, May 6, 2014 at 3:24 PM, Timothy Washington twash...@gmail.comwrote:

 Hi there,


 *A)* I'm just writing some SOAP XML, trying to use 
 data.xmlhttps://github.com/clojure/data.xml.
 This SO 
 threadhttp://stackoverflow.com/questions/10868050/clojure-data-xml-create-key-named-xlinkhref
  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 
 Supporthttp://dev.clojure.org/display/DXML/Fuller+XML+supportproposal 
 (referring to this
 threadhttps://groups.google.com/forum/#!msg/clojure-dev/3_jkBrdQKgs/dUwtevWqlwkJ),
 and this Namespaced 
 XMLhttp://dev.clojure.org/display/DXML/Namespaced+XMLproposal. But I don't 
 see that namespaces are fully implemented in any of
 the core libs.

 I only see this ArmageDOM https://github.com/pepijndevos/ArmageDOM lib,
 which supports namespaces. Anything else out there that I've missed?


 Thanks

 Tim Washington
 Interruptsoftware.com http://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?

2014-05-06 Thread 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)

?xml version=1.0 encoding=UTF-8?
thing:first xmlns:thing=http://thing;
  thing:second/
/thing:first



Tim Washington
Interruptsoftware.com http://interruptsoftware.com


On Tue, May 6, 2014 at 3:45 PM, Timothy Washington twash...@gmail.comwrote:

 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)

 ?xml version=1.0 encoding=UTF-8?
 root xmlns:thing=http://thing;
   thing:use/
 /root

 user (print-esequel process/e3)

 ?xml version=1.0 encoding=UTF-8?
 root xmlns:thing=http://thing;
   thing:first
 thing:second/
   /thing:first
 /root



 Tim Washington
 Interruptsoftware.com http://interruptsoftware.com


 On Tue, May 6, 2014 at 3:24 PM, Timothy Washington twash...@gmail.comwrote:

 Hi there,


 *A)* I'm just writing some SOAP XML, trying to use 
 data.xmlhttps://github.com/clojure/data.xml.
 This SO 
 threadhttp://stackoverflow.com/questions/10868050/clojure-data-xml-create-key-named-xlinkhref
  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 
 Supporthttp://dev.clojure.org/display/DXML/Fuller+XML+supportproposal 
 (referring to this
 threadhttps://groups.google.com/forum/#!msg/clojure-dev/3_jkBrdQKgs/dUwtevWqlwkJ),
 and this Namespaced 
 XMLhttp://dev.clojure.org/display/DXML/Namespaced+XMLproposal. But I don't 
 see that namespaces are fully implemented in any of
 the core libs.

 I only see this ArmageDOM https://github.com/pepijndevos/ArmageDOMlib, 
 which supports namespaces. Anything else out there that I've missed?


 Thanks

 Tim Washington
 Interruptsoftware.com http://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

2014-05-06 Thread 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 jason.m.fel...@gmail.comwrote:

 The form should be:

 (:import [org.sat4j.core Vec]) ; note the square braces.


 On Mon, May 5, 2014 at 3:29 PM, Ronan BARZIC rbar...@gmail.com 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.VecT
 not org.ow2.sat4j.core.VecT.
 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?

2014-05-06 Thread 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?

2014-05-06 Thread 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 mikefi...@me.com 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)

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

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

2014-05-06 Thread 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 akm...@gmail.comjavascript:
  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;; = {#AsyncChannel 
 /0:0:0:0:0:0:0:1%0:-/0:0:0:0:0:0:0:1%0:60071 
 true}
 (into {} clients) ; = #ManyToManyChannel clojure.core.async.impl.
 channels.ManyToManyChannel@5d9c832a
 I get IllegalArgumentException java.lang.IllegalArgumentException: No 
 implementation of method: :take! of protocol: 
 #'clojure.core.async.impl.protocols/ReadPort 
 found for class: nil
 AsyncChannel is from http-kit

 and
 (merge {} clients) ;; #ManyToManyChannel clojure.core.async.impl.
 channels.ManyToManyChannel@5d9c832a

 How {#AsyncChannel /0:0:0:0:0:0:0:1%0:-/0:0:0:0:0:0:0:1%0:60071 
 true} is transformed to #ManyToManyChannel clojure.core.async.impl.
 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.comjavascript:
 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 javascript:
 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 javascript:.
 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?

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?

2014-05-06 Thread 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 a...@puredanger.com 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?

2014-05-06 Thread 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 a...@puredanger.com 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

2014-05-06 Thread Sean Corfield

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

On May 6, 2014, at 12:14 PM, Brian Craft craft.br...@gmail.com 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?

2014-05-06 Thread 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 andy.finger...@gmail.com 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 a...@puredanger.com 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?

2014-05-06 Thread 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 al...@puredanger.comjavascript:
  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.comjavascript:
 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 javascript:
 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 javascript:.
 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)

On Tue, May 6, 2014 at 2:22 PM, Tim Daly d...@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.


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 http://www.literateprogramming.com 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

Re: Immutable or Effectively Immutable?

2014-05-06 Thread 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)

2014-05-06 Thread 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 d...@mobileink.com wrote:

 On Tue, May 6, 2014 at 2:22 PM, Tim Daly d...@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.


 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 http://www.literateprogramming.com 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

Re: Immutable or Effectively Immutable?

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)

2014-05-06 Thread 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

2014-05-06 Thread 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 
 andrewcf...@gmail.comwrote:

 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?

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 al...@puredanger.comjavascript:
  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.comjavascript:
 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 javascript:
 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 javascript:.
 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?