Re: grouping and mapping

[miner]

If your data elements are essentially map-entries (key-value pairs), I'd 
use reduce.  Maybe something like this would work for you...

(defn mapping-group-by [grouping-fn mapping-fn coll]
  (reduce (fn [res [k v]] (update res k grouping-fn (mapping-fn v)))
  {}
  coll))

(def foos [[:a "foo"]  [:b "bar"]  [:a "baz"]])

(mapping-group-by conj clojure.string/upper-case foos)
;;=> {:a ("BAZ" "FOO"), :b ("BAR")}

If you need vector values, you can wrap `conj` with `fnil` to get a vector.

(mapping-group-by (fnil conj []) clojure.string/upper-case foos)
;;=> {:a ["FOO" "BAZ"] :b ["BAR"]}

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

[miner]

 

It looks like the problem is with the macro -inc.  It should quote the 
internal fn name so that it stays an unqualified symbol during macro 
expansion.  I need to test this a bit as I’m not familiar with this code. 
 I’ll make a patch soon if David doesn’t fix it first.


By the way, spec pointed me to the right place, but I didn’t see the 
problem at first.  Maybe the spec needs to be improved here to test the 
internal name.  I’ll have to look at that later.


If you just want to get going, here the quick fix...


diff --git a/src/main/clojure/clojure/core/logic.clj 
b/src/main/clojure/clojure/core/logic.clj

index 3e98397..2dcb818 100644

--- a/src/main/clojure/clojure/core/logic.clj

+++ b/src/main/clojure/clojure/core/logic.clj

@@ -1075,7 +1075,7 @@

  `(mplus ~e (fn [] (mplus* ~@e-rest)

 

 (defmacro -inc [& rest]

-  `(fn -inc [] ~@rest))

+  `(fn ~'-inc [] ~@rest))

 

On Tuesday, September 13, 2016 at 3:45:18 AM UTC-4, Burt wrote:
>
> Hi,
>
> with "1.9.0-alpha10" and core.logic "0.8.10":
>
> (ns lwb.nd.rules
>   (:refer-clojure :exclude [==])
>   (:require [clojure.core.logic :refer :all]))
> => nil
>
> with "1.9.0-alpha12" and core.logic "0.8.10":
>
> (ns lwb.nd.rules
>   (:refer-clojure :exclude [==])
>   (:require [clojure.core.logic :refer :all]))
> CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/fn did 
> not conform to spec:
> In: [0] val: clojure.core.logic/-inc fails spec: 
> :clojure.core.specs/arg-list at: [:args :bs :arity-1 :args] predicate: 
> vector?
> In: [0] val: clojure.core.logic/-inc fails spec: 
> :clojure.core.specs/args+body at: [:args :bs :arity-n] predicate: (cat 
> :args :clojure.core.specs/arg-list :prepost (? map?) :body (* any?))
> :clojure.spec/args  (clojure.core.logic/-inc [] (bind (this) g))
>  #:clojure.spec{:problems ({:path [:args :bs :arity-1 :args], :pred 
> vector?, :val clojure.core.logic/-inc, :via [:clojure.core.specs/args+body 
> :clojure.core.specs/arg-list :clojure.core.specs/arg-list], :in [0]} {:path 
> [:args :bs :arity-n], :pred (cat :args :clojure.core.specs/arg-list 
> :prepost (? map?) :body (* any?)), :val clojure.core.logic/-inc, :via 
> [:clojure.core.specs/args+body :clojure.core.specs/args+body], :in [0]}), 
> :args (clojure.core.logic/-inc [] (bind (this) g))}, 
> compiling:(clojure/core/logic.clj:1130:5) 
>
> Is there already a fix for this?
>
> Kind regards,
> Burt
>
>

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

[miner]

(dosync (alter congrats conj (System/getProperty "user.name")))

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

contrib javalog depends on Java 6

[miner]

I'm just getting started with Clojure.  I had a small issue trying to
build the clojure-contrib project.  I'm on an old PPC Mac with only
Java 5.  The javalog.clj file requires Java 6.

There's an easy fix for javalog.clj.  GLOBAL_LOGGER_NAME is always
just "global", so you can use the literal value and have backwards
compatibility.

-(getLogger
- (. Logger GLOBAL_LOGGER_NAME
+(getLogger "global")))

https://www.darkcornersoftware.com/confluence/display/open/Logger.global+Deprecated+in+Java+6

In searching through the discussion archives, I noticed that Rich
Hickey wants to stay with Java 5 for now.  I think this is a good
policy and makes for easy adoption.

http://groups.google.com/group/clojure/msg/de3812c16723e1a9?hl=en

Since javalog.clj is considered deprecated, you could simply remove
it.  Or take it out of the default build for clojure-contrib.  If you
want to get fancier, you could segregate Java 6 dependencies and make
a special ant target for people who don't mind depending on Java 6.
The point is to make it easy to build for people who have only Java 5,
which is the stated requirement 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
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: hammock driven development...

[miner]

Here's some more support for the hammock:

http://www.npr.org/blogs/health/2011/06/20/137300311/why-hammocks-make-sleep-easier-deeper

> Rocking increased the length of N2 sleep, a form of non-REM sleep that takes 
> up about half of a good night's rest. It also increased slow oscillations and 
> "sleep spindles." Sleep spindles are brief bursts of brain activity, which 
> look like sudden up-and-down scribbles on an electroencephalogram.

> "We were basically trying to find a scientific demonstration of this notion 
> of rocking to sleep,"Michel Muehlethaler, a professor of neuroscience who 
> conducted the research with Schwartz, tells Shots. The fact that the brain 
> waves changed so much, he says, was "totally unexpected." The results were 
> published in the journal Current Biology.

> Sleep spindles are associated with tranquil sleep in noisy environments and 
> may be a sign that the brain is trying to calm sleepers stuck in them. 
> Spindles also have been linked with the ability to remember new information. 
> And that is associated with the brain's ability to rewire itself, known as 
> brain plasticity.

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

Re: Enhanced Primitive Support

[miner]

On Jun 18, 8:49 am, Rich Hickey  wrote:
> Fixing it requires adopting a single  
> semantic for +. Choosing auto-promotion precludes the use of + on  
> primitives, a huge loss IMO. Choosing throw-on-overflow precludes auto-
> promotion, but preserves polymorphism otherwise, and gives the  
> compiler free reign to optimize since it will never be altering the  
> semantics by doing so.
>
> I don't see a way around this fundamental dichotomy. The semantics for  
> + should be unified, and the operator that makes the other choice  
> needs to be called something else, or placed somewhere else.

I'm just a newbie here, but I would prefer the simpler and faster +
(with throw-on-overflow).  I don't want to annotate my arguments
(carefully!) to get primitive performance.  I want the best
performance in the simple cases.  The primitive domain is big enough
for most programs.

I would be willing to use separate function names ("auto-promo-+",
etc.) to get the "safe" auto-promotion semantics.  Perhaps they could
be in a separate namespace so that you can make your + symbol refer to
the auto-promoting one if you want to pay the cost.  By the way, I
also want to know if a library is using auto-promotion so that I can
avoid it unless I really need it.  And, yes, I think I'll know enough
about my domain to make that decision.

Steve Miner

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

Re: ops' macro to tidy +', -', *', /' operations?

[miner]

I'd call it with-auto-promotion.

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

Re: Counterclockwise version 0.0.59.RC2

[miner]

First, thanks for your work.  I appreciate it.  Now some comments:

"Select top level s-expression" and "evaluate current selection or top-
level s-expression" should act on the sexp in front of the cursor,
especially if the cursor is at the end of an sexp.  When I tried it, I
was getting the next sexp even when it was a couple of lines below the
cursor.

"Load clojure file in REPL" should start a REPL if there isn't one
already.

In general, I would prefer not to have hierarchical menus, especially
when there aren't so many menu items to begin with.

New feature request: I would like to be able to double-click on a
paren or bracket to select the enclosed element.  (Same operation as
"Expand selection to... enclosing element".)

By the way, I let Eclipse install the new version (RC2) without
uninstalling the old one (plain 0.0.58 I think).  It seems like it
worked OK.

Thanks,
Steve

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

Re: Counterclockwise version 0.0.59.RC2

[miner]

Many years of Emacs have trained me to expect evaluation of the form
before the cursor.  For example, with | standing for the cursor
position:

--
(+ 3 4)|

(* 2 3)
--

I expect to evaluate (+ 3 4).  Often I put my cursor right after an
expression just so I can execute it.  Again, that's how Emacs does
it.  This also makes it convenient to type and expression and evaluate
it immediately without having to move the cursor.

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

Re: Variadic arguments and macros

[miner]

I think you're missing a quote in your original macro.
You wrote:
 (defmacro foo [& xs] `(map identity ~xs))

Try this in a REPL:

user=> (macroexpand-1 '(foo 1 2))
(clojure.core/map clojure.core/identity (1 2))

That shows you that it's going to try to evaluate the form (1 2). The
original complaint is that 1 is not a function.  Using the vector
notation [] created a literal vector which works without quoting.

Try this instead:

user=> (defmacro foo [& xs] `(map identity (quote ~xs)))
#'user/foo
user=> (foo 1 2)
(1 2)

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

Re: faster flatten?

[miner]

I think it's worthwhile to have a faster flatten even if it doesn't
look as elegant as the current implementation.  You could do a bit of
refactoring and save yourself a call to sequential? since the
recursive calls are guaranteed to have seqs (as a result of next).

Also, I'd prefer flatten to return the argument if it isn't
sequential? so for example, (flatten 10) ==> 10.  I think it would be
less likely to give mysterious results, especially with mistaken
arguments.  I understand that the current flatten for 1.2 beta doesn't
do this -- I'm just throwing in another suggestion after playing with
it for a while.

Here's my suggestion:

(defn fl1 "faster flatten" [coll]
  (letfn [(flcoll [coll]
 (lazy-seq
  (when-let [c (seq coll)]
(let [x (first c)
  nxt (flcoll (next c))]
  (if (sequential? x)
(concat (flcoll x) nxt)
(cons x nxt))]
(if (sequential? coll) (flcoll coll) coll)))

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

Re: better way to group consecutive numbers in a vector?

[Steve Miner]

I would try to avoid last and but-last as they work in linear time.  How about 
something like this?

(defn congeal-consecutives [coll] 
  (when (seq coll) 
(let [[_ group res] (reduce (fn [[succ group res] n] 
(if (== succ n) 
[(inc n) (conj group n) res] 
[(inc n) [n] (conj res group)])) 
   [(nth coll 0) [] []] 
   coll)]
   (conj res group


> On Nov 6, 2014, at 5:22 PM, John Gabriele  wrote:
> 
> Hi all,
> 
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
> 
> That is, I'd like to group consecutive numbers together (the final goal being 
> to produce something like `["1" "3-5" "7" "9-12"]`, but that's the easy part).
> 
> I haven't found an easy way to do this. Here's what I've come up with in 
> Clojure:
> 
> ~~~clojure
> #!/usr/bin/env lein-exec
> 
> (def v [1 3 4 5 7 9 10 11 12])
> 
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
> 
> (prn (congeal-consecutives v))

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

Re: [ANN] Clojure 1.7.0-alpha5 now available

[Steve Miner]

Alpha5 works for me.

I noticed that the doc-string for *unchecked-math* doesn't mention the 
:warn-on-boxed behavior.  

Suggestion:  "While bound to true, compilations of +, -, *, inc, dec and the 
coercions will be done without overflow checks. While bound to :warn-on-boxed, 
a warning will be emitted when compilation uses boxed math. Default: false."


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

Re: [ANN] dformat 0.1.0

[Steve Miner]

Clever.  The doc-strings for dformatter and dformat could use a little work.  
Remember, people will use (doc whatever) in the REPL so “same as above” isn’t 
very useful.  Also, the dformatter doc implies more arguments than it actually 
takes.  The order of arguments to dformat seems backwards to me -- usually the 
"format" arg comes before the value to be formatted.

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

[Steve Miner]

Looks like a bug in clojure.pprint/print-table.  Probably should be use 
`pr-str` instead of `str`.

user=> (str ())
"clojure.lang.PersistentList$EmptyList@1"
user=> (pr-str ())
"()"



> On Feb 2, 2015, at 3:10 PM, John Lawrence Aspden  
> wrote:
> 
> These behave differently in 1.6 with respect to printing the empty list:
> 
> (clojure.pprint/print-table (list {:a 1  :b 2 :c '()}))
> | :a | :b |  :c |
> |++-|
> |  1 |  2 | clojure.lang.PersistentList$EmptyList@1 |
> 
> (clojure.pprint/pprint {:a 1  :b 2 :c '()})
> {:a 1, :b 2, :c ()}
> 
> Is this a bug?
> 
> I think I prefer the behaviour of the second one .
> 
> Cheers, John.

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

[Steve Miner]

In any case, it would be nice if (str ()) returned “()”.  By the way, (str {}) 
returns "{}" and (str []) returns "[]” as I would expect.

I just filed CLJ-1653.Seems like the simple fix is to add a toString() 
method for PersistentList.EmptyList.

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

[Steve Miner]

Clojure doesn't give you direct access to the name of the function you're 
defining.  However, you could use a macro to get that.  Here’s one way.  This 
macro binds the strange symbol %0 to  the symbol naming the current function.

;; %0 is bound to the function's symbolic name within the function.  Useful for 
pre-conditions,
;; logging and error reporting.
(defmacro defn0 [fname & fdcls]
  `(let [~'%0 (symbol (name (ns-name *ns*)) (name '~fname))]
 (defn ~fname ~@fdcls)))

