Will it ever be possible to use reader conditionals in clojure macros

[Arewa Olakunle]

I have been trying to define a macro for clojurescript/clojure using  a 
cljc file

(ns async
  (:require #?(:clj [clojure.core.async :as a :refer [go-loop]])
#?@(:cljs [[cljs.core.async :as a]
  [cljs.core.async.macros :refer [go-loop]]])))

(defmacro dochan
  "Wrap the expressions in a go-loop over the single binding to a channel
  till the chan closes"
  [chan & body]
  (let [[name channel-expr] binding]
`(let [channel# ~channel-expr]
   (a/go-loop [~name (a/http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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 


(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] Virgil 0.1.6

[Mike Rodriguez]

I've have used this as a lein plugin and I think it is a really great tool 
to have available.  It makes working on Java or a hybrid Java/Clojure 
project more tolerable.

On Thursday, March 16, 2017 at 2:13:35 PM UTC-4, Zach Tellman wrote:
>
> I figured it was worth reminding everyone that this library exists: 
> https://github.com/ztellman/virgil.  It now seems to work on Java 
> projects of arbitrary size and structure (the in-process compiler is very 
> fussy about compile order, you need to topologically sort the classes), and 
> I've been using it extensively this last month while writing a bunch of 
> Java [1].  I can tweak some Java, wait a second, and then test that code at 
> the REPL.  It's been pretty game-changing for my workflow.
>
> If anyone has questions, I'm happy to answer them.
>
> Zach
>
> [1] https://github.com/lacuna/bifurcan
>

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

[Arewa Olakunle]

Sorry I posted this here, wasn't aware of clojurescript group. Found a 
similar posting(almost a clone) here 

 with 
a useful hack here 


On Friday, March 17, 2017 at 1:37:27 PM UTC+1, Arewa Olakunle wrote:
>
> I have been trying to define a macro for clojurescript/clojure using  a 
> cljc file
>
> (ns async
>   (:require #?(:clj [clojure.core.async :as a :refer [go-loop]])
> #?@(:cljs [[cljs.core.async :as a]
>   [cljs.core.async.macros :refer [go-loop]]])))
>
> (defmacro dochan
>   "Wrap the expressions in a go-loop over the single binding to a channel
>   till the chan closes"
>   [chan & body]
>   (let [[name channel-expr] binding]
> `(let [channel# ~channel-expr]
>(a/go-loop [~name (a/  (if (some? ~name)
>(do
>  ~@body
>  (recur (a/(a/close! channel#))
> ;; in CLJS
> (ns cljs
>   (:require [cljs.core.async :as a]))
>
> (dochan [e (a/chan 10)]
>   (println "Auto-insert" e)) ;; keeps throwing exception saying it cannot 
> find clojure.core.async
>
>
> Further macroexpansion in cljs-repl confirmed what I was saying with the 
> resulting code using clojure.core.async. So I came to the conclusion that 
> since clojurescript relies on clojure for macros, it would use clojure to 
> load the macros , hence making the reader conditionals work like the 
> macro's to be used in a clojure file. Another weird thing happened though. 
> It was auto-inserting clojure.core.async whenever I remove the :clj 
> require. I am guessing it's cider because whenever I started a different 
> repl it would behave normally, using a alone rather than cojure.core.asyn
>
>

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

[arthur]

Daniel,

 I'll check out OSGi (you might be right about the cure being worse). I 
think Java 9 modules were originally supposed to include versioning as 
well, but currently "The State of the Module System" says "A module’s 
declaration does not include a version string, nor constraints upon the 
version strings of the modules upon which it depends. This is intentional: 
It is not a goal 
 of 
the module system to solve the version-selection problem, which is best 
left to build tools and container applications".

On Thursday, March 16, 2017 at 4:29:47 PM UTC-4, Daniel Compton wrote:
>
> One option to help with this is OSGi which does have support in Clojure. 
> https://github.com/talios/clojure.osgi
>
> As Stuart alluded to in his message, the cure to dependency conflicts 
> (OSGi) may be worse than the disease. I’d guess that the venn diagram of 
> people using both Clojure and OSGi is pretty thin. There is also 
> Jigsaw/JPMS in the upcoming Java 9 which is another take on modularity: 
> https://www.infoq.com/articles/java9-osgi-future-modularity.
>
> On Fri, Mar 17, 2017 at 5:20 AM > 
> wrote:
>
>> Howard, thanks for posting that library. I've passed on the info to some 
>> of the other developers at work. That kind of tool is highly valuable, I'll 
>> likely start using it soon.
>>
>> Gary, the MrAnderson approach sounds similar to shading; I'll take a look 
>> today.
>>
>> Stuart, the most common approach boils down to trust and hope, and I 
>> don't think it's good enough. As projects grow larger the likelihood of 
>> running into incompatibilities also grows, regardless of community 
>> etiquette. Thank you for suggesting :pendantic.
>>
>>
>> On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship 
>> wrote:
>>
>>> We have some very, very complex projects that bring in boat-loads of 
>>> dependencies, some of which will have version conflicts, if left 
>>> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to 
>>> see the artifact tree, identify and repair conflicts, and determine why any 
>>> particular artifacts are in the build.
>>>
>>> https://github.com/walmartlabs/vizdeps
>>>
>> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra  
>>> wrote:
>>>
>> This is a well-known problem in the JVM world, not just Clojure.

 The most common approach is: Always use the latest versions, and don't 
 break backwards-compatibility.

 Most open-source Java and Clojure libraries are careful about not 
 breaking backwards-compatibility. So in general, you're safe choosing the 
 latest version of any library.

 Leiningen has the `:pedantic` option which can be set to warn or fail 
 when there are possible dependency conflicts.

 Neither Clojure nor the JVM has explicit support for linking to 
 specific versions of a library. Work-arounds exist, but they often 
 increase 
 overall complexity and lead to conflicts which are harder to debug.

 –S


 On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in 
> Clojure projects and how they affect applications at runtime. I believe 
> this is a common problem faced by many languages in this day and age 
> where 
> we try not to reinvent the wheel by depending on the work of others. 
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. 
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us 
> depend on *different versions* of library *A.* Leiningen thankfully 
> warns us in many of these situations by suggesting exclusions. However, 
> how 
> can I possibly know that something hasn't broken? Stringent testing can 
> give a certain degree of confidence that things are still working, but it 
> would seem to me that to ensure correctness, we should include *all* 
> versions 
> of the dependencies and have the functions link to their respective 
> *versioned* identites. Does anyone have advice on how they solve 
> these kinds of problems on their codebases in the wild? Thankfully 
> nothing 
> has broken yet (to my knowledge), but it seems we have very few 
> assurances 
> here and the best we can do is *hope* nothing is broken. Any advice 
> is much appreciated.
>
> Thanks,
>
> Arthur
>
 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.

>>> To post to this group, send email to clo...@googlegroups.com

>>>
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to

>>> clojure+u...@googlegroups.com

>>>
 For more options, visit this group at
 http://groups.google.com/gr

Defrecord Conflict

[tmountain]

Say that I have the following:

-- ns1.clj --
(ns multi.ns1)
(defrecord Animal [name])


-- ns2.clj --
(ns multi.ns2)
(defrecord Animal [name])

-- core.clj --
(ns multi.core
  (:require [multi.ns1]
[multi.ns2])
  (import [multi.ns1 Animal]
  [multi.ns2 Animal]))


My intent is to have a multimethod with target such as:

(defmethod stringify multi.ns1.Animal ...)
(defmethod stringify multi.ns2.Animal ...)

My problem is that I'm forced to use import to bring in the records defined 
in ns1 and ns2, but once I do this, I lose the ability to refer to these 
classes by their fully-qualified names and the following conflict occurs.

java.lang.IllegalStateException: Animal already refers to: class 
multi.ns1.Animal

This actually works from the repl, which tells me it's getting the records 
onto the classpath ahead of time.



multi.core=> (require 'multi.ns1)
nil
multi.core=> (require 'multi.ns2)
nil
multi.core=> multi.ns1.Animal
multi.ns1.Animal

I bumped into this in the process of exploring the expression problem. Is 
there a way around 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: Defrecord Conflict

[Francis Avila]

Import does not demand name mapping. You can import a full path without 
aliasing.  This will work fine:

(ns multi.core
  (:require [multi.ns1]
[multi.ns2])
  (:import [multi.ns1.Animal]
   [multi.ns2.Animal]))

(multi.ns1.Animal. "hi")

(But remember to use the keyword :import, not the symbol. This will be 
tightened up in the future.)


On Friday, March 17, 2017 at 4:28:09 PM UTC-5, tmountain wrote:
>
> Say that I have the following:
>
> -- ns1.clj --
> (ns multi.ns1)
> (defrecord Animal [name])
>
>
> -- ns2.clj --
> (ns multi.ns2)
> (defrecord Animal [name])
>
> -- core.clj --
> (ns multi.core
>   (:require [multi.ns1]
> [multi.ns2])
>   (import [multi.ns1 Animal]
>   [multi.ns2 Animal]))
>
>
> My intent is to have a multimethod with target such as:
>
> (defmethod stringify multi.ns1.Animal ...)
> (defmethod stringify multi.ns2.Animal ...)
>
> My problem is that I'm forced to use import to bring in the records 
> defined in ns1 and ns2, but once I do this, I lose the ability to refer to 
> these classes by their fully-qualified names and the following conflict 
> occurs.
>
> java.lang.IllegalStateException: Animal already refers to: class 
> multi.ns1.Animal
>
> This actually works from the repl, which tells me it's getting the records 
> onto the classpath ahead of time.
>
>
>
> multi.core=> (require 'multi.ns1)
> nil
> multi.core=> (require 'multi.ns2)
> nil
> multi.core=> multi.ns1.Animal
> multi.ns1.Animal
>
> I bumped into this in the process of exploring the expression problem. Is 
> there a way around 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.

instrument code only in dev, with lein

[Brian Craft]

How do you instrument code, e.g. apply ring wrap-reload, 
wrap-stacktrace-web, etc., only in dev, not in uberjar?

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

[Matching Socks]

In a nutshell: leverage distinct classpaths.  Adjust the :dev profile in 
project.clj to prepend a directory other than src to :source-paths, and 
likewise a directory other than resources for :resource-paths.  In 
development, use code or resources from the dev classpath to override 
default behaviors on the uberjarred classpath.  See the sample Lein 
project.clj:

https://github.com/technomancy/leiningen/blob/master/sample.project.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.

livecoding with Quil middleware

[Jay Porcasi]

hello, i hope this is the place to discuss questions about Quil (i couldn't 
find a dedicated forum)

and first of all, kudos to Nikita for this incredible library, which i find 
even better than the original Processing
it's not just a matter of using a different syntax than java, but Nikita 
actually created something more powerful and flexible than Processing

i'm particularly fond of the middleware functionality, which is a stroke of 
genius: so simple in retrospect and so powerful, opening a whole new way of 
possibilities of structuring one's own work in a modular fashion

so i have one question regarding live coding and middleware

if i redefine a function that i associate to :setup, :update or :draw keys, 
i can see my running sketch changing on the fly, reflecting the new 
definitions

this is not the case however if i redefine a function that i use as a 
middleware

is it an intrinsic limitation? would it be possible to extend the live 
coding behaviour to middlewares as well?

thanks and long live Quil,
Jay

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