;; For example...
(defn0 my-func [x]  
  (println "calling" %0 x)  
  (+ x 3))

user=> (my-func 11)
calling user/my-func 11
14

The downside to using something like this is that other people might have a 
harder time reading your code.  I thought it was clever when I wrote it, but I 
don't actually use it much.


> On Feb 14, 2015, at 11:11 AM, Cecil Westerhof  wrote:
> 
> In Bash I use the following construct:
> printf "${FUNCNAME} needs an expression\n"
> 
> In this way I do not have to change the print statement when the name of the 
> function changes. Is something like this also possible in clojure?

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

Re: Lucky numbers

[Steve Miner]

> On Feb 17, 2015, at 4:39 PM, Colin Jones  wrote:
> 
> Sounds almost like a mirror image of `clojure.core/take-nth`, so something 
> like this is kind of fun:
> 
> (defn drop-nth [n coll] 
>   (lazy-seq 
> (when-let [s (seq coll)] 
>   (concat (take (dec n) s) (drop-nth n (drop n s))
> 

I like that drop-nth.  Here's my version of lucky:

(defn lucky
  "Returns sequence of Lucky numbers less than max"
  ([max] (when (pos? max) (lucky 1 (range 1 max 2
  ([i acc]
   (if-let [n (nth acc i nil)]
 (recur (inc i) (drop-nth n acc))
 acc)))

The recur in this case loops back to the top.

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

[Steve Miner]

One more try.  This time using the int-map contrib library. (Thanks to Zack 
Tellman.) 

Warning: I'm assuming that the int-set seq is automagically sorted so I can 
reliably turn it back into a vector without sorting.  It seems to be stable at 
least.  I wanted a vector for fast nth access.  (Nth and count are constant 
time on vectors.)  I thought it would be slow to make the vector every round, 
but it runs pretty fast.  For small values of max, it was necessary to guard 
the nth access with the not-found nil.

(require '[clojure.data.int-map :as im])

(defn lucky3
  ([max] (lucky3 1 (im/dense-int-set (range 1 max 2
  ([i iset]
   (let [v (vec (seq iset))
 n (nth v i nil)]
 (if (and n (<= n (count v)))
   (recur (inc i) (reduce (fn [sss m] (disj sss (nth v m)))
  iset
  (range (dec n) (count v) n)))
   (sequence iset)


user=> (time (count (lucky3 1e6)))
"Elapsed time: 48905.491951 msecs"
71918

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

[Steve Miner]

I found a better data structure for calculating lucky numbers.  The contrib 
library data.avl (from Michał Marczyk) has a persistent sorted-set that 
supports nth.  This runs much faster than my previous attempts.

(require '[clojure.data.avl :as avl])

(defn lucky-avl
 ([max] (lucky-avl 1 (apply avl/sorted-set (range 1 max 2
 ([i avl]
  (let [n (nth avl i nil)]
(if (and n (<= n (count avl)))
  (recur (inc i) (reduce (fn [sss m] (disj sss (nth avl m)))
 avl
 (range (dec n) (count avl) n)))
  (sequence avl)

(time (count (lucky-avl 1e6)))
"Elapsed time: 2396.158435 msecs"
71918

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

[Steve Miner]

The edn format does not include records.  The transit README gives an example 
of how to write a transit handler for a record.  See the section on 
extensibility.

https://github.com/cognitect/transit-format#extensibility 
<https://github.com/cognitect/transit-format#extensibility>

Before transit existed, there was a little library that I used to encode a 
Clojure record as a tagged literal (for edn compatibility).  It’s only for the 
Clojure side at the moment, but I imagine it wouldn’t be hard to port to CLJS.  
However, I suggest that you use transit.

https://github.com/miner/tagged <https://github.com/miner/tagged>



> On Feb 24, 2015, at 4:40 PM, Colin Yates  wrote:
> 
> I am sending instances of defrecords from clojurescript via transmit/edn and 
> getting:
> 
> 2015-Feb-24 19:23:52 + dev-os-mbp.local DEBUG [taoensso.sente] - Bad 
> package: [[:client/message #health.shared.domain.PingCommand{}]] 
> (clojure.lang.ExceptionInfo: No reader function for tag 
> health.shared.domain.PingCommand {:type :reader-exception})
> 
> The defrecord is defined using cljx and is definitely there on the server.
> 
> Do I need to write a reader function to recognise instances of defrecord - my 
> assumption was that this should just work?
> 
> 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: Can someone offer refactoring suggestions for my protocol example?

[Steve Miner]

It’s probably fine to do a linear search with .indexOf for small vectors, but 
I’ll just say as a matter of style I prefer to use a couple of maps to hold 
previous and next items.  The maps are callable like functions, which I think 
reads very nicely.  Using your example data for ranks:

;; helper functions
(defn prev-map [coll] (zipmap (rest coll) coll))
(defn next-map [coll] (zipmap coll (rest coll)))

(def ranks [:private :corporal :sergeant :lieutenant :captain :major :colonel 
:general])

(def previous-rank (prev-map ranks))

(def next-rank (next-map ranks))

(next-rank :corporal)
;=> :sergeant

Perhaps, in your example with promotions you'd want the end items to stick 
rather than return nil for the overflow cases.  (In other situations, you might 
want to wrap around.)

(defn bounded-prev-map [coll]
  (assoc (zipmap (rest coll) coll) (first coll) (first coll)))

(defn bounded-next-map [coll]
  (let [lst (if (vector? coll) (peek coll) (last coll))]
(assoc (zipmap coll (rest coll)) lst lst)))

Just a suggestion.


> On Feb 23, 2015, at 1:44 PM, Daniel Hinojosa  
> wrote:
> This example works, but it still has the feel of a lot of duplication, are 
> there any refactorings that I can do to this to make it more concise?
> 
> https://github.com/dhinojosa/language-matrix/blob/master/clojure/protocols/protocols.clj

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

[Steve Miner]

Try adding (flush) at the end.

> On Feb 27, 2015, at 2:12 PM, Cecil Westerhof  wrote:
> 
> My core.clj ends with:
> (println (format "Started: %s (println)" (java.util.Date.)))
> (printf "Started: %s (printf)\n" (java.util.Date.))
> 
> I do not see the output from the printf when I run 'lein repl'.
> The funny thing is that when I switch the two statements, both are shown.
> Also when I do 'lein run' both are shown.
> 
> What could be happening here?
> 
> For the moment I changed all my printf to println with format, but it is a 
> little annoying.

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

[Steve Miner]

For the transducer version, I don’t think you need to keep track of the 
previous value (fval). The decision to start a new partition group depends only 
on the current item. Here’s my version. (Warning: virtually untested.)  I 
assume that the first item goes into the first partition no matter what so you 
don’t even need to call f.  Maybe you should for side-effects?

(defn partition-when
   "Applies f to each value in coll, starting a new partition each time f 
returns a
   true value.  Returns a lazy seq of partitions.  Returns a stateful
   transducer when no collection is provided."
  {:added "1.X"
   :static true}
  ([f]
   (fn [rf]
 (let [a (java.util.ArrayList.)]
   (fn
 ([] (rf))
 ([result]
  (let [result (if (.isEmpty a)
 result
 (let [v (vec (.toArray a))]
   ;;clear first!
   (.clear a)
   (unreduced (rf result v]
(rf result)))
 ([result input]
(if (.isEmpty a)
  (do (.add a input)
  result)
  (if (f input)
(let [v (vec (.toArray a))]
  (.clear a)
  (let [ret (rf result v)]
(when-not (reduced? ret)
  (.add a input))
ret))
(do
  (.add a input)
  result

  ([f coll]
  (lazy-seq
   (when-let [s (seq coll)]
 (let [fst (first s)
   run (cons fst (take-while #(not (f %)) (next s)))]
   (cons run (partition-when f (seq (drop (count run) s)


— Steve

> On Mar 5, 2015, at 12:11 PM, Andy-  wrote:
> 
> Tried myself and my first transducer for fun:
> 
> (defn partition-when
>   [f]
>   (fn [rf]
> (let [a (java.util.ArrayList.)
>   fval (volatile! false)]
>   (fn
> ([] (rf))
> ([result]
>(let [result (if (.isEmpty a)
>   result
>   (let [v (vec (.toArray a))]
> ;;clear first!
> (.clear a)
> (unreduced (rf result v]
>  (rf result)))
> ([result input]
> (if-not (and (f input)  @fval)
>(do
>  (vreset! fval true)
>  (.add a input)
>  result)
>(let [v (vec (.toArray a))]
>  (.clear a)
>  (let [ret (rf result v)]
>(when-not (reduced? ret)
>  (.add a input))
>ret
> 
> 
> (into [] (partition-when
>   #(.startsWith % ">>"))
>   [">> 1" ">> 2" "22" ">> 3"])
> 
> Based on partition-by (on master branch). Would be interesting how fast it is 
> compared to the other implementations.
> 
> Any comments appreciated.
> 
> Cheers

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

[Steve Miner]

> On Apr 1, 2015, at 11:16 AM, Alex Miller  wrote:
> 
> - eduction now takes multiple transformations, not just one, and composes 
> them. This is designed for mechanical rewriting (hello tool developers!!) of 
> ->> chains like this:
> 
> (->> s (interpose 5) (partition-all 2))
> 
> to this:
> 
> (->> s (eduction (interpose 5) (partition-all 2)))
> 

Maybe it’s just me, but the eduction argument order just looks strange to me.  
For a variadic function, I would have expected the single collection to come 
first, then any number of xforms.  There must be a better reason than 
mechanical rewriting.  Wouldn't a macro make more sense?

(defmacro educe->> [coll & xfs] `(->Eduction (comp ~@xfs) ~coll))

So the rewrite could be just educe->> for ->>, without having to wrap the 
xforms at all.

(educe->> s (interpose 5) (partition-all 2))



Steve Miner
stevemi...@gmail.com






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

[Steve Miner]

I use a default reader to do something like what you're asking for in my
'tagged' library.  You could hack a similar default reader that restricted
itself just to your favorite namespaces.  That way you don't have to
explicitly track all your defrecord classes.

https://github.com/miner/tagged




On Fri, Dec 6, 2013 at 2:10 AM, Michael Daines  wrote:

> I'm trying to come up with a function that will take a namespace
> containing Record definitions and convert it into a :readers map for EDN
> parsing. Right now, I'm just doing it manually, but as the number of
> records grows, this feels sillier and sillier. I haven't found anything in
> the core libraries yet that would seem to help me here. The only "ns-"
> function that gets me some of what I need is (ns-publics), which I could
> use to parse out the map functions.
>
> To be more clear, I have a namespace in the project like this:
>
> (ns proj.core.records)
>
> (defrecord NodeAddress [node address])
> (defrecord NodeComplete [node completed status)
> ... etc.
>
>
> Then at the end of the file, I'm manually creating a map for use with EDN:
>
> (def reader-map
>   {'proj.core.records.NodeAddress map->NodeAddress
>... etc. })
>
>
> I feel like there should be an elegant way to do this, but I haven't seen
> anything like what I have in mind. I'd love to put together a general
> purpose function I could use like this:
>
> (edn/read-string {:readers (reader-map 'proj.core.records)} data)
>
>
> Does anyone have some insights, or suggestions, or maybe something out
> there already (this seems to me like an obvious thing to do)?
>
> 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/groups/opt_out.
>

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

Re: Function that "weaves" two collections together - looking for feedback

[Steve Miner]

On Feb 19, 2014, at 12:28 AM, Laurent Droin  wrote:

> Ah, thank you. "interleave" is what I was looking for. I looked for "weave", 
> "zip", "map", "concat", and all the "see also" but did not find "interleave".
> Interleave will of course not handle the last value in the categories 
> collection so my first instinct will be to call (into [] ) on the map 
> returned by interleave, and to add (using conj) the (last categories) to the 
> vector. Not sure whether there is a better way.

Here's an interleave-all function that's like interleave but uses all the 
elements of all the collections.  Be careful if any of your collections might 
be infinite.  In that case, you need to wrap something like `take` around the 
call.

(defn interleave-all
  "Returns a lazy seq of the first item in each collection, then the second, 
etc.  If one 
collection ends, continues to interleave the others.  Naturally, you should 
take care with
infinite sequences."
  ([] (lazy-seq nil))
  ([c] (lazy-seq c))

  ([c1 c2]
 (lazy-seq
  (cond (not (seq c1)) c2
(not (seq c2)) c1
:else (conj (interleave-all (rest c1) (rest c2)) (first c2) (first 
c1)

  ([c1 c2 & colls] 
 (lazy-seq 
  (let [ss (keep seq (conj colls c2 c1))]
(concat (map first ss) (apply interleave-all (map rest ss)))



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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Steve Miner]

I just tried to build master locally with the new JDK 1.8 on a Mac.  I'm 
getting a build test failure.  Sorry, I don't have time to look into it at the 
moment.  JDK 1.7 worked fine for me.

 [java] clojure.test-clojure.reflect
 [java] 
 [java] java.lang.IllegalArgumentException
 [java] at clojure.asm.ClassReader.(ClassReader.java:170)
 [java] at clojure.asm.ClassReader.(ClassReader.java:153)
 [java] at clojure.asm.ClassReader.(ClassReader.java:424)
 [java] at clojure.reflect.AsmReflector.do_reflect(java.clj:200)
 [java] at clojure.reflect$fn__9042$G__9038__9045.invoke(reflect.clj:44)
 [java] at clojure.reflect$fn__9042$G__9037__9049.invoke(reflect.clj:44)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:156)
 [java] at clojure.lang.AFn.applyTo(AFn.java:144)
 [java] at clojure.core$apply.invoke(core.clj:626)
 [java] at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at clojure.reflect$type_reflect.doInvoke(reflect.clj:100)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:439)
 [java] at clojure.test_clojure.reflect$fn__19909.invoke(reflect.clj:23)
 [java] at clojure.test$test_var$fn__7187.invoke(test.clj:704)
 [java] at clojure.test$test_var.invoke(test.clj:704)
 [java] at clojure.test$test_vars$fn__7209$fn__7214.invoke(test.clj:722)
 [java] at clojure.test$default_fixture.invoke(test.clj:674)
 [java] at clojure.test$test_vars$fn__7209.invoke(test.clj:722)
 [java] at clojure.test$default_fixture.invoke(test.clj:674)
 [java] at clojure.test$test_vars.invoke(test.clj:718)
 [java] at clojure.test$test_all_vars.invoke(test.clj:728)
 [java] at clojure.test$test_ns.invoke(test.clj:747)
 [java] at clojure.core$map$fn__4245.invoke(core.clj:2559)
 [java] at clojure.lang.LazySeq.sval(LazySeq.java:40)
 [java] at clojure.lang.LazySeq.seq(LazySeq.java:49)
 [java] at clojure.lang.Cons.next(Cons.java:39)
 [java] at clojure.lang.RT.next(RT.java:599)
 [java] at clojure.core$next.invoke(core.clj:64)
 [java] at clojure.core$reduce1.invoke(core.clj:903)
 [java] at clojure.core$reduce1.invoke(core.clj:894)
 [java] at clojure.core$merge_with.doInvoke(core.clj:2777)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:139)
 [java] at clojure.core$apply.invoke(core.clj:626)
 [java] at clojure.test$run_tests.doInvoke(test.clj:762)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:137)
 [java] at clojure.core$apply.invoke(core.clj:624)
 [java] at 
clojure.test.generative.runner$run_all_tests$fn__529.invoke(runner.clj:255)
 [java] at 
clojure.test.generative.runner$run_all_tests$run_with_counts__521$fn__525.invoke(runner.clj:251)
 [java] at 
clojure.test.generative.runner$run_all_tests$run_with_counts__521.invoke(runner.clj:251)
 [java] at 
clojure.test.generative.runner$run_all_tests.invoke(runner.clj:253)
 [java] at 
clojure.test.generative.runner$test_dirs.doInvoke(runner.clj:304)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:137)
 [java] at clojure.core$apply.invoke(core.clj:624)
 [java] at clojure.test.generative.runner$_main.doInvoke(runner.clj:312)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at user$eval566.invoke(run_tests.clj:4)
 [java] at clojure.lang.Compiler.eval(Compiler.java:6703)
 [java] at clojure.lang.Compiler.load(Compiler.java:7130)
 [java] at clojure.lang.Compiler.loadFile(Compiler.java:7086)
 [java] at clojure.main$load_script.invoke(main.clj:274)
 [java] at clojure.main$script_opt.invoke(main.clj:336)
 [java] at clojure.main$main.doInvoke(main.clj:420)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at clojure.lang.Var.invoke(Var.java:379)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:154)
 [java] at clojure.lang.Var.applyTo(Var.java:700)
 [java] at clojure.main.main(main.java:37)
 [java] {:file "ClassReader.java",
 [java]  :tstamp 1395244274721,
 [java]  :type :error,
 [java]  :clojure.test/vars (compare-reflect-and-asm),
 [java]  :level :error,
 [java]  :pid 97553,
 [java]  :line 170,
 [java]  :thread 1,
 [java]  :exception
 [java]  #,
 [java]  :thread/name "main",
 [java]  :message "Uncaught exception, not in assertion."}
 [java] 


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

Re: Thoughts on a curly-infix reader macro?

[Steve Miner]

The desire (and rejection) of infix notation for Lisp is as old as the hills.

"Therefore we expect future generations of Lisp programmers to continue to 
reinvent Algol-style syntax for Lisp, over and over and over again, and we are 
equally confident that they will continue, after an initial period of 
infatuation, to reject it. (Perhaps this process should be regarded as a rite 
of passage for Lisp hackers.)" 
-- Steele and Gabriel, [1].  

The full paper "The Evolution of Lisp" [2] is definitely worth reading.  See 
also the video presentation [3].

As far as Clojure goes, it's highly unlikely that the Clojure language will 
accept your proposal.  I suggest that you write a macro or use a data-reader 
[4].

[1] http://www.paulgraham.com/syntaxquestion.html

[2] http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

[3] http://www.infoq.com/presentations/Lisp-Guy-Steele-Richard-Gabriel

[4] https://gist.github.com/miner/5224709

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

Re: [ANN] clojure.test.check 0.5.8

[Steve Miner]

On May 14, 2014, at 10:44 AM, Reid Draper  wrote:
> * Limit the number of retries for gen/such-that. A two-arity version is
>   provided if you need to retry more than 10 times. This should be a
>   code-smell, though.

I think the limit is a good idea, but it's an extra wrinkle and maybe too tight.

I had a such-that that failed due to the new limit.  Unfortunately, the error 
message didn't help much in tracking it down.  I ended up changing all my 
such-that calls to use a unique number of retries so I could figure which one 
was failing.

I suppose my situation is unusual in that I generate generators and tests from 
schemas and data.  The stack traces aren't very pretty when there are errors.

It might help if you added the 'pred' and 'tries' to the ex-info data in 
such-that-helper.  Might as well put something in the ex-info data.

By the way, it turns out 25 was a sufficient number of retries for my test.  
Works fine now.


Steve Miner

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

Re: [ANN] clojure.test.check 0.5.8

[Steve Miner]

On May 15, 2014, at 1:03 PM, Reid Draper  wrote:

> Sorry you ran into an issue, Steve. I like your idea of including more 
> information in the ex-info data. Is there a specific generator you're having 
> trouble writing without such-that? In general, I've found that it's a 
> code-smell if you need such-that to retry that many times. Happy to help 
> explore other ways to write these generators.

I'm generating generators from schemas [1].  I have generators for all my 
simple schemas -- "int" corresponds to gen/int, etc.  The tougher case is when 
I have to convert a conjunction of schema expressions into a generator.  For 
example, a schema (and int pos) specifies a positive integer, essentially like 
testing (fn [x] (and (integer? x) (pos? x)).  

My current implementation finds some element of the AND that I can map to a 
generator and uses such-that to filter against a predicate created from the 
rest of the AND elements.

A simple example does something like this...

(make-generator '(and int pos odd))
--->  (gen/such-that (make-predicate '(and pos odd)) (make-generator 'int))
--->  (gen/such-that (fn [x] (and (pos? x) (odd? x))) gen/int)

Of course, it would be better to use gen/s-pos-int.  I'm thinking that I need 
to look for a few common combinations of simple schemas, especially if there's 
already a good generator for those cases.

However, I still need to try to handle the general case, and it looks like the 
such-that approach will have to be my fallback position.  I'll probably give 
the user the option of adding custom generators to match more complicated 
schema expressions.

Now, if you could provide an efficient AND generator combinator, that would 
solve all my problems.  :-)

It occurs to me that automatically deriving generators is something like 
running a predicate backwards so maybe there's a way to do it with core.logic, 
but I haven't tried to do that yet.

I'd be happy to consider any suggestions.

Thanks,
Steve Miner


[1] https://github.com/miner/herbert


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

Re: How to take a subsequence out of an infinite lazy sequence?

[Steve Miner]

On Jun 15, 2014, at 9:42 AM, Yehonathan Sharvit  wrote:

> I have a infinite lazy sequence and I would like to create a lazy sub 
> sequence with all the elements whose indices are between 100 and 1000. 



You can use `drop` and `take` with infinite sequences.  Something like this 
should work:

(defn between [start end coll] 
  (take (- end start) (drop start coll)))

The `end` is exclusive as in `range`.

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

[Steve Miner]

Slightly off-topic from original poster's question, but if you're interested in 
another  implementation of flatten, I suggest you take a look at the reducers 
library.  clojure.core/flatten is elegant but a bit slow.  The reducers version 
is very fast as part of a reduce/fold operation.  The whole reducers library is 
worth studying.

http://clojure.org/reducers

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

[Steve Miner]

I will call it a bug.  It's definitely surprising to the user, and therefore 
worthy of a ticket.  On first glance, it seems that the fix isn't too hard. In 
core.clj where the macro fn is redefined, we just need to wrap the section that 
handles the post condition either with a loop* or a fn* so that the body has 
the proper recur target.  I'll try to make a patch and a test.  If it works, 
I'll file a bug with the patch.

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

[Steve Miner]

Ticket CLJ-1475 with my patch.

http://dev.clojure.org/jira/browse/CLJ-1475

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

[Steve Miner]

My first patch was buggy with destructured args so I had to withdraw it.

While working on a better patch, I came up against a related issue: Should the 
:pre conditions apply to every recur "call". I'm saying no.  The :pre 
conditions should be checked just once on the initial function call and never 
during a recur. Any other opinions?

On Jul 25, 2014, at 10:57 AM, Steve Miner  wrote:

> Ticket CLJ-1475 with my patch.
> 
> http://dev.clojure.org/jira/browse/CLJ-1475

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

[Steve Miner]

I'm giving up on this bug.  My approach was adding too much complexity to 
handle an edge case.  Hacking the fn macro is not as easy as it looks. :-)

I recommend the loop work-around if you run into this problem.  Or refactor the 
recursive code into a separate function and call it from another function with 
the :pre and :post conditions in the non-recursive function.

http://dev.clojure.org/jira/browse/CLJ-1475

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

[Steve Miner]

I tried the latest patch from Ambrose for CLJ-1475.  Looks good to me.  Well 
done.

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

[Steve Miner]

I wouldn’t make any claims about “best practices” but I’ve been playing with 
transducers in my little project:

https://github.com/miner/transmuters

I have a blog post about how to “chain” transducers.  (Not sure that’s the best 
term.)  Basically, I wanted to use a transducer that might terminate (as with 
‘take’), and then have another transducer pick up the input from there.  The 
“chain” transducer is like a sequential combination of transducers.  Of course, 
you can mix ‘chain’ and ‘comp’ to make work flows.

http://conjobble.velisco.com/blog_posts/transducer-chain

In any case, it was a fun experiment for me.

Steve Miner
stevemi...@gmail.com


> On May 6, 2015, at 11:15 AM, larry google groups  
> wrote:
> 
> I would like to write a detailed blog post about how developers are actually 
> using transducers. If you have a public project on Github that is using 
> transducers, would you please point me to it? I would like to see what you 
> did. 
> 
> If you are not using transducers, but you plan to in the near future, I would 
> be curious to see the code where you think they could help you.

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

Re: What is "best practice" regarding transducers

[Steve Miner]

xempty is a transducer that just returns an empty result, essentially ignoring 
the input.  The thought was that a degenerate transducer might be useful in a 
complex chain if you want to stop processing.  I haven’t actually used it for 
anything, just experimenting.

> On May 10, 2015, at 3:12 PM, piastkra...@gmail.com wrote:
> 
> That is interesting. What is xempty for? 

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

[Steve Miner]

Not an expert, but I’ll throw out an alternative approach that might work for 
you.  I think it’s simpler to use a transducer that calls functions rather than 
trying to transform an existing transducer to do the cutoff.

(defn take-while-accumulating [accf init pred2]
   (fn [rf]
 (let [vstate (volatile! init)]
   (fn
 ([] (rf))
 ([result] (rf result))
 ([result input]
  (if (pred2 @vstate input)
(do (vswap! vstate accf input)
(rf result input))
(reduced result)))

accf is like a reducing function: takes two args, state and input, and returns 
new state of the “accumulation”.  init is the initial state of the 
accumulation.  pred2 is a predicate taking two args, the accumulation state and 
the new input.  The process stops when pred2 returns false.

;; distinct
(into [] (take-while-accumulating conj #{} (complement contains?)) '(1 2 3 4 2 
5 6))
;;=> [1 2 3 4]

;; dedupe
(into [] (take-while-accumulating (fn [r x] x) ::void not=) '(1 2 1 3 4 4 5 6))
;;=> [1 2 1 3 4]

;; monotonically increasing
(into [] (take-while-accumulating max 0 <=) '(1 2 3 4 4 1 5 6))
[1 2 3 4 4]


Steve Miner
stevemi...@gmail.com


  

On May 9, 2015, at 6:28 PM, Andy-  wrote:

> (defn take-while-xf
>  
> "Takes a transducer and returns a transducer that will immediately finish (ie
>   call (reduced)) when the transducer did not call the reducing function and
>   just returned the result. Only really useful with stateful transducers.
>   Otherwise you'd use take-while."
> 
> [xf]
> 

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

[Steve Miner]

If you’re interested in a transducer version of partition-when, here’s my code 
from https://github.com/miner/transmuters


;; collection version by Frank on mailing list
;; SEM added transducer version, adapted from partition-by
(defn partition-when
   "Applies f to each value in coll, starting a new partition each time f 
returns a
   true value.  Returns a lazy seq of partitions.  Returns a stateful
   transducer when no collection is provided."
  {:static true}
  ([f]
   (fn [rf]
 (let [a (java.util.ArrayList.)]
   (fn
 ([] (rf))
 ([result]
  (let [result (if (.isEmpty a)
 result
 (let [v (vec (.toArray a))]
   ;;clear first!
   (.clear a)
   (unreduced (rf result v]
(rf result)))
 ([result input]
(if (.isEmpty a)
  (do (.add a input)
  result)
  (if (f input)
(let [v (vec (.toArray a))]
  (.clear a)
  (let [ret (rf result v)]
(when-not (reduced? ret)
  (.add a input))
ret))
(do
  (.add a input)
  result

  ([f coll]
  (lazy-seq
   (when-let [s (seq coll)]
 (let [fst (first s)
   run (cons fst (take-while #(not (f %)) (next s)))]
   (cons run (partition-when f (seq (drop (count run) s)


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

[Steve Miner]

I’ll second what Timothy Baldridge  wrote.  By the way, 
you have to make sure you’re dealing with some sort of clojure.lang.IPending 
before you call realized? on it.  

I prefer to test against interfaces rather than concrete classes so I would try 
something like this (minimally tested):

(defn lazy-seq? [x]
  (and (instance? clojure.lang.IPending x) (seq? x) (not (realized? x

Even after a lazy seq has been “realized” (typically with doall), it’s still a 
clojure.lang.LazySeq but the results have been cached so it’s not so “lazy” 
anymore.

Depending on what you’re doing, you might get by with just counted? which is 
true for literal lists and vectors, but false for conses and lazy collections.



> On Oct 18, 2015, at 5:55 PM, Brian Marick  wrote:
> 
> Is there a way to tell if `v` is a lazyseq other than `(instance? 
> clojure.lang.LazySeq v)`? Seems like there should be, but I'm not seeing 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: A call for an idiomatic rendering of Clojure EDN in info/error messages

[Steve Miner]

For what it’s worth, I like to use matching `backquotes` as a meta-syntax.

(defn expected [exp was] 
  (format "Expected `%s` but was `%s`" (pr-str exp) (pr-str was)))

(println (expected 2 "2"))
;=> Expected `2` but was `"2"`



> On Nov 13, 2015, at 6:55 AM, Colin Yates  wrote:
> 
> Hi all,
> 
> Can we, the community agree a consistent way of rendering Clojure EDN when we 
> report it in info or error. For example, given the EDN "2" (i.e. a string 
> containing a single character 2) I have seen various libraries render it as:
> 
>  - 2
>  - "2"
>  - ["2"]
>  - [2]
>  - (2)
>  - '"2"'
> 
> I would like to propose that we standardise around "_" as the boundary 
> character as that isn't likely to be used in (except for some markup I guess 
> but that is pretty unlikely), so a test framework might render as such:
> 
>  - expected _2_ but was _"2"_
> 
> Please? :-)

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

[Steve Miner]

I would prefer that *read-eval* default to false.  In this case, security is 
more important than backwards compatibility.  

However, I want to point out that there is an issue with backwards 
compatibility, especially for users of *print-dup* (default false).  In many 
cases, with *print-dup* true, the printed representation will use the "#=" 
notation, which is readable only if *read-eval* is true.

If your code is binding *print-dup*, you probably should be binding *read-eval* 
explicitly, not depending on the default.


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

Re: Nilsafe operators from clojure.core.contrib fail when not referred

[Steve Miner]

In Clojure 1.5 pre-releases, there's a new macro called some-> .  The source 
looks like it would work fine in earlier versions of Clojure.  At this point, I 
don't think it's a good idea to keep slightly different versions in contrib.

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

Re: Clojure 1.5 RC 14

[Steve Miner]

Maybe the registry has caught up with the updates yet.  Leiningen found RC 14.

% lein deps
Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.pom from 
sonatype-oss-public
Retrieving org/clojure/clojure/1.5.0-RC14/clojure-1.5.0-RC14.jar from 
sonatype-oss-public


On Feb 9, 2013, at 3:29 PM, AtKaaZ  wrote:

> Hi Stu. All I see is beta13 as being last (9 feb), and RC6 05-Feb-2013
> 

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

Re: Clojure as first language

[Steve Miner]

> On Feb 26, 2016, at 9:53 AM, Lee Spector  wrote:
> 
> But sometimes it does matter, e.g. (str '(1 2 3 4 5 6 7 8 9 10)) => "(1 2 3 4 
> 5 6 7 8 9 10)", whereas (str (map inc (range 10))) => 
> "clojure.lang.LazySeq@c5d38b66"

There’s a bit of subtlety around `str` vs. `pr-str`.  In many case, pr-str will 
give more intuitive results.  Unfortunately, it’s not easy for beginners to 
discover.

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

[Steve Miner]

> On May 24, 2016, at 8:10 AM, Alex Miller  wrote:
> 
> The first use is a namespace alias and the second is a var - they don't 
> overlap in usage.

Right, but it’s still a potential source of confusion.  The explanation 
distracts from the point of the example which is to demonstrate the new spec 
feature.

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

[Steve Miner]

Not exactly the same problem, but you might like to see an infix implementation 
from “The Joy of Clojure” by Fogus and Chouser.

http://fogus.me/fun/unfix/infix-src.html

The “Joy” code makes intermediate calculations as it goes.  I tweaked it a bit 
to make a data-reader that only does the infix to prefix transformation.  
That’s probably closer to what you want.

https://gist.github.com/miner/5224709

Note: the “Joy” code uses vector notation for grouping.  You would have to 
adapt it to use lists.

Here’s the relevant code from my gist, leaving out the data-reader part:

(def && #(and % %2))
(def || #(or  % %2))

(def ops '[- + * / < > && || =])
(def rank (zipmap ops (iterate inc 1)))
(def op? rank)

(defn infix
  [[a b & [c d e & m]]]
  (cond
   (vector? a) (recur (list* (infix a) b c d e m))
   (vector? c) (recur (list* a b (infix c) d e m))
   (op? b) (if (and d (< (rank b 0) (rank d 0)))
 (recur (list a b (infix (list* c d e m
 (recur (list* (list b a c) d e m)))
   :else a))

;; example
(infix '[1 + 3 * 4 - 5])
;=> (+ 1 (- (* 3 4) 5))


> On Jun 24, 2016, at 2:28 PM, Botond Balázs  wrote:
> 
> Hi,
> 
> I'm working through Clojure for the Brave and True and there's a little 
> exercise at the end of Chapter 7:
> 
> Create an infix function that takes a list like (1 + 3 * 4 - 5) and 
> transforms it into the lists that Clojure needs in order to correctly 
> evaluate the expression using operator precedence rules.
> 
> I ended up implementing the shunting yard algorithm in Clojure to solve it 
> (65 lines, many functions), but I have the suspicion that this exercise isn't 
> meant to be this complicated and that I'm missing a very obvious and elegant 
> solution. What do you think?
> 
> Thanks,
> Botond

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

[Steve Miner]

With a little help from Java, you can make equivalent open intervals for the 
desired bounds.  For example,

  (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %))

should be the same as

  (s/double-in :min Double/MIN_VALUE :max 1.0)

Also, you can use java.lang.Math/nextUp and nextAfter to get adjacent doubles 
for your bounds.

(java.lang.Math/nextUp 1.1)
;=> 1.1003

(java.lang.Math/nextAfter 1.1 Double/NEGATIVE_INFINITY)
;=> 1.0999

There are a few tricky situations around the zeroes and infinities so you 
should read the doc on nextAfter, especially if you’re dealing with extreme 
doubles.

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

[Steve Miner]

> (s/and (s/double-in :min 0.0 :max 1.0) #(not= 0.0 %)) 
> 
> should be the same as 
> 
>   (s/double-in :min Double/MIN_VALUE :max 1.0) 

I should have mentioned that Double/MIN_VALUE is the smallest positive double 
(just greater than 0.0), not a large negative value.  It’s easy to get confused 
by the fact that Long/MIN_VALUE is extremely negative.

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

[Steve Miner]

It looks like you’ve got your #s misplaced.  I think you want something like 
this:

(s/and #(> % 0.0) #(< % 1.0))

Of course, the first predicate expression could be replaced by `pos?`.

The `s/and` returns a single spec that combines multiple specs.  Of course, 
`clojure.core/and` is basically the logical AND of “truthy” values.

The #(…) form is creating an anonymous function.  In your first case, that 
creates a reasonable predicate, which works correctly as a spec.

Your second form isn’t doing what you wanted because the anonymous function 
notation is wrapping the whole `s/and` combining form, and in that context the 
tests aren't syntactically the appropriate predicates.  You’re getting an extra 
level of nesting and bad tests.

I suspect that the confusion comes from the similarity between a predicate and 
a spec.  In a sense, a predicate function is the simplest form of a spec.  
However, you need a special way of combining multiple specs, not just the plain 
logical `and` combination.  So we have `s/and` to do the job.



> On Jul 21, 2016, at 1:23 PM, Mars0i  wrote:
> 
> With Clojure 1.9.0-alpha10:
> 
> user=> (s/def ::interval-with-cloj-and #(and   (> % 0.0) (< % 1.0)))
> 
> user=> (s/def ::interval-with-spec-and #(s/and (> % 0.0) (< % 1.0)))
> 
> user=> (s/valid? ::interval-with-cloj-and 1.0)
> false
> 
> That's what I expected.
> 
> user=> (s/valid? ::interval-with-spec-and 1.0)
> true
> 
> That's not what I expected.
> 
> In fact, as far as I can tell, (valid? ::interval-with-spec-and x) will 
> return true for any number x.  What does spec/and mean, then?  I thought that 
> in this context it would mean the same as Clojure's normal 'and'.  That's 
> what the first example of its use in the Clojure.spec Guide seems to show.  I 
> must be misunderstanding something basic and perhaps obvious.


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

Re: How does clojure.core quote function work for keyword?

[Steve Miner]

It’s working as expected.  The :: notation is expanded by the reader, before 
evaluation.  As keywords are basically constants (like numbers or strings), you 
rarely see them quoted.


> On Jul 26, 2016, at 8:52 AM, Mamun  wrote:
> 
> Hi 
> 
> How does clojure.core quote function work for keyword? If it is namespace 
> keyword then it is displaying with namespace. Is it excepted result?  
> 
> (println  (quote a)) 
> => a
> 
> (println  (quote :a) )
> => :a
> 
> (println  (quote ::a) )
> => :user/a  ;; I am expecting it should display ::a

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

[Steve Miner]

Sorry, I got the semantics of the grouping-fn wrong.  My code assumes that the 
key is always first in the elements and my grouping is more like a merging-fn.

> On Aug 14, 2016, at 2:53 PM, miner  wrote:
> 
> If your data elements are essentially map-entries (key-value pairs), I'd use 
> reduce.  Maybe something like this would work for you...
> 
> (defn mapping-group-by [grouping-fn mapping-fn coll]
>   (reduce (fn [res [k v]] (update res k grouping-fn (mapping-fn v)))
>   {}
>   coll))
> 
> (def foos [[:a "foo"]  [:b "bar"]  [:a "baz"]])
> 
> (mapping-group-by conj clojure.string/upper-case foos)
> ;;=> {:a ("BAZ" "FOO"), :b ("BAR")}
> 
> If you need vector values, you can wrap `conj` with `fnil` to get a vector.
> 
> (mapping-group-by (fnil conj []) clojure.string/upper-case foos)
> ;;=> {:a ["FOO" "BAZ"] :b ["BAR"]}
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> <http://groups.google.com/group/clojure?hl=en>
> --- 
> You received this message because you 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 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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: core.logic with 1.9.0-alpha12

[Steve Miner]

Filed LOGIC-180 bug with patch.

http://dev.clojure.org/jira/browse/LOGIC-180 


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

[Steve Miner]

> On Oct 10, 2016, at 6:50 AM, Rastko Soskic  wrote:
> 
> I am specially interested in better way for processing input which shrinks 
> after each step.

Vectors have some nice properties if your action is mostly at the end.  The 
peek and pop functions are useful for “shrinking” a vector.  Also, you can 
assoc into a vector, which is sometimes simpler to use than list manipulations. 
 By the way, reduce-kv works with vectors so that’s a good way to find the 
smallest element and its index.

I’m cheating a bit by filling the “hole” of the selected item with the last 
element so I can pop the input vector without losing anything.

Caveat: not a recommended way to sort, only lightly tested.

(defn selsort [coll]
  (loop [v (vec coll) sv []]
(if (seq v)
  (let [pi (dec (count v))
px (peek v)
[i0 x0] (reduce-kv (fn [r i x] (if (< x (peek r)) [i x] r))
  [pi px]
  (pop v))]
(recur (pop (assoc v i0 px)) (conj sv x0)))
  sv)))



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you 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: Help me understand what part of this code is slow, and how to make it faster?

[Steve Miner]

> On Nov 21, 2016, at 3:05 PM, Didier  wrote:
> 
> I experimented with this a lot, and took everyone's advice, and this is the 
> fastest I got, even faster then Michael Gardner's answer.
> 
> (deftype point5 [^long i ^long j]
>   Object
>   (equals [this that] (and (= (.i this) (.i ^point5 that))
>(= (.j this) (.j ^point5 that
>   (hashCode [this] (+ (.i this) (* 4000 (.j this)


Java equals and hashCode are notoriously tricky to get right.  Equals should 
handle any kind of “that” so you typically need to test instance? (basically, 
instanceOf in Java).  Here are a couple of reference links:

http://stackoverflow.com/questions/27581/what-issues-should-be-considered-when-overriding-equals-and-hashcode-in-java

http://www.angelikalanger.com/Articles/JavaSolutions/SecretsOfEquals/Equals.html

In this case, I suggest you try something like this:

(equals [this that] (or (identical? this that)
(and (instance? point5 that)
 (= (.i this) (.i ^point5 that))
 (= (.j this) (.j ^point5 that)

It might be a little slower but it should be safer.

If you’re out for speed, you could also try unchecked-add, unchecked-multiply, 
unchecked-inc, and unchecked-dec where it's safe to ignore the chance of 
overflows.  I mention these only because you’re trying to compete on 
benchmarks.  Most of the time, you shouldn’t use them.





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

Re: Help me understand what part of this code is slow, and how to make it faster?

[Steve Miner]

> On Nov 21, 2016, at 8:03 PM, Didier  wrote:
> 
> @miner: Doesn't using the flag (set! *unchecked-math* :warn-on-boxed) gives 
> me unchecked math automatically? I was under the impression that +, -, /, * 
> etc. would all now perform in an equal way to unchecked-add, etc. If not, 
> what is the difference?

Yes, you’re right about the *unchecked-math* flag.  There shouldn’t be any 
difference.

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

[Steve Miner]

> On Dec 30, 2016, at 9:42 AM, John Schmidt  wrote:
> 
> (s/def ::game1 #(satisfies? Game %))
> (s/def ::game2 (partial satisfies? Game))
> 
> (s/explain ::game2 (spec-test.foo/->Foo))
> val: #spec_test.foo.Foo{} fails spec: :spec-test.core/game2 predicate: 
> (partial satisfies? Game) < WAT
> nil

It looks like the spec macros aren’t resolving the Game reference in the game2 
spec.  You can use macroexpand-1 to see what was happening at the top-level.  
The internal macros get a little complicated so I can’t say if code expressions 
like this were intended to work.  It doesn’t hurt to file a bug.

I think the usual way to write this would be to define your own little 
predicate first and then use that var in the spec.

(def my-game? (partial satisfies? Game))

(s/def ::game3 my-game?)

If you want to work around the immediate issue, try using the fully qualified 
symbol for the protocol.  (I prefer ::game3 FWIW.)

(s/def ::game4 (partial satisfies? spec-test.core/Game))






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

[Steve Miner]

Use clojure.edn/read-string.  Note the clojure.edn namespace.  
clojure.core/read-string can execute code (controlled by *read-eval*), and as 
such should be used only with trusted sources.

> On Jan 1, 2017, at 10:07 AM, Yehonathan Sharvit  wrote:
> 
> I’d like to write a function `foo` that receives a string `s` and returns a 
> list with the value of `s` without the quotes as a single element.
> A possible implementation, I wrote:
> ```
> (defn foo [s]
> (list (symbol s)))
> 
> (def my-string "[1 2]")
> (foo my-string) ; ([1 2])
> ```
> But it feels weird to me to call `symbol` for that purpose. 
> 
> I call also call `read-string`...
> 
> What is the proper way of writing `foo`?

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

[Steve Miner]

> On Jan 1, 2017, at 7:13 PM, John Schmidt  wrote:
> 
> Steve: both ::game3 and ::game4 from your suggestions result in the same 
> error.
> 

Sorry for my mistaken conjecture.  My issue with the macroexpansion looks like 
a red herring.  I guess I confused myself with quick tests in the REPL. 

The problem seems to be sensitive to the order of the declaration of the 
predicates versus the protocol extension.  That is, it seems to work for me if 
I do the extend-type Foo before defining the predicates that refer to the 
protocol.  I probably did this accidentally while playing in the REPL. 

So now I think the issue is that one version of the protocol was captured by 
the “early" predicates, and then the protocol itself was changed so references 
to the “old” protocol (with the same name) no longer worked.

The #(…) closure seems to do the right thing as the protocol symbol doesn’t get 
evaluated at definition 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: Combinatorics partitions that preserves adjacency?

[Steve Miner]

For what it’s worth, I gave your problem a try and come up with the following 
implementation based on Mark Engelberg’s suggestion.  It should do less 
generating work up front so you don’t have to filter unwanted results.  This 
code depends on `combinations` preserving the order of the items.  I’m not sure 
that’s guaranteed, but the current implementation works that way, which is 
convenient.  My `sized-subsets` is a modified version of the combinatorics 
`subsets` that limits the results to the inclusive min and max counts given.

By the way, if you’re using subvectors you should be aware of bug CLJ-2065, 
reduce-kv fails on subvectors.  There’s an easy work-around in the bug report.

http://dev.clojure.org/jira/browse/CLJ-2065 
<http://dev.clojure.org/jira/browse/CLJ-2065>

(require '[clojure.math.combinatorics :as mc])

;; inclusive sizes
(defn sized-subsets [items min-count max-count]
  (mapcat (fn [n] (mc/combinations items n))
  (range min-count (inc max-count


(defn subv-ordered-partitions [coll & {from :min to :max}]
  (let [v (vec coll)
cnt (count v)
smin (dec (or from 1))
smax (dec (or to cnt))]
(map (fn [splits]
   (map (fn [start end] (subvec v start end))
(conj splits 0)
(concat splits (list cnt
 (sized-subsets (range 1 cnt) smin smax))))

Steve Miner


> On Mar 16, 2017, at 12:59 PM, Paul Gowder  wrote:
> 
> For sake of completeness/if this is useful for anyone else, a full 
> implementation of the number-the-possible-split-locations method, including 
> the original API with :min and :max options. Could probably be tidied up with 
> transducers and such for all those filters but does the job. 
> 
> (require '[clojure.math.combinatorics :as c])
> (defn breaks->partition 
>  ([v brks]
>   (breaks->partition 0 [] v brks))
>  ([start pars v brks]
>   (if (empty? brks)
> (conj pars (subvec v start (count v)))
> (let [this-part (subvec v start (first brks))]
>   (recur (first brks) (conj pars this-part) v (rest brks))
> 
> (defn min-parts [min splits]
>  (>= (count splits) (- min 1)))
> 
> (defn max-parts [max splits]
>  (<= (count splits) (- max 1)))
> 
> (defn ordered-partitions [v & {:keys [max min]}]
>  (let 
>[s (c/subsets (range 1 (count v)))
> fs (cond
>  (and max min) 
>  (filter 
>(partial max-parts max) 
>(filter (partial min-parts min) s))
>  max (filter (partial max-parts max) s)
>  min (filter (partial min-parts min) s)
>  :else s)]
> (map (partial breaks->partition v) fs)))
> 
> It does, alas, take more than 10 times as long as Mike's version.  Which 
> proves that one should never try to do anything faster than the core.matrix 
> guy.  :-) 

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

Re: [ANN] Clojure 1.9 / clojure.spec split

[Steve Miner]

Before the spec split, the basic way to invoke Clojure at the command line was:

% java -cp clojure.jar clojure.main

Documented here: https://clojure.org/guides/getting_started 
<https://clojure.org/guides/getting_started>

Is that still the intended usage with 1.9 going forward?

When I try it with 1.9-alpha16, I get an error:

Exception in thread "main" java.lang.ExceptionInInitializerError
at clojure.main.(main.java:20)
Caused by: java.io.FileNotFoundException: Could not locate 
clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.

As a work-around, I grabbed the spec jars and added them to the classpath.  
That worked to get me to the REPL.

However, I noticed that I get an error from the doc function.  So something is 
still not right with spec.

% java -cp clojure.jar:spec.alpha-0.1.94.jar:core.specs.alpha-0.1.10.jar 
clojure.main
Clojure 1.9.0-alpha16
user=> (doc +)
-
clojure.core/+
([] [x] [x y] [x y & more])
  Returns the sum of nums. (+) returns 0. Does not auto-promote
  longs, will throw on overflow. See also: +'
ClassNotFoundException clojure.spec.alpha$get_spec  
java.net.URLClassLoader.findClass (URLClassLoader.java:381)

user=> *e
#error {
 :cause "clojure.spec.alpha$get_spec"
 :via
 [{:type java.lang.NoClassDefFoundError
   :message "clojure/spec/alpha$get_spec"
   :at [clojure.repl$print_doc invokeStatic "repl.clj" 109]}
  {:type java.lang.ClassNotFoundException
   :message "clojure.spec.alpha$get_spec"
   :at [java.net.URLClassLoader findClass "URLClassLoader.java" 381]}]
 :trace
 [[java.net.URLClassLoader findClass "URLClassLoader.java" 381]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 424]
  [sun.misc.Launcher$AppClassLoader loadClass "Launcher.java" 331]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 357]
  [clojure.repl$print_doc invokeStatic "repl.clj" 109]
  [clojure.repl$print_doc invoke "repl.clj" 83]
  [clojure.lang.Var invoke "Var.java" 381]
  [user$eval1596 invokeStatic "NO_SOURCE_FILE" 1]
  [user$eval1596 invoke "NO_SOURCE_FILE" 1]
  [clojure.lang.Compiler eval "Compiler.java" 6977]
  [clojure.lang.Compiler eval "Compiler.java" 6940]
  [clojure.core$eval invokeStatic "core.clj" 3187]
  [clojure.core$eval invoke "core.clj" 3183]
  [clojure.main$repl$read_eval_print__9835$fn__9838 invoke "main.clj" 242]
  [clojure.main$repl$read_eval_print__9835 invoke "main.clj" 242]
  [clojure.main$repl$fn__9844 invoke "main.clj" 260]
  [clojure.main$repl invokeStatic "main.clj" 260]
  [clojure.main$repl_opt invokeStatic "main.clj" 324]
  [clojure.main$main invokeStatic "main.clj" 423]
  [clojure.main$main doInvoke "main.clj" 386]
  [clojure.lang.RestFn invoke "RestFn.java" 397]
  [clojure.lang.AFn applyToHelper "AFn.java" 152]
  [clojure.lang.RestFn applyTo "RestFn.java" 132]
  [clojure.lang.Var applyTo "Var.java" 702]
  [clojure.main main "main.java" 37]]}


I think it would be nice to have an inclusive jar as before.  Or we could make 
Clojure 1.9 tolerant of not having spec available, perhaps by stubbing out the 
basics of spec.  Maybe give a warning that explains how to get the spec jars.

Steve Miner


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

Re: [ANN] Clojure 1.9 / clojure.spec split

[Steve Miner]

> On May 3, 2017, at 7:37 PM, Alex Miller  wrote:
> 
> A newer version (0.1.108) of spec.alpha is available that fixes the issue. 
> Note that this kind of update is exactly why the jars are split - you can 
> update the libs more frequently than the Clojure version.

Thanks. The updated spec.alpha works for me.

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

Re: [ANN] tools.deps.alpha

[Steve Miner]

I’ve been using my own launch script that does something similar to the new clj 
script. (I’m caching a Leiningen generated classpath.)  I had some bugs when my 
project directory was copied to another user or machine because the cached 
classpath was not validate in the new environment, particularly with a 
different Maven repository.  The same kind of problem can happen with a 
remotely mounted project directory.  File time checks did not necessarily 
protect against these relocations.

I fixed my problem with two changes.  First, I put the cache in the 
PROJECT/target subdirectory so that a “lein clean” would allow the user to 
recover.  Second, I named my cache file with the inode of the project.clj file. 
 If the project is copied somewhere else, it is highly unlikely that the inode 
numbers would match.  The inode of the Maven repository or project deps.edn 
should work with the new clj script.

I use rlwrap, except within an Emacs shell.  I suggest you test for the 
presence of rlwrap as you do for java.  $(type -p rlwrap)  and ignore it if 
it’s not found.  I think Emacs is popular enough that it’s worth testing for 
within your clj script ($EMACS will be defined).  It would be good enough if 
you provided an option to turn off rlwrap so I could wrap your script with my 
own.

I can file bugs and provide patches if you want.

Steve Miner
stevemi...@gmail.com <mailto:stevemi...@gmail.com>




> On Jul 25, 2017, at 10:19 AM, Alex Miller  wrote:
> 
> tools.deps.alpha is a new contrib library API for transitive dependency graph 
> expansion and the creation of classpaths.
> 
> For more information, I would invite you to check out:
> 
> * the README 
> <https://github.com/clojure/tools.deps.alpha/blob/master/README.md> from 
> tools.deps.alpha
> * the slides 
> <http://cdn.cognitect.com/presentations/2017/dependency_heaven.pdf> from my 
> EuroClojure talk (video coming in the next week or two)
> 
> There are some additional pieces still to come that will provide installers 
> for various systems as well. This is still a work in progress but is targeted 
> for completion along with Clojure 1.9.
> 

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

Re: [ANN] tarantella 1.1.1

[Steve Miner]

Thanks for updated Tarantella.  I also enjoyed re-watching your talk.  

I just wrote a blog post to cover a simple solution to the Eight Queens problem 
using Tarantella.

http://conjobble.velisco.com/2019/07/30/tarantella-queens.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/FE9197F8-C372-481D-B32D-2D7B9583F068%40gmail.com.

Re: [ANN] tarantella 1.1.1

[Steve Miner]

My original benchmarks were for Eight Queens.  I ran some more tests with 
larger N and found that at N=14, the Tarantella version is the clear 
performance winner on my machine.

> On Jul 30, 2019, at 7:03 PM, Mark Engelberg  wrote:
> 
> Thanks for writing the n-queens code and the blog post. It's great to see 
> tarantella performing well.
> 
> There's a certain amount of overhead associated with setting up the dancing 
> links data structure, so I would conjecture that as your problem gets more 
> complicated (e.g., increasing n), you'd see tarantella become competitive 
> with the fastest of your hand-rolled implementations.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/6F654488-5D15-4A91-A80C-059FAE1818B8%40gmail.com.

Re: [ANN] fs - file system utilities for Clojure

[Steve Miner]

Thanks for shaing.  I was just about to write several functions along these 
lines.  I have a couple of comments.

First, I suggest that you look at the standard clojure.java.io package for some 
useful functions that are already in Clojure 1.2.  In particular, you could use 
io/file instead of (File. xxx) in your code to add some flexibility to the 
kinds of things that can be treated as a "file".  I think io/file could replace 
your fs/join. Also, io/copy is very flexible so it's worth a look, too.

Second, fs is using a singe segment namespace.  I remember that there have been 
some cautions against doing that. (But not everyone agrees.)  My understanding 
is that it's best for Java interop to have a multi-segment namespace.  
(Reference links below.)

http://clojure.org/libs

> A lib name is a symbol that will typically contain two or more parts 
> separated by periods.

http://groups.google.com/group/clojure-dev/browse_frm/thread/00b1c6971c3b3394

Chas Emerick wrote:
> First, namespacing is good.  Your foobar library won't have the same name as 
> my foobar library -- and while you might think "who else would put code in 
> the same oddly-named namespace as mine?", it's a big world out there and an 
> ounce of prevention is worth a pound of cure. More strictly speaking, one 
> cannot use any class in the default package from any Java class that is in a 
> package.  That is the practical issue that leads to default package use being 
> nonexistent in the Java space. And, you may not care about Java interop now, 
> but either (a) you might later, or (b) your users might, now.  Finally, 
> gen-class will simply not work (last I checked) from a single-segment 
> namespace. 


Best Regards,
Steve Miner
stevemi...@gmail.com

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

Re: Java namespaces, Cobol, and Hierarchical file systems

[Steve Miner]

On Jan 13, 2011, at 3:16 PM, Chas Emerick wrote:

> Just to clarify my position (it's funny to see one's self quoted out of the 
> blue from an old thread!), I'm not at all suggesting "java naming 
> conventions" when it comes to namespacing.

By the way, I didn't mean to put Chas on the spot.  Google led me to what 
seemed like a good quote, and I thought he deserved the credit. Please take 
that as a compliment.

One suggested compromise (from the old thread) was to use a short first segment 
so that your namespace is technically multi-segment (good for Java interop), 
but still short enough to be esthetically pleasing.  For example, clj.foo 
instead of plain foo.  Seems like a good compromise to me.

Now, one could say that the problem is in the Clojure compiler.  Maybe single 
segment names should be explicitly disallowed.  (They're bad, don't do that.)  
Or maybe the compiler should silently prepend "us.technomancy." to 
single-segment namespaces to make the world safe for Java interop with minimal 
danger of conflicts.  That would make everybody happy. :-)

Cheers,
Steve




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

Re: Release.Next Version Number

[Steve Miner]

The choice boils down to whether or not you want to follow Semantic Versioning 
[1].  Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent 
policies.  Personally, I think it's a perfectly logical approach to increment 
the major version number for any backwards incompatible change.

Python officially has a more relaxed interpretation [5].  My understanding is 
that in practice the Python community was very concerned about backwards 
compatibility among the late 2.x releases because 3.0 was going to introduce 
big changes.

> Python versions are numbered A.B.C or A.B. A is the major version number – it 
> is only incremented for really major changes in the language. B is the minor 
> version number, incremented for less earth-shattering changes. C is the 
> micro-level – it is incremented for each bugfix release.

The Wikipedia article on software versioning [6] covers some other concerns 
such as marketing.  I guess that takes into account the idea that "2.0" should 
be a major improvement.

As I said, I personally like the concept of semantic versioning.  If Rich wants 
to do something else, I can live with an incompatible 1.3.  In any case, it 
would be useful for the Clojure Core team to document the Clojure version 
policy.



[1] http://semver.org

[2] http://apr.apache.org/versioning.html

[3] http://wiki.eclipse.org/index.php/Version_Numbering

[4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

[5] 
http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work

[6] http://en.wikipedia.org/wiki/Software_versioning

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

Re: [ANN] fs - file system utilities for Clojure

[Steve Miner]

I've been using this to get the extension:

(defn extension [file]
  (when file
(let [base (fs/basename file)
  dot (.lastIndexOf ^String base ".")]
  (when (pos? dot)
(subs base (inc dot))

Steve Miner


On Mar 15, 2011, at 5:56 PM, siyu798 wrote:

> Hi Miki,
>   We are planning to use this file system utilities, and we need a function 
> to get file extension. Currently we're using apache common for that, but we 
> want to get rid of apache common altogether.  Can you add this functionality 
> to the fs.clj? Thx
> 
> Si Yu

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

Re: "closed" maps / reducing runtime errors due to mistyped keywords

[Steve Miner]

Creating your own "Closed Map" type would be the object-oriented approach.  One 
downside is that a closed-map feels like a normal map, but can't be safely 
substituted for most maps because of the booby-trap when using assoc (etc.) 
with a new key.  It doesn't really fulfill the map contract anymore. You'll 
have to do some defensive copying if you need a normal map.

I would like to suggest a functional approach as an alternative.  It seems to 
me that the concept of "closedness" is a matter of interpretation.  It could be 
determined by the functions manipulating the data.  Sometimes you might want to 
treat the data (map) as closed and other times you might not care, so you just 
need to use the appropriate functions.

If you create your closed maps with all the allowed keys (nil values as 
appropriate), you just need to call contains? on any new key to make sure it's 
allowed.  You could do that in a pre-condition.  For example:

(defn assert-key [m k] {:pre [(contains? m k)]} k)

(defn assoc-closed [m k v] 
  (assoc m (assert-key m k) v))

(defn get-closed [m k] 
  (get m (assert-key m k)))


Steve Miner
stevemi...@gmail.com

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

Re: Key order of literal maps

[Steve Miner]

On May 3, 2011, at 7:08 AM, David Jagoe wrote:

> Can I rely on (keys some-literal-map) always returning the keys in the
> order they were defined in the literal map?

In general, the key order is not guaranteed, but an array-map will maintain the 
insertion order of the keys.  Use the array-map function to create one. There's 
a bit more info here:

http://clojuredocs.org/clojure_core/clojure.core/array-map

> An array-map maintains the insertion order of the keys. Look up is linear, 
> which is not a problem for small maps (say less than 10 keys). If your map is 
> large, you should use hash-map instead.
> 
> When you assoc onto an existing array-map, the result is a new array-map with 
> the new key as the first key. The rest of the keys are in the same order as 
> the original. Functions such as seq and keys will respect the key order.
> 
> Note that assoc will decide to return a hash-map if the result is too big to 
> be efficient.

For your specific purpose, I would be careful about using a map as an "entity" 
specification. If the order is significant, a vector of field specifiers would 
be better.  Instead of taking a map as the second argument to defentity, you 
could make it variadic like (defmacro defentity [ent & specs] ...).

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

Re: possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

[Steve Miner]

Using the array-map sounds like a good work-around when you know there are 
potential key collisions.  It would also allow you to swap keys reliably using 
a temporary key.

(rename-keys  {:a 1 :b 2 :c 3}  (array-map :a :tmp :b :a :tmp :b))
;; {:b 1, :a 2, :c 3}


The larger question is: Should rename-keys handle the collisions for you?  I 
think it was probably a pragmatic decision not to handle collisions in order to 
have better performance for the (usual) collision-free case with a small number 
of changes.  It would be good if the doc for rename-keys warned that behavior 
with key collisions is not defined.


On May 10, 2011, at 10:56 PM, Sunil S Nandihalli wrote:

> (defn rename-keys [mp kmap-fn]
>   (into {} (map (fn [[key val]] [(kmap-fn key) val]) mp)))

By the way, the suggested implementation doesn't work for keys that don't 
change (that is, when some keys that are left out of the kmap).  You get a nil 
for the key in that case.  I think it would work if the old key was used when 
you got a nil for the new key. However, you still have an issue if someone 
actually wants to use nil or false as a new key. (Not likely, but you'd need to 
document it.)

(defn truthy-rename-keys [mp kmap-fn]
  (into {} (map (fn [[key val]] [(or (kmap-fn key) key) val]) mp)))

I did a few timings and it looks like performance is similar for rename-keys 
and truthy-rename-keys when kmap has lots of key changes, but rename-keys is 
much faster when there are only a couple of key changes.  That makes sense as 
rename-keys is reducing over the kmap, but truthy-rename-keys is mapping over 
the original map.

My conclusion is that it's probably not worth "fixing" rename-keys.  A little 
extra documentation would be helpful.  I updated the ClojureDocs.org entry with 
a couple of new examples with key collisions.

Regards,
Steve Miner

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

Re: Efficient sparse vector representation...

[Steve Miner]

I've used this approach before. It was simple and worked well.  Note that assoc 
can take multiple keys and vals so you can simplify it to (assoc m k v v k) 
instead of nesting the assoc calls.  If there's any chance of a collision, you 
could be defensive and test for (contains? m k) or (contains? m v) and take 
appropriate action (maybe throw).  It might be a good thing to put into a 
pre-condition.


On May 25, 2011, at 11:12 PM, Ken Wesson wrote:

> If the token and id sets are disjoint (no single object can ever
> appear as each -- only one of those at most) then you can use a single
> map with a function put defined as:
> 
> (defn put [m k v]
>  (assoc (assoc m k v) v k))
> 
> which adds mappings in both directions. Then just use (m k) or (m v)
> to perform lookups in either direction. The overhead may be less than
> with two separate hashmaps, and the code is certainly simpler.

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

Re: CSV Handling

[Steve Miner]

On Jun 6, 2011, at 2:08 PM, octopusgrabbus wrote:

> Is there a core Java library that handles .csv files or do I need to
> download something like OpenCsv? Thanks.

I've been using csvclj successfully.  It's on clojars.org.

 [com.github.jonase.csv/csvclj "1.0.0-SNAPSHOT"]

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

Re: (merge) => nil

[Steve Miner]

On Aug 29, 2012, at 12:18 PM, Brian Marick  wrote:

> Why does `(merge)` return nil? I would have expected it to return the unit 
> ({})

I agree with your intuition -- I expected an empty map.  However, the doc says 
"Returns a map that consists of the rest of the maps conj-ed onto the first" 
which implies that correct usage needs at least one map.  As an aside, it 
doesn't say anything about nil arguments, but they seem to be supported as well 
as maps.  My guess, based on a quick look at some of the commits, is that 
allowing nil as an argument was convenient for some metadata manipulations, and 
the edge case of no-arguments wasn't considered important.  It looks like it 
would be easy to fix and probably wouldn't break any code since no one should 
be depending on the undocumented nullary behavior.

Steve Miner
stevemi...@gmail.com



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

Re: another why: (flatten #{:a :b}) => () ???

[Steve Miner]

flatten has been discussed before:

https://groups.google.com/forum/?fromgroups=#!topic/clojure/ye70iNJ73zc

See also CLJ-400, but it looks like no patch was submitted.

http://dev.clojure.org/jira/browse/CLJ-400

I think the general policy for Clojure is that the core functions of course 
should work as documented, but they do not necessarily handle undocumented edge 
cases.  So if you use the wrong kinds of arguments, the implementation does not 
have to detect your error -- it might throw or just give you non-useful 
results.  There's a trade-off among ease of implementation, performance and 
programmer friendliness.  If it's a common mistake, maybe an assertion is 
warranted.  If I remember correctly, Rich Hickey suggested that someday there 
might be an option to run a stricter version of Clojure (with lots of 
assertions) during development, and a faster version with less checking in 
production.

Regarding flatten in particular, I would like it to be faster and to do a bit 
more to help the careless programmer.  I was all set to submit a patch 
condemning the elegant but slow implementation when I noticed that the new 
"reducers" version of flatten in 1.5 alphas is amazingly fast.  So that looks 
like the way to go.



On Aug 29, 2012, at 3:47 PM, dmirylenka  wrote:

> Calling flatten on anything that is not 'sequential?' returns an empty 
> sequence:
> 
> (flatten 1); => () 
> (flatten "Hi"); => () 
> 
> With sets if feels somewhat strange:
> 
> (flatten #{#{:a} #{:b :c}}); => ()
> 
> For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}.
> 
> Ok, the docstring says: "Takes any nested combination of sequential 
> things...", and sets are not sequential...
> 
> But then, why
> 
> (reduce + (flatten #{1 2})); => 0
> (r/reduce + (r/flatten #{1 2})); => 3 ?

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

Re: Tagged literals: undefined tags blow up reader

[Steve Miner]

I added the following comment to CLJ-927 as a possible solution.  

It would be convenient if I could handle unknown tags using some sort of 
catch-all key in data-readers (say 'default). The associated function should 
take two arguments: the tag and the literal value. If there is no 'default key 
in data-readers, then an error would be thrown (same as Clojure 1.4).

I think it's a simple way to allow the programmer to take control without 
having to add new API or data types. It's just one distinguished key ('default, 
:default something like that) and one additional line of doc.

I have a patch that I'm planning to submit if dev people indicate support for 
it.  The alternative of binding another dynamic var as the unknown tag handler 
would also work for me.

Steve Miner

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

Re: syntax for defrecord literals and tagged literals

[Steve Miner]

CLJ-1100 "Reader literals cannot contain periods" has a patch that will allow 
tags to have periods. It does not address the issue of allowing a space after 
the record type for record literals.

My patch for CLJ-1100 would also allow *default-readers* to override a 
defrecord definition.  That's   wasn't explicitly the intention, but it fell 
out of the implementation.  If people don't like letting *default-readers* 
dominate records, please comment in the bug.  I think it's acceptable in order 
to support the desired periods in tags, but it might be good to have some other 
people take a look.

Regarding the original issue for this thread, it's interesting to note that the 
code for the record reader has a commented out section that would have allowed 
whitespace for the record literals.  See LispReader.java, readRecord.

https://github.com/clojure/clojure/commit/21175bc95d5f64e8142cb368e39ccd171debc56a

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

Re: Proposed change to let-> syntax

[Steve Miner]

I propose guard-> to avoid the cond-> confusion.

If we're voting, as-> is good.  I liked when->.


On Nov 30, 2012, at 10:37 AM, Rich Hickey  wrote:

> I'm not satisfied with the names for the new threading macros either. 
> 
> The new names being considered for let->, test-> and when-> are:
> 
> A) let-> becomes as->
> 
> reduces arg order and destructuring expectations.
> 
> B) test-> becomes cond->
> 
> cond-> was the original name, and, protestations about not short-circuiting 
> like cond notwithstanding, it is still the best fit. The doc string will say:
> 
> "Note that, unlike cond branching, cond-> threading does
>  not short circuit after the first true test expression."
> 
> C) when-> becomes some->
> 
> and in doing so, tests for non-nil rather than truth.
> 
> ==
> This last one touches on the general area of non-nil-ness, often needed. 
> Other possible (future) ideas in line with this are:
> 
> (some? x) == (not (nil? x))
> 
> (some coll) ;;note no pred, == (some some? coll)
> 
> this is tricky, as we are bridging CL's some and Maybe's Some
> 
> if-some, when-some et al.
> 
> (some! x) ;;(or somex ?) identity for all but nil, which throws
> 
> etc
> ==
> 
> Last chance for fabulous and better names than these: (as->, cond-> and 
> some->). Note that "cond-> doesn't match cond's short-circuit" has been 
> considered already, please do not repeat.
> 
> Thanks,
> 
> Rich
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Proposed change to let-> syntax

[Steve Miner]

gate-> would work.  Like guard-> it doesn't have any connotations in the 
Clojure world, but it's learnable.  I'll add one more: qual-> ... short for 
"qualified threading macro".  Each clause is qualified by a test condition.

Of course, there's always conde-> to borrow from miniKanren and core.logic.  
The "e" stands for "every" because multiple clauses can succeed as opposed to 
the short-circuiting cond.


On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:

> 
> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
> 
>> I propose guard-> to avoid the cond-> confusion.
>> 
> 
> Yeah, that came up. Guards in other langs are short circuiting, just like 
> cond.
> 
> Another in that camp was gate->

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

Re: Default random in Clojure doesn't seem to fit fp paradigm

[Steve Miner]

You should treat rand and friends like i/o.  Don't bury them deep in your code. 
 Write your pure functions so that they take a seed value (or sequence).  
Generate the random values from outside of the important functions,  maybe 
providing a convenience wrapper function around your main logic.

(defn foo-pure [val seed] ...)

(defn foo-uses-rand [val] (foo-pure val (rand)))


On Dec 5, 2012, at 1:48 PM, JonC  wrote:

> Ok: first of all, Clojure has outstandingly the best core library I've seen. 
> I am awed by how wonderfully the protocol approach makes data structures, and 
> the good taste applied to getting an API that's reasonably minimal and 
> wonderfully complete. I've not posted before because I've had nothing to ask 
> - everything is super-clear, especially now I have a copy of JoC. But I would 
> suggest that there is one easily corrected area where things are imperfect: -
> 
> One of the big advantages of functional coding to me is rock solid 
> testability - same inputs, same outputs; easy to test, easy to debug. 
> 
> Obviously psuedo-random  numbers and io present problems with this. Now, the 
> normal way for an API to discourage something problematic is to make it 
> difficult, and to encourage correct behavoiur by making it easy. So list's 
> lack of nth but possession of first, second rest and last shout out "Do NOT 
> use for random access!" while vector's api says "Use me instead!"
> 
> Now we come to rand, rand-int, rand-nth. They're the easiest things to use 
> for their purpose, so they shout "Use me!" But.. they break the repeatability 
> paradigm. Because they use Java's default random number generator instance, 
> which has a private and unsettable seed, you can't get repeatabilty. In Java, 
> this isn't actually too awful because you can instantiate an rng of your own 
> and use it in just the same way - but if you do this in clojure, bang goes 
> your rand-nth. Yes, the problem is one you can easily solve with a few 
> minutes coding. But an api should gently lure into doing things the right way 
> rather than wrong one - so wouldn't it be a good idea to add change the 
> standard api to include a function that takes a seed? A random that allows 
> you to see the last "seed" would be even better. That way when you get
> 
> => (foo-uses-rand "bar')
> ..crazy result *sometimes*
> 
> then
> 
> => (def wrong (get-last-rand-seed))
> 
> would give you the seed needed to repeat the last call to any random fn. So 
> you could fix your code and verify by re-seeding with "wrong" and repeating 
> the function call.
> 
> To me this seems a nice low-impact solution. It wouldn't make repeatability 
> bullet proof, but I'd suggest it would be an easily implemented mild 
> improvement for a future version of 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

Re: reader literal , tagged literal

[Steve Miner]

I'd say that "tagged literal" is the preferred term for expressions like #inst 
"2012".  The term "reader literal" might perhaps refer to any literal (number, 
string, etc.) that doesn't need any further evaluation, although I think people 
use it loosely to mean the same thing as "tagged literal".

A data-reader would be the function assigned to read the tagged literal.  See 
*data-readers* and default-data-readers.

On Dec 22, 2012, at 12:03 PM, John Gabriele  wrote:

> Are "reader literals" the same thing as "tagged literals"? (It appears
> that the Clojure 1.4 changes.md file refers to them as "reader
> literals", but http://clojure.org/reader calls them "tagged
> literals".)
> 
> Thanks,
> ---John
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: clojure defining a var with a dot in the name is accepted in clojure 1.5-RC1, but probably shouldn't?

[Steve Miner]

It looks like Clojure 1.4 does the same thing so it's probably been hiding for 
a while.  The fully qualified var works.

user=> (def foo1. 2)
#'user/foo1.
user=> foo1.
CompilerException java.lang.ClassNotFoundException: foo1., 
compiling:(NO_SOURCE_PATH:0) 
user=> user/foo1.
2

On Dec 22, 2012, at 3:34 PM, Borkdude  wrote:

> I was playing around with 1.5-RC1 and stumbled unto this behavior:
> 
> https://www.refheap.com/paste/7817
> 
> Clojure lets me define a var which name contains a dot, but I can't 
> dereference it by name (because it is seen as a classname with a method or 
> field). Clojure shouldn't let me let define it in the first place I think?
> 
> (I was trying to get a list of all vars added to clojure 1.5, the fact that I 
> have used the value 2 in the refheap isn't the point).
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: What's the current status of Clojure-in-Clojure?

[Steve Miner]

I think you're looking for:

https://github.com/kanaka/clojurescript

I just saw a tweet about a talk be accepted for ClojureWest:

https://twitter.com/bus_kanaka/status/289037484787118080

On Jan 8, 2013, at 6:44 PM, Thor  wrote:

> I think this would be a fun project to contribute to, but a few searches 
> haven't led me to where the development is taking place. Is it just part of 
> the main Clojure github project?
> 
> 

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

Re: List comprehension not running

[Steve Miner]

(dotimes [x 10] ...)  should do the trick if you're just interested in side 
effects.

On Jun 16, 2011, at 12:24 PM, Baishampayan Ghose wrote:
> 'for' is not recommended for causing side-effects. Since you are not using 
> the return value of the for comprehension, the lazy sequence is not getting 
> realised. You can either use 'doall' around it or better still, use 'doseq'.
> 

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

Re: Please stand firm against Steve Yegge's "yes language" push

[Steve Miner]

On Jul 6, 2011, at 10:06 PM, nchubrich wrote:

> And as to improving
> documentation, how is one to go about doing it?  This would be an
> excellent area to have some community effort on, especially from
> relative beginners, and that is an itch I would not mind scratching.


Stuart Halloway responded about how to contribute to the "Getting Started" 
documentation.

If you want another place for language documentation, take a look at 
ClojureDocs.org. Anyone can sign up and contribute examples and usage notes.


Steve Miner

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

Re: Apply concat and mapcat evaluate seqs unnecessarily

[Steve Miner]

I'd be careful about writing my own version of mapcat.  You might save a call 
or two on the f function, but you'll probably lose in the general.  Try some 
experiments with larger take numbers.  You might be better off concentrating on 
your f function.  I've found that trying to special-case degenerate cases (for 
empty collections, etc.) has actually hurt my performance, presumably because 
my cleverness got in the way of hotspot optimizations.  


On Aug 22, 2011, at 10:32 AM, Asim Jalis wrote:

> user=> (defn f [[x]] (println "computing x:" (inc x)) (vector (inc x)))
> #'user/f
> user=> (->> (iterate f [0]) (take 0))
> ()
> user=> (->> (iterate f [0]) (apply concat) (take 0))
> computing x: 1
> computing x: 2
> computing x: 3
> ()
> user=> (->> (iterate f [0]) (mapcat identity) (take 0))
> computing x: 1
> computing x: 2
> computing x: 3
> ()
> 
> Is there a way to rewrite mapcat (or apply concat) so that they don't
> evaluate the incoming seq unnecessarily?
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: get keys from defrecord

[Steve Miner]

On Aug 29, 2011, at 8:20 PM, Alex Miller wrote:

> I'm not sure if there are any enhancements in the 1.3 record support
> for this feature.


In 1.3beta2, the record class has a static method getBasis that will give you 
the fields.  I remember Fogus mentioning this on the mailing list.  The design 
notes [1] say "These methods should not be used in Clojure code" as they're 
intended for tool support, but they seem generally useful to me.

user=> (clojure-version)
"1.3.0-beta2"
user=> (defrecord MyRecord [a b])
user.MyRecord
user=> (MyRecord/getBasis)
[a b]


[1] http://dev.clojure.org/display/design/defrecord+improvements


Steve Miner

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

Re: ANN: core.match 0.2.0-alpha5

[Steve Miner]

I've just been playing around a bit with match so please forgive me if I've 
missed some prior discussions regarding issues that are considered settled.

One of my first attempts was to match a vector of two of the same thing using a 
pattern like [a a].  I naively thought that would imply an equality constraint 
between the two items, but in fact each variable matched anything 
independently. I now understand that the pattern variables are considered in 
different scopes, but I think it's confusing.  It's reasonable that you want 
something faster than unification for simple literal patterns, but this to my 
mind is a special case that's likely to trip people up.

My work-around is to use something like this:

(match [x y]
[a (b :when #(= % x))] :match
:else :no-match)

But that doesn't look very nice, and it gets worse with multiple pattern 
variables.  Still, it doesn't look too hard to make that sort of conversion 
automatically so maybe I'll try to write a macro.  (Famous last words. :-)

In any case, if using multiple pattern variables of the same name does not 
imply an equality constraint, I suggest that it be considered an error to reuse 
a pattern variable.  It's better to throw than to yield an unexpected match.

Regarding OR patterns, I didn't really like the infix notation, (1 | 2).  As a 
lisper, I'd prefer to use something like (or 1 2), or maybe even a Clojure set 
notation: #{1 2}. I'm guessing you already thought about this and made your 
decision on syntax, but I thought I'd throw it out there.

For guards, I wonder if the extra parens are really necessary.  Couldn't the 
:when bind tightly to the previous pattern variable?  Like Clojure FOR 
comprehensions.  I think it would be easier to read that way.  Same comment 
applies to :as.  To cover the rare case of matching a literal :when or :as, you 
could quote it or use it as the first item in an OR pattern.

As others have suggested, I agree that returning nil when nothing matches makes 
sense.  That was my original expectation.

It was common when testing to wrap a let around the match so I made a little 
macro to save a few characters.  Free for anyone who wants it.  :-)

(defmacro match-let [bindings & body]
  (let [bindvars# (take-nth 2 bindings)]
`(let ~bindings
   (match [~@bindvars#]
~@body


Steve Miner
stevemi...@gmail.com

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

Re: ANN: core.match 0.2.0-alpha5

[Steve Miner]

> match-let looks good. I see that you are Clojure contributor - I'm more than 
> happy to include this.

Yes, I'm a registered contributor.  It's all yours.

I'll take a look at the code and see if I can fix things for myself regarding 
the implied equality constraints and guard clauses.

By the way, there is a recurring typo in the README and the code: "occurance" 
should be "occurrence".

Steve Miner
stevemi...@gmail.com

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

Re: Exception handling changes in Clojure 1.3.0

[Steve Miner]

I've done something like this in Java projects but without any magic 
unwrapping. It worked well.  Manual unwrapping wasn't too onerous in the rare 
cases where we wanted to do so.  The Clojure-specific exception should be part 
of the public API for Java interop. Don't try to hide it.



On Oct 12, 2011, at 8:20 AM, Ivan Koblik wrote:

> I wonder, would it be possible to throw a custom exception (something like 
> DoNotUse_InternalRuntimeException) in Reflector.java, and update try/catch 
> code to always unwrap 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

Re: Symbol matching in core.match

[Steve Miner]

On Nov 30, 2011, at 3:04 PM, David Nolen wrote:

> (quote foo) should be interpreted as a literal match. I thought this was 
> addressed by a previous user submitted patch but it doesn't look like that's 
> true.

I wrote a patch that treated quoted keywords as literals so that ':when could 
be used to match a literal :when as opposed to introducing a guard.  Sorry, I 
didn't think about the case of literal symbols.  I assumed they already worked 
that way.  Hmmm, maybe there's a difference between the :seq and vector 
matching.   I will take a look tomorrow to see if I can come up with a patch.

The complaint about reusing symbols is also my contribution.  Maybe match 
bindings should be limited to symbols starting with an alphabetic character.  I 
doubt anyone really wants to bind to symbols that look like operators.  They 
could be treated as literals for the sake of matching.  Any opinions on that?

Steve Miner

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

Re: Symbol matching in core.match

[Steve Miner]

I filed the bug and attached a patch.  The check for duplicate wildcards now 
ignores anything that's quoted.  I'm in a rush so it might be good for others 
to try it out.

http://dev.clojure.org/jira/browse/MATCH-42


Steve Miner
stevemi...@gmail.com

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

Re: Matching core.match's syntactic keywords

[Steve Miner]

On Dec 22, 2011, at 10:54 PM, Herwig Hochleitner wrote:

> I want to match vectors of the form [(some expr) :as :label], but  #(match 
> [%] [[expr :as (label :when keyword)]] {:expr expr :label label}) throws a 
> compiler exception: Unable to resolve symbol expr
> 


If you want to match a literal keyword that has a special meaning to match, you 
need to quote it. (It's always safe to quote the keyword literals when in 
doubt.)  Also, I think your :when test should be keyword? (to make sure 
something is a keyword, rather than creating one).  The following works for me:

(match [['(some expr) :as :label]] 
   [[expr ':as (label :when keyword?)]] {:expr expr :label label})

;=> {:expr (some expr), :label :label}


--
Steve Miner
stevemi...@gmail.com

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

Re: Any char-based Java file I/O with arbitrary seek?

[Steve Miner]

On Jan 5, 2012, at 5:07 PM, Andy Fingerhut wrote:

> I realize that with variable-length multi-byte character encodings like 
> UTF-8, it would be a bad idea to seek to a random byte position and start 
> trying to decode a UTF-8 character starting at that byte position.  I'm 
> thinking of cases where you have an index of byte positions of interest you 
> want to jump to in the future that are known to be the first byte of a 
> character in the appropriate encoding.  I also realize that one must be very 
> cautious in writing to the middle of such a file, since byte lengths of 
> strings are variable.


I can't help too much, but the comment about UTF-8 rang a bell.  It's actually 
not that hard to find a valid character by jumping to a random position.  You 
just need to be able to back up a few bytes.

http://en.wikipedia.org/wiki/UTF-8

>   * All continuation bytes (byte nos. 2-6 in the table above) have 10 as 
> their two most-significant bits (bits 7-6); in contrast, the first byte never 
> has 10 as its two most-significant bits. As a result, it is immediately 
> obvious whether any given byte anywhere in a (valid) UTF-8 stream represents 
> the first byte of a byte sequence corresponding to a single character, or a 
> continuation byte of such a byte sequence.

>   * As a consequence of no. 3 above, starting with any arbitrary byte 
> anywhere in a (valid) UTF-8 stream, it is necessary to back up by only at 
> most five bytes in order to get to the beginning of the byte sequence 
> corresponding to a single character (three bytes in actual UTF-8 as explained 
> in the next section). If it is not possible to back up, or a byte is missing 
> because of e.g. a communication failure, one single character can be 
> discarded, and the next character be correctly read.


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

Re: Problem with :pre checks against nil in 1.3.0?

[Steve Miner]

The precondition should be a vector of expressions.

 (defn foo [x] {:pre [(not (nil? x))]} (* 3 x))


On Jan 9, 2012, at 12:53 PM, Tom Chappell wrote:

> Ok, I've got a couple thousand lines of Clojure under my belt, but
> this has me stumped, unless it's a compiler etc. issue.  If I'm
> missing something dumb, what is it, please?
> 
> I have a function that is failing a not-nil precondition.  Here are
> four versions of the same test; only #3 works correctly.  Obviously I
> can work around the problem, but am I doing something wrong?
> 
> user> (def fq (frequencies "abbccc"))
> #'user/fq
> 
> user> fq
> {\a 1, \b 2, \c 3}
> 
> user> (fq \a)
> 1
> 
> user> ; incorrectly fails :pre
> (defn test-fun1
>  [mp k]
>  {:pre (not (nil? (mp k)))}
>  (mp k))
> #'user/test-fun1
> 
> user> (test-fun1 fq \a)
> 
> Assert failed: (nil? (mp k))
>  [Thrown class java.lang.AssertionError]

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

Re: How to loop over several sequences in parallel for side-effects?

[Steve Miner]

On Jan 20, 2012, at 2:41 PM, Lars Nilsson wrote:

>  => (map #(vector %1 %2) [1 2 3] ['a 'b 'c])
>  ([1 a] [2 b] [3 c])

Sorry if I'm drifting a bit off topic, but I just wanted to point out that it's 
convenient to use just the function name if the arguments are already in the 
appropriate order.  Also, it is sometimes convenient to quote a vector rather 
than the individual elements.  For example, the following is an equivalent 
expression:

(map vector [1 2 3] '[a b c])

Of course, wrapping the expression in dorun is necessary if you care about 
forcing side-effects.

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