Re: Expected inconsistency between set and map w/ ArrayList?

[Michał Marczyk]

I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
hashes consistent with those of appropriate Clojure collection types
on the ticket.

Performance of repeated hasheq lookups on a single PHM actually seems
to be slightly better with this patch applied. Adding the hasheqs of a
PHM, a string and a long takes slightly longer than on 1.6.0. See the
ticket for details.

The patch also changes "default" return-the-hashCode behaviour of
hasheq to match Strings. That's mostly because I originally wanted to
leave out the String case altogether, but that seems to hurt String
hashing quite badly. The original branch is up on GitHub, however (see
ticket for link).


On 13 May 2014 04:13, 'Mikera' via Clojure Dev
 wrote:
> On Monday, 12 May 2014 00:33:25 UTC+1, Alex Miller wrote:
>>
>> On Sun, May 11, 2014 at 2:06 PM, Mikera  wrote:
>>>
>>> OK. this thread is a bit worrying. If I understand correctly, it
>>> means that we've now got inconsistent hash and equals functions. I suspect
>>> this hasn't bitten many people yet simply because it is unusual to mix Java
>>> and Clojure collections as keys in the same structure, but it seems like a
>>> really nasty issue.
>>
>>
>> Reports of real problems in real codebases would change my own opinion of
>> the severity of this issue.
>
>
> Are you suggesting correctness issues in APIs aren't severe? This is broken
> according to the documentation. From the docstrings:
>
> clojure.core/= "Same as
>   Java x.equals(y) except it also works for nil, and compares
>   numbers and collections in a type-independent manner."
>
> clojure.core/hash "Returns the hash code of its argument. Note this is the
> hash code
>   consistent with =, and thus is different than .hashCode for Integer,
>   Short, Byte and Clojure collections."
>
> This promises consistency, and also promises behaviour that works like
> x.equals(y) and x.hashCode() - except for a a few defined exceptions. Which
> means I should expect them to work on arbitrary Java objects.
>
> As a result, all sorts of code that depends on hashes directly or indirectly
> now has subtle bugs. clojure.core/merge is now broken for example:
>
> (let [a {[1 2] :a}
>   b {(java.util.ArrayList. [1 2]) :a}
>   m (zipmap (range 20) (range 20))]
>   [(= a b)   (= (merge m a) (merge m b))])
> => [true false]
>
> I hope everyone agrees that this isn't the kind of behaviour we want in core
> functions?
>
>>
>>>
>>> Hash and equality functions generally have a very simple rule: if two
>>> things are equal they must have the same hashcode. But now we've got:
>>>
>>> (= (java.util.ArrayList. [1 2]) [1 2])
>>> => true
>>>
>>> (hash (java.util.ArrayList. [1 2]))
>>> => 994
>>>
>>> (hash [1 2])
>>> => 156247261
>>>
>>> I consider this a major defect. If we want to define our own equals and
>>> hashcode that's fine, but then these functions absolutely should be
>>> consistent with each other.
>>>
>>> If it is really true that non-Clojure collections aren't considered as
>>> values and aren't expected to participate in hash/= comparisons then I'd
>>> expect an exception, not an erroneous value. Silent potential corruption of
>>> data is *much* worse than a noisy failure. But I think even that is a bad
>>> direction to go: easy Java ecosystem interop is definitely one of the main
>>> reasons why I'm using Clojure, and I'd like to see this maintained.
>>
>>
>> Please be more specific about where an exception could be thrown (equals
>> vs hash vs collection usage).
>>
>>> I can think of only two sensible ways to fix this inconsistency:
>>> a) Roll back the hash changes. Correctness is much more important than a
>>> performance edge case.
>>
>>
>> We're not doing that.
>>
>>>
>>> (I suspect the hash changes have hurt average case performance anyway...)
>>
>>
>> We have made hash calculation slightly slower to generate better hashes
>> across the board. Timing info is at
>> http://dev.clojure.org/display/design/Better+hashing but in general, the
>> time increases per hash are on the order of nanoseconds for simple values
>> and sub-millisecond for more complicated strings and collections (where
>> hashes are cached and times are likely to be dwarfed by other things). The
>> better hashes avoid catastrophically bad (and relatively easy to find)
>> cases.
>>
>>
>> It is quite challenging to predict the performance impact of the hashing
>> changes in Strings, keywords, and symbols due to the effects of usage
>> patterns, interning, caching, etc. I am aware of several people that have
>> reported better performance overall in 1.6 and I don't think I've heard any
>> reports of significantly slower performance in 1.6. I'm calling FUD on this
>> unless you have data to report.
>
>
> It's absolutely not FUD. I'm generally a pretty big Clojure evangelist
> and my aim here is simply to be very clear about issues so that we can
> improve Clojure. I hope all my comments are taken in that spirit.
>
> The page you have linked shows that the hashin

Re: "recursive" hierarchies and derive

[Leif]

Hi, Ranko.

I *think* it's because vectors are handled specially during dispatch, to 
easily handle both dispatching on multiple args and hierarchies:

"isa?works
 with vectors by calling 
isa?on
 their corresponding elements:

(isa? [::square ::rect] [::shape ::shape])"

--Leif

On Monday, May 12, 2014 8:41:35 PM UTC-4, r wrote:
>
> Why is something like 
>
> (derive [::matrix ::ring-element] ::ring-element)
>
> prevented by the assertion in clojure.core/derive?
> Is there something that is an actual show-stopper 
> or is this an implementation detail?
>
> Cheers,
> ranko
>
>
>

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

Re: using atoms as logs for channels in core.async

[gamma235]

Hey guys, I took your suggestions and just wanna deliver the finished 
product. I included the macro in there for practice, but agree it is 
probably not necessary. Thanks for all your help. 

p is for pretty :)
 

> (defn pchan [ch]
>   {:channel ch, :buffer (atom [])})
>
 

> (defn pbuff [{:keys [ch buffer]}]
>(println @buffer))
>
 

> (defn pput [{:keys [channel buffer]} v]
>   (do 
> (go 
>  (>! channel v))
> (swap! buffer conj v)
> (println "put " v)))
>
 

> (defn ptake [{:keys [channel buffer]}]
> (go 
>  (let [v ((if-not (empty? @buffer)
> (do 
>(swap! buffer pop)
>(println "took " v)
> (println "take pending ..."))
>
 

> (defmacro def-pchan
>   ([name]
>`(def ~name (pchan (chan
>   ([name buff]
>`(def ~name (pchan (chan ~buff)
>
 

> (defn clear-buffer [{:keys [buffer]}]
>   (reset! buffer []))
>
> it works!  

> (def-pchan pc)
> (:buffer pc)
> (pbuff pc)
> (ptake pc)
> (pput pc 42)
> (clear-buffer pc)

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

[ru]

Before creating own rete implementation I have used in my applications 
Drools for several years. Drools is becoming more and more complex and in 
the end ceased to support my applications. I decided to create my own 
implementation as simple as possible to have a full control and quick 
search in case of an error in application. As I understand from quick look 
Clara rete implementation is a similar to Drools.  It is intresting to 
compare Clara, Drools and rete4frames on traditional benchmarks such as 
Mrs.Manners and Waltz algorithm. I tried to compare my implementation with 
Drools, but Manners example of Drools in the last version I looked at was 
brocken. I wrote to Mark Proctor about this and he promised to fix this but 
I did not look at that ever since.. :( Hope I will find time to accomplish 
this comparison.

понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:
>
> New feature: added Java interface. Eclipse project example.
>
> Home: https://github.com/rururu/rete4frames
>
> Have fun!
>
> Sincerely,
>   Ru
>

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

Re: *data-readers* with clojure.tools.reader -- No reader function for tag id

[Sarkis Karayan]

I got this to work by modifying my read-all function to convert the results 
from the take-while into a vector.
Not entirely sure why it makes a difference, but I got through it for now.
Interestingly, calling vec isn't needed when using clojure.tools.reader.edn.

Thanks for your help.


(defn read-all [source-code]
  (let [reader (readers/source-logging-push-back-reader source-code)
eof(Object.)]
(binding [r/*data-readers* *data-readers*]
  (vec
(take-while #(not= % eof)
  (repeatedly #(r/read reader false eof)))


On Monday, May 12, 2014 6:53:45 PM UTC-4, Sarkis Karayan wrote:
>
> Doesn't seem to work:
>
> (ns literal-test
>   (:require [datomic.api :as d]
> [clojure.tools.reader :as r]
> [clojure.tools.reader.reader-types :as readers]))
>
> (defn read-all [source-code]
>   (let [reader (readers/source-logging-push-back-reader source-code)
> eof(Object.)]
> (binding [r/*data-readers* *data-readers*]
>   (take-while #(not= % eof)
> (repeatedly #(r/read reader false eof))
>
> (read-all "#db/id [db.part/user -100]")
>
>
>
> *ExceptionInfo No reader function for tag id  clojure.core/ex-info 
> (core.clj:4327)*
>
> Any ideas?
>
> Thanks,
> Sarkis
>
>
>
> On Monday, May 12, 2014 6:27:13 PM UTC-4, Nicola Mometto wrote:
>>
>> (binding [clojure.tools.reader/*data-readers* *data-readers*] 
>>   (clojure.tools.reader/read ..))
>> is probably what you want.
>>
>>
>> On Tue, May 13, 2014 at 12:17 AM, Sarkis Karayan wrote:
>>
>>> Hi everyone,
>>>
>>> I am trying to use clojure.tools.reader to read from a file and also 
>>> process datomic #db/id literals, but I am not sure how to pass in the 
>>> *data-readers*?
>>>
>>> clojure.tools.reader.edn allows something like this:
>>> (edn/read reader false eof { :readers *data-readers* } )
>>>
>>> Is there something equivalent with clojure.tools.reader?
>>>
>>> Thanks,
>>> Sarkis
>>>
>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [ANN] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[Alan Moore]

On Monday, May 12, 2014 10:29:03 AM UTC-7, da...@axiom-developer.org wrote:
>
> Forgy's RETE is a self-modifying data structure. 
> How is this handled in Clojure? 
>

The clara-rules approach treats (no pun intended) the working memory as a 
value, from the readme.md:

"Embrace immutability. The rule engine's working memory is a persistent 
Clojure data structure that can participate in transactions. All changes 
produce a new working memory that shares state with the previous."

Alan

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

[Alan Moore]

Nice... good to see another implementation.

Have you seen clara-rules by Ryan Brush? It is actually a 
modified/optimized RETE but faithful to the basic design. 

See:

https://github.com/rbrush/clara-rules

Alan


On Monday, May 12, 2014 6:47:44 AM UTC-7, ru wrote:
>
> New feature: added Java interface. Eclipse project example.
>
> Home: https://github.com/rururu/rete4frames
>
> Have fun!
>
> Sincerely,
>   Ru
>

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

['Mikera' via Clojure]

On Monday, 12 May 2014 00:33:25 UTC+1, Alex Miller wrote:
>
> On Sun, May 11, 2014 at 2:06 PM, Mikera 
> > wrote:
>
>> OK. this thread is a bit worrying. If I understand correctly, it 
>> means that we've now got inconsistent hash and equals functions. I suspect 
>> this hasn't bitten many people yet simply because it is unusual to mix Java 
>> and Clojure collections as keys in the same structure, but it seems like a 
>> really nasty issue.
>>
>
> Reports of real problems in real codebases would change my own opinion of 
> the severity of this issue. 
>

Are you suggesting correctness issues in APIs aren't severe? This is broken 
according to the documentation. From the docstrings:

clojure.core/= "Same as
  Java x.equals(y) except it also works for nil, and compares
  numbers and collections in a type-independent manner."

clojure.core/hash "Returns the hash code of its argument. Note this is the 
hash code
  consistent with =, and thus is different than .hashCode for Integer,
  Short, Byte and Clojure collections."

This promises consistency, and also promises behaviour that works like 
x.equals(y) and x.hashCode() - except for a a few defined exceptions. Which 
means I should expect them to work on arbitrary Java objects.

As a result, all sorts of code that depends on hashes directly or 
indirectly now has subtle bugs. clojure.core/merge is now broken for 
example:

(let [a {[1 2] :a}
  b {(java.util.ArrayList. [1 2]) :a}
  m (zipmap (range 20) (range 20))]
  [(= a b)   (= (merge m a) (merge m b))])
=> [true false]

I hope everyone agrees that this isn't the kind of behaviour we want in 
core functions?

 
>
>> Hash and equality functions generally have a very simple rule: if two 
>> things are equal they must have the same hashcode. But now we've got:
>>
>> (= (java.util.ArrayList. [1 2]) [1 2])
>> => true
>>
>> (hash (java.util.ArrayList. [1 2]))
>> => 994
>>
>> (hash [1 2])
>> => 156247261
>>
>> I consider this a major defect. If we want to define our own equals and 
>> hashcode that's fine, but then these functions absolutely should be 
>> consistent with each other.
>>
>> If it is really true that non-Clojure collections aren't considered as 
>> values and aren't expected to participate in hash/= comparisons then I'd 
>> expect an exception, not an erroneous value. Silent potential corruption of 
>> data is *much* worse than a noisy failure. But I think even that is a bad 
>> direction to go: easy Java ecosystem interop is definitely one of the main 
>> reasons why I'm using Clojure, and I'd like to see this maintained.
>>
>
> Please be more specific about where an exception could be thrown (equals 
> vs hash vs collection usage). 
>
> I can think of only two sensible ways to fix this inconsistency:
>> a) Roll back the hash changes. Correctness is much more important than a 
>> performance edge case.
>>
>
> We're not doing that.
>  
>
>> (I suspect the hash changes have hurt average case performance anyway...)
>>
>
> We have made hash calculation slightly slower to generate better hashes 
> across the board. Timing info is at 
> http://dev.clojure.org/display/design/Better+hashing but in general, the 
> time increases per hash are on the order of nanoseconds for simple values 
> and sub-millisecond for more complicated strings and collections (where 
> hashes are cached and times are likely to be dwarfed by other things). The 
> better hashes avoid catastrophically bad (and relatively easy to find) 
> cases.  
>

> It is quite challenging to predict the performance impact of the hashing 
> changes in Strings, keywords, and symbols due to the effects of usage 
> patterns, interning, caching, etc. I am aware of several people that have 
> reported better performance overall in 1.6 and I don't think I've heard any 
> reports of significantly slower performance in 1.6. I'm calling FUD on this 
> unless you have data to report.
>

It's absolutely not FUD. I'm generally a pretty big Clojure evangelist 
and my aim here is simply to be very clear about issues so that we can 
improve Clojure. I hope all my comments are taken in that spirit.

The page you have linked shows that the hashing changes have slowed down 
various workloads (including the full Clojure compile). The Clojure 
micro-benchmarks posted recently also show various slowdowns related to 
hashing. 

For good measure (and because I care about small vector performance for 
numerical work / core.matrix stuff) here's my own criterium benchmark:

;; Clojure 1.6.0
(c/quick-bench 
 (dotimes [i 1000] (hash [i i])))
WARNING: Final GC required 9.3578822831726 % of runtime
WARNING: Final GC required 119.680511859946 % of runtime
Evaluation count : 1950 in 6 samples of 325 calls.
 Execution time mean : 339.879773 µs
Execution time std-deviation : 98.446114 µs
   Execution time lower quantile : 240.545585 µs ( 2.5%)
   Execution time upper quantile : 453.154577 µs (97.5%)
   Overhead used : 4.007792 ns

"recursive" hierarchies and derive

[r]

Why is something like 

(derive [::matrix ::ring-element] ::ring-element)

prevented by the assertion in clojure.core/derive?
Is there something that is an actual show-stopper 
or is this an implementation detail?

Cheers,
ranko


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

[ANN] brute 0.2.0 - A lightweight Entity Component System library for writing games

[Mark Mandel]

Brute is a simple and lightweight Entity Component System library for
writing games with Clojure.

This is a rewrite of Brute 0.1.1, to get rid of all the global internal
refs, and make it so that Brute simply passes around an immutable
collection.  This makes things far nicer to deal with, and makes the
library far more flexible.

Full Blog Post on changes:
http://www.compoundtheory.com/brute-entity-component-system-library-0-2-0-the-sequel/

The aim of this project was to use basic Clojure building blocks to form an
Entity System architecture, and get out of the author's way when deciding
exactly what approach would best fit their game when integrating with this
library.

To that end:


   - Entities are UUIDs.
   - The Component type system can be easily extended through a multimethod
   get-component-type, but defaults to using the component's instance class as
   its type.
   - Components can therefore be defrecords or deftypes by default, but
   could easily be maps or just about anything else.
   - Systems are simply references to functions of the format (fn [delta]).

Project can be found on Github at:
https://github.com/markmandel/brute

Sample Pong Game can be found on Github as well:
https://github.com/markmandel/brute-play-pong


-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

Re: *data-readers* with clojure.tools.reader -- No reader function for tag id

[Sarkis Karayan]

Doesn't seem to work:

(ns literal-test
  (:require [datomic.api :as d]
[clojure.tools.reader :as r]
[clojure.tools.reader.reader-types :as readers]))

(defn read-all [source-code]
  (let [reader (readers/source-logging-push-back-reader source-code)
eof(Object.)]
(binding [r/*data-readers* *data-readers*]
  (take-while #(not= % eof)
(repeatedly #(r/read reader false eof))

(read-all "#db/id [db.part/user -100]")



*ExceptionInfo No reader function for tag id  clojure.core/ex-info 
(core.clj:4327)*

Any ideas?

Thanks,
Sarkis



On Monday, May 12, 2014 6:27:13 PM UTC-4, Nicola Mometto wrote:
>
> (binding [clojure.tools.reader/*data-readers* *data-readers*] 
>   (clojure.tools.reader/read ..))
> is probably what you want.
>
>
> On Tue, May 13, 2014 at 12:17 AM, Sarkis Karayan 
> 
> > wrote:
>
>> Hi everyone,
>>
>> I am trying to use clojure.tools.reader to read from a file and also 
>> process datomic #db/id literals, but I am not sure how to pass in the 
>> *data-readers*?
>>
>> clojure.tools.reader.edn allows something like this:
>> (edn/read reader false eof { :readers *data-readers* } )
>>
>> Is there something equivalent with clojure.tools.reader?
>>
>> Thanks,
>> Sarkis
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Leiningen/javax.imageio

[Lars Nilsson]

On Mon, May 12, 2014 at 6:28 PM, Michael Shaffer  wrote:
> What dependencies do I add to leiningen to get javax.imageio package?

None, as far as I can tell..

(ns imagetest.core
  (:import [javax.imageio ImageIO])
  (:gen-class))

(defn foo []
  (let [x (ImageIO/getReaderMIMETypes)]
x))

(defn -main []
  (println (seq (foo

$ lein run
(image/jpeg image/png image/x-png image/vnd.wap.wbmp image/gif image/bmp)

Worked without problem.

Lars Nilsson

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

Leiningen/javax.imageio

[Michael Shaffer]

What dependencies do I add to leiningen to get javax.imageio package?

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

Re: *data-readers* with clojure.tools.reader -- No reader function for tag id

[Bronsa]

(binding [clojure.tools.reader/*data-readers* *data-readers*]
  (clojure.tools.reader/read ..))
is probably what you want.


On Tue, May 13, 2014 at 12:17 AM, Sarkis Karayan  wrote:

> Hi everyone,
>
> I am trying to use clojure.tools.reader to read from a file and also
> process datomic #db/id literals, but I am not sure how to pass in the
> *data-readers*?
>
> clojure.tools.reader.edn allows something like this:
> (edn/read reader false eof { :readers *data-readers* } )
>
> Is there something equivalent with clojure.tools.reader?
>
> Thanks,
> Sarkis
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

*data-readers* with clojure.tools.reader -- No reader function for tag id

[Sarkis Karayan]

Hi everyone,

I am trying to use clojure.tools.reader to read from a file and also 
process datomic #db/id literals, but I am not sure how to pass in the 
*data-readers*?

clojure.tools.reader.edn allows something like this:
(edn/read reader false eof { :readers *data-readers* } )

Is there something equivalent with clojure.tools.reader?

Thanks,
Sarkis


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

[Alex Miller]

On Mon, May 12, 2014 at 4:26 PM, John D. Hume wrote:

> On Mon, May 12, 2014 at 12:53 PM, Alex Miller  wrote:
>
>> My recommendation in Java would be the same - using mutable objects as
>> keys in a map (where mutability changes the hashcode) is a bug waiting to
>> happen.
>>
>
> Although I used java.util.ArrayList in the sample REPL session showing the
> surprising behavior, I never said anything about the Java types used in our
> application being mutable. That gets at my point: the "best" Java
> collection values, the only ones that make good hashmap keys, are
> immutable, but Clojure still gives them this mixed status where they're
> equiv but not hasheq to IPersistentCollections w/ the same contents.
>
> [Having made that point again, I'll now admit that under the cover of
> java.util.List, the lists in messages our app receives are ArrayLists
> :-), BUT they're never mutated, and we'd have the same issue if they were
> Guava ImmutableList, which is a fine value type (so long as V is
> immutable).]
>

If you don't know, then you don't know... But, point taken.


>  In general, Clojure treats Java collections (and arrays) as values now
>> ... but if you do mutation, then any Clojure guarantees are off (in
>> hashing, in STM, etc). I think that's been generally a happy compromise so
>> far. The question is to what extent that should continue.
>>
>
> I'm totally happy to see crazy things happen to anyone who treats a
> mutable collection as a value and then mutates it.
>
> It may even be that this could be supported without much of a hit.
>> Strings, numbers, keywords, symbols, and all Clojure collections should be
>> handled above the suggested change and that covers most common key types.
>> Some research would need to be done on what common non-Clojure classes
>> (hence not IHashEq implementors) fall into the final else case -
>> java.lang.Class is one that comes to mind which is used a lot inside
>> Clojure itself.
>>
>
> I like the sound of this. One of your comments on the ticket mentioned JVM
> inlining issues, which scared me.
>

Yes, me too. :)  Needs investigation, which is why we did not try to jam it
into 1.6.

Is it a safe bet that protocol dispatch would be too slow for hasheq?
>

No clue - needs more investigation.

>  --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Expected inconsistency between set and map w/ ArrayList?

[John D. Hume]

On Mon, May 12, 2014 at 12:53 PM, Alex Miller  wrote:

> My recommendation in Java would be the same - using mutable objects as
> keys in a map (where mutability changes the hashcode) is a bug waiting to
> happen.
>

Although I used java.util.ArrayList in the sample REPL session showing the
surprising behavior, I never said anything about the Java types used in our
application being mutable. That gets at my point: the "best" Java
collection values, the only ones that make good hashmap keys, are
immutable, but Clojure still gives them this mixed status where they're
equiv but not hasheq to IPersistentCollections w/ the same contents.

[Having made that point again, I'll now admit that under the cover of
java.util.List, the lists in messages our app receives are ArrayLists
:-), BUT they're never mutated, and we'd have the same issue if they were
Guava ImmutableList, which is a fine value type (so long as V is
immutable).]

In general, Clojure treats Java collections (and arrays) as values now ...
> but if you do mutation, then any Clojure guarantees are off (in hashing, in
> STM, etc). I think that's been generally a happy compromise so far. The
> question is to what extent that should continue.
>

I'm totally happy to see crazy things happen to anyone who treats a mutable
collection as a value and then mutates it.

It may even be that this could be supported without much of a hit. Strings,
> numbers, keywords, symbols, and all Clojure collections should be handled
> above the suggested change and that covers most common key types. Some
> research would need to be done on what common non-Clojure classes (hence
> not IHashEq implementors) fall into the final else case - java.lang.Class
> is one that comes to mind which is used a lot inside Clojure itself.
>

I like the sound of this. One of your comments on the ticket mentioned JVM
inlining issues, which scared me.

Is it a safe bet that protocol dispatch would be too slow for hasheq?

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

[ru]

This implementation does not strictly support principles of functional 
programming, immutability and so on. Clojure used mostly for simplicity of 
programming, specifically in right hand sides of the rules and helper 
functions. Moreover, it is extensively uses Java HashMaps directly for 
better performance.

понедельник, 12 мая 2014 г., 17:47:44 UTC+4 пользователь ru написал:
>
> New feature: added Java interface. Eclipse project example.
>
> Home: https://github.com/rururu/rete4frames
>
> Have fun!
>
> Sincerely,
>   Ru
>

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

[Alex Miller]

On Mon, May 12, 2014 at 12:15 PM, John Hume wrote:

> On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote:
>
>> On Sun, May 11, 2014 at 2:06 PM, Mikera  wrote:
>>
>>> OK. this thread is a bit worrying. If I understand correctly, it
>>> means that we've now got inconsistent hash and equals functions. I suspect
>>> this hasn't bitten many people yet simply because it is unusual to mix Java
>>> and Clojure collections as keys in the same structure, but it seems like a
>>> really nasty issue.
>>>
>>
>> Reports of real problems in real codebases would change my own opinion of
>> the severity of this issue.
>>
>
> Here's the real problem I feared when thinking about what was new in
> Clojure 1.6, which led to the testing that led to this thread:
> One of our Clojure applications has two kinds of clients. (1) Legacy Java
> clients use a legacy remoting lib w/ generated,
> shared-across-client-and-server Java value types as messages. Where those
> have a collection, that's exposed as a java.util.List.
> (2) Newer (Clojure) clients use a lighter-weight message format that's
> easily read into Clojure data structures. Clients interested in the same
> data need to be aggregated, and the commonality is contained in one
> java.util.List from a message the legacy clients send.
> The old code used those as map keys.
>

I think the general recommendation would be to not do that. :)  My
recommendation in Java would be the same - using mutable objects as keys in
a map (where mutability changes the hashcode) is a bug waiting to happen.


> The new code for Clojure clients currently builds a vector of
> AnotherValueType and throws that into the same map, where, under Clojure
> 1.5.1, vectors and non-Clojure Lists can play nicely together. Under
> Clojure 1.6, they won't play nicely any more.
>
> This is an easy problem to work around by making the keys from the two
> client types more similar, either vectors on both sides or non-Clojure
> java.util.Lists on both sides.
>

IMO vectors are the only choice that makes sense here.


> Luckily the change on our side is recent, and Clojure 1.6 is brand new, so
> this jumped out at me as something to test well before embarking on an
> upgrade, and this is a (probably) subtle bug we've avoided.
>

Depending on your point of view, you could also say that the use of a
mutable Java collection as a key is the bug you had already incurred and
it's just now biting you. :)

I really am sympathetic to what you're describing, but just trying to
highlight how the mutability of Java collections really is a problem when
used for hashing (and this is true regardless of language). Immutability is
what allows us to cache the hash code of a collection (something that
cannot be done in Java or Scala due to the mutability of objects, even in
immutable collections).


> What primarily worries me about the new behavior is that Clojure has
> always embraced the host platform, but the notion of "value" that seems to
> be reified in 1.6 excludes the closest things the Java platform has to
> collection values.
>

I really don't think anything has changed philosophically in 1.6. There is
a tension between interop support for mutable objects and the immutability
at the core of Clojure. We've come to a point where performance concerns
are driving us a bit further in one direction.


> While I agree a java.util.ArrayList is a bad value, mutability is not part
> of the java.util.List contract – it's optional – and even the best
> (immutable) Java collection value type one can write wouldn't be treated as
> a value by Clojure 1.6 unless it also implemented some clojure.lang
> interface(s) (which no sane Java lib would do). In the spirit of embracing
> the host platform, I'd like to see support for Java collections as values
> (and let those who mutate their value-treated Java collections deal with
> the nasty consequences).
>

In general, Clojure treats Java collections (and arrays) as values now ...
but if you do mutation, then any Clojure guarantees are off (in hashing, in
STM, etc). I think that's been generally a happy compromise so far. The
question is to what extent that should continue.


> From the comments on the ticket (
> http://dev.clojure.org/jira/browse/CLJ-1372), particularly Alex Miller's
> two longer comments from March 10th, I have the impression that there's no
> principled objection to this, just the performance concern with supporting
> so many types in hasheq. Does that seem right, Alex?
>

That's my feeling (not speaking for Rich) - I'd prefer to say without
exception that equiv=true => hash=same. As I said above, I think treating
Java collections as "look the other way" values has been mostly a happy
compromise.

It may even be that this could be supported without much of a hit. Strings,
numbers, keywords, symbols, and all Clojure collections should be handled
above the suggested change and that covers most common key types. Some
research would need to be done on what common non

Re: Java API is copyright protected?

[u1204]

>Judge Alsup did not conflate patent and copyright law. With regards to 
> asserting copyright in the Java API he concludes: ...[snip]...

Good point. I was wrong. 

The higher court ruled that Oracle DID have a copyright claim.

I'm not a lawyer but I've read 3 books on intellectual property law.
I've also spent many hours in discussions on copyright, patent, and
trademark issues.  I admit that most court decisions still baffle me.

Tim Daly

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

[u1204]

Forgy's RETE is a self-modifying data structure.
How is this handled in Clojure?

Tim Daly

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

[John Hume]

On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote:
>
> On Sun, May 11, 2014 at 2:06 PM, Mikera 
> > wrote:
>
>> OK. this thread is a bit worrying. If I understand correctly, it 
>> means that we've now got inconsistent hash and equals functions. I suspect 
>> this hasn't bitten many people yet simply because it is unusual to mix Java 
>> and Clojure collections as keys in the same structure, but it seems like a 
>> really nasty issue.
>>
>
> Reports of real problems in real codebases would change my own opinion of 
> the severity of this issue. 
>

Here's the real problem I feared when thinking about what was new in 
Clojure 1.6, which led to the testing that led to this thread:
One of our Clojure applications has two kinds of clients. (1) Legacy Java 
clients use a legacy remoting lib w/ generated, 
shared-across-client-and-server Java value types as messages. Where those 
have a collection, that's exposed as a java.util.List. 
(2) Newer (Clojure) clients use a lighter-weight message format that's 
easily read into Clojure data structures. Clients interested in the same 
data need to be aggregated, and the commonality is contained in one 
java.util.List from a message the legacy clients send. 
The old code used those as map keys. The new code for Clojure clients 
currently builds a vector of AnotherValueType and throws that into the same 
map, where, under Clojure 1.5.1, vectors and non-Clojure Lists can play 
nicely together. Under Clojure 1.6, they won't play nicely any more.

This is an easy problem to work around by making the keys from the two 
client types more similar, either vectors on both sides or non-Clojure 
java.util.Lists on both sides. Luckily the change on our side is recent, 
and Clojure 1.6 is brand new, so this jumped out at me as something to test 
well before embarking on an upgrade, and this is a (probably) subtle bug 
we've avoided.

What primarily worries me about the new behavior is that Clojure has always 
embraced the host platform, but the notion of "value" that seems to be 
reified in 1.6 excludes the closest things the Java platform has to 
collection values. While I agree a java.util.ArrayList is a bad value, 
mutability is not part of the java.util.List contract – it's optional – and 
even the best (immutable) Java collection value type one can write wouldn't 
be treated as a value by Clojure 1.6 unless it also implemented some 
clojure.lang interface(s) (which no sane Java lib would do). In the spirit 
of embracing the host platform, I'd like to see support for Java 
collections as values (and let those who mutate their value-treated Java 
collections deal with the nasty consequences).

>From the comments on the ticket 
(http://dev.clojure.org/jira/browse/CLJ-1372), particularly Alex Miller's 
two longer comments from March 10th, I have the impression that there's no 
principled objection to this, just the performance concern with supporting 
so many types in hasheq. Does that seem right, Alex? I'd feel much better 
about an open issue and agreement that Clojure is in search of a 
high-performance implementation treating Java collections as values than 
about clear documentation of when and why hasheq is and will remain 
inconsistent w/ = and all the quirks that follow from that. (Though since 
we're living w/ the inconsistency, that documentation is important.)

Thanks.
-hume.

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

[C K Kashyap]

Sounds promising ... I'll give it a shot. Thanks Daniel.
Regards,
Kashyap


On Mon, May 12, 2014 at 4:41 PM, Daniel Barlow  wrote:

> On 12 May 2014 10:40, C K Kashyap  wrote:
> > I finally got my robotic vehicle working using raspberry pi. I was
> hoping to
> > make it do tricks using the clojure repl - however, I found that repl
> took
> > well over 2 minutes to start. Is that normal or are folks seeing better
> > performance?
>
> I haven't tried it on a Pi, but it's consistent with what I see when I
> start a lein repl on my android phone (inside a debian chroot using a
> regular linux jvm).  One problem you may be seeing is that leiningen
> starts a jvm and your app starts a jvm, and in a RAM-limited
> environment that means a lot of paging.
>
> What I did is
> 1) created a namespace myapp.nrepl which calls
> (clojure.tools.nrepl.server/start-server :port 9990)
>
> 2) invoke the app with
>
>   $ lein trampoline run -m myapp.nrepl
>
> 3) connect to it from some other machine
>
>   $ lein repl :connect myphone.local:9990
>
> This means there's only one JVM running at a time on the phone (or in
> your case, pi) and reduces the startup time on my phone from something
> arounf 2 minutes to something around 40 seconds.  Which is still Too
> Long but not quite as Much Too Long
>
> Playing with clojure-metal and clojure-c are both on my "TO DO,
> EVENTUALLY" list but I have more than enough to keep me occupied for
> the time being already, so not any time soon
>
> [ With Actual Code!
> https://github.com/telent/defone/blob/master/defone/start.sh
> https://github.com/telent/defone/blob/master/defone/src/defone/nrepl.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.
>

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

Re: using atoms as logs for channels in core.async

[gamma235]

Ok the destructuring is clear to me now. And yes Jay Field article was great :)

So the only thing that remains now is to get the symbol being passed into my 
original transparent-put function to stop evaluating to either ch-log or 
clojure.core.async.impl.channels.ManyToManyChannel@5096B86b-log

I'm using your macro David but it still won't put with an update to the atom.


Jesse

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

[Daniel Barlow]

On 12 May 2014 10:40, C K Kashyap  wrote:
> I finally got my robotic vehicle working using raspberry pi. I was hoping to
> make it do tricks using the clojure repl - however, I found that repl took
> well over 2 minutes to start. Is that normal or are folks seeing better
> performance?

I haven't tried it on a Pi, but it's consistent with what I see when I
start a lein repl on my android phone (inside a debian chroot using a
regular linux jvm).  One problem you may be seeing is that leiningen
starts a jvm and your app starts a jvm, and in a RAM-limited
environment that means a lot of paging.

What I did is
1) created a namespace myapp.nrepl which calls
(clojure.tools.nrepl.server/start-server :port 9990)

2) invoke the app with

  $ lein trampoline run -m myapp.nrepl

3) connect to it from some other machine

  $ lein repl :connect myphone.local:9990

This means there's only one JVM running at a time on the phone (or in
your case, pi) and reduces the startup time on my phone from something
arounf 2 minutes to something around 40 seconds.  Which is still Too
Long but not quite as Much Too Long

Playing with clojure-metal and clojure-c are both on my "TO DO,
EVENTUALLY" list but I have more than enough to keep me occupied for
the time being already, so not any time soon

[ With Actual Code!
https://github.com/telent/defone/blob/master/defone/start.sh
https://github.com/telent/defone/blob/master/defone/src/defone/nrepl.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: using atoms as logs for channels in core.async

[James Reeves]

On 12 May 2014 10:48, gamma235  wrote:

> When I try this using your code above I get a stack-trace that I can't
> understand. Am I using it wrong?
>
> (transparent-chan c)
>> (transparent-put c 42)
>> (transparent-take c)
>>
>
Yep, try this instead:

  (def tc (transparent-chan c))
  (transparent-put tc 42)
  (transparent-take tc)

I'm creating a new data structure that contains both a channel and an atom,
and I'm returning it from transparent-ch. I'm not modifying the original
channel in any fashion.

The destructuring is just a shortcut. This code:

  (defn transparent-put [{:keys [channel buffer]} x]
(go
  (>! channel x)
  (swap! buffer conj x)))

Is equivalent to:

  (defn transparent-put [tc x]
(let [{:keys [channel buffer]} tc]
  (go
(>! channel x)
(swap! buffer conj x)))

Which is equivalent to:

  (defn transparent-put [tc x]
(let [channel (:channel tc)
  buffer (:buffer tc)]
  (go
(>! channel x)
(swap! buffer conj x)))

- James

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

Re: using atoms as logs for channels in core.async

[Dave Della Costa]

Sorry, I just realized that you were referring to the exact same
examples Jay Fields uses...so you must already know about that article! ;-)

(2014/05/12 23:07), Dave Della Costa wrote:
>> The x is referring to the map that is to be
>> added in as a parameter, right?
> 
> So, taking one example from James's code:
> 
> (defn transparent-put [{:keys [channel buffer]} x]
>   (go
> (>! channel x)
> (swap! buffer conj x)))
> 
> The x is the second argument to the function--it's the message you put
> into the channel, in this case.
> 
> The contrast with the let form you used as an example is that the let
> form is assigning the right value to the left destructuring form.  But
> in the case of a function, the value that is passed in is what is
> getting destructured.  Contrast this:
> 
> (let [{:keys [a b]} {:a 1 :b 2}]
>   (println "a: " a ", b: " b))
> 
> with this:
> 
> (defn destruct
>   [{:keys [a b]}]
>   (println "a: " a ", b: " b))
> 
> (destruct {:a 1 :b 2})
> 
> Does that help?
> 
> If you haven't read this great article about destructuring by Jay Fields
> yet, I highly recommend you do:
> 
> http://blog.jayfields.com/2010/07/clojure-destructuring.html
> 
>> Like you said, I also feel like I'm *starting* to get it and it is
>> really exciting :) Thanks for your advice.
> 
> Great! You're very welcome--good luck.
> 
> DD
> 
> (2014/05/12 21:43), gamma235 wrote:
>> Your description of what is going on with my macro was really helpful.
>> In my head I was imagining recursive evals running over the code, saying
>> first, then, etc. I didn't really think about  compile time vs. run-time. 
>>
>> I am impressed with James' code as well, but I am having trouble fully
>> understanding it and getting it to run. From the transparent put
>> definition, it doesn't seem like it is possible to pass a channel value
>> as a parameter in the call. The x is referring to the map that is to be
>> added in as a parameter, right? at least that is why I learned, when I
>> studied destructuring: 
>>
>> (def point {:x 5 :y 7})
>>
>>  
>>
>> (let [{:keys [x y]} point]
>>   (println "x:" x "y:" y))
>>
>>  
>>
>> => :x 5 :y 7
>>
>>
>> Does it work different different for defining function parameters? I
>> posted more under his comment above, please have a look. 
>>
>> Like you said, I also feel like I'm *starting* to get it and it is
>> really exciting :) Thanks for your advice. 
>>
>> Jesse
>>
>> On Monday, May 12, 2014 7:46:34 PM UTC+9, David Della Costa wrote:
>>
>> > to reason about and can be dangerous. I would suggest putting
>> > dynamically created channels in a collection inside an atom if you
>> > need to create them like this.
>>
>> P.S. I just read James's response and I see he said something similar
>> regarding this--it's better to structure this as a hash-map or other
>> data structure, and use an atom if it needs to be updated dynamically.
>> Notice that his code is far simpler and easier to reason about, and
>> avoids the use of macros.
>>
>> DD
>>
>> (2014/05/12 19:40), Dave Della Costa wrote:
>> >> I think I am confused about how to distinguish between a symbol
>> and a
>> >> variable, as I thought that the symbol being derefed pointed to the
>> >> atom that it was made to define when transparent-chan was called.
>> >
>> > I think it's not so much that, as being mistaken about what is
>> going at
>> > compile-time vs. run-time in your macros.  Going back to your
>> original
>> > code, your log-name function is just fine:
>> >
>> > (defn log-name [ch] (symbol (str ch '-log)))
>> >
>> > It returns a symbol, which is what you want for the second arg to
>> def.
>> >
>> > However, keep in mind that this is going to return a list which will
>> > then get evaluated, but it will only be the last value returned
>> from 'do':
>> >
>> > (defmacro transparent-chan [ch]
>> >   (do
>> > `(def ~ch (chan))
>> > `(def (log-name ~ch) (atom []))
>> > `(println "new transparent channel created!")))
>> >
>> > that is, a list like this:
>> >
>> > `(println "new transparent channel created!")
>> >
>> > ...which will then get evaluated at run-time.  So your def calls will
>> > never run!  If we know that we can adjust it--
>> >
>> > (defmacro transparent-chan [ch]
>> >   `(do (def ~ch (async/chan))
>> >(def (log-name ~ch) (atom []))
>> >(println "new transparent channel created!")))
>> >
>> > ...but then we get:
>> >
>> > user=> (transparent-chan my-chan)
>> >
>> > CompilerException java.lang.RuntimeException: First argument to
>> def must
>> > be a Symbol, compiling... ; etc.
>> > user=>
>> >
>> > Hmm...still a problem.  Let's see, when is the 'log-name' function
>> > getting run?  Oh, at *run-time*...but we want it run at compile-time.
>> > So, kn

Re: using atoms as logs for channels in core.async

[Dave Della Costa]

> The x is referring to the map that is to be
> added in as a parameter, right?

So, taking one example from James's code:

(defn transparent-put [{:keys [channel buffer]} x]
  (go
(>! channel x)
(swap! buffer conj x)))

The x is the second argument to the function--it's the message you put
into the channel, in this case.

The contrast with the let form you used as an example is that the let
form is assigning the right value to the left destructuring form.  But
in the case of a function, the value that is passed in is what is
getting destructured.  Contrast this:

(let [{:keys [a b]} {:a 1 :b 2}]
  (println "a: " a ", b: " b))

with this:

(defn destruct
  [{:keys [a b]}]
  (println "a: " a ", b: " b))

(destruct {:a 1 :b 2})

Does that help?

If you haven't read this great article about destructuring by Jay Fields
yet, I highly recommend you do:

http://blog.jayfields.com/2010/07/clojure-destructuring.html

> Like you said, I also feel like I'm *starting* to get it and it is
> really exciting :) Thanks for your advice.

Great! You're very welcome--good luck.

DD

(2014/05/12 21:43), gamma235 wrote:
> Your description of what is going on with my macro was really helpful.
> In my head I was imagining recursive evals running over the code, saying
> first, then, etc. I didn't really think about  compile time vs. run-time. 
> 
> I am impressed with James' code as well, but I am having trouble fully
> understanding it and getting it to run. From the transparent put
> definition, it doesn't seem like it is possible to pass a channel value
> as a parameter in the call. The x is referring to the map that is to be
> added in as a parameter, right? at least that is why I learned, when I
> studied destructuring: 
> 
> (def point {:x 5 :y 7})
> 
>  
> 
> (let [{:keys [x y]} point]
>   (println "x:" x "y:" y))
> 
>  
> 
> => :x 5 :y 7
> 
> 
> Does it work different different for defining function parameters? I
> posted more under his comment above, please have a look. 
> 
> Like you said, I also feel like I'm *starting* to get it and it is
> really exciting :) Thanks for your advice. 
> 
> Jesse
> 
> On Monday, May 12, 2014 7:46:34 PM UTC+9, David Della Costa wrote:
> 
> > to reason about and can be dangerous. I would suggest putting
> > dynamically created channels in a collection inside an atom if you
> > need to create them like this.
> 
> P.S. I just read James's response and I see he said something similar
> regarding this--it's better to structure this as a hash-map or other
> data structure, and use an atom if it needs to be updated dynamically.
> Notice that his code is far simpler and easier to reason about, and
> avoids the use of macros.
> 
> DD
> 
> (2014/05/12 19:40), Dave Della Costa wrote:
> >> I think I am confused about how to distinguish between a symbol
> and a
> >> variable, as I thought that the symbol being derefed pointed to the
> >> atom that it was made to define when transparent-chan was called.
> >
> > I think it's not so much that, as being mistaken about what is
> going at
> > compile-time vs. run-time in your macros.  Going back to your
> original
> > code, your log-name function is just fine:
> >
> > (defn log-name [ch] (symbol (str ch '-log)))
> >
> > It returns a symbol, which is what you want for the second arg to
> def.
> >
> > However, keep in mind that this is going to return a list which will
> > then get evaluated, but it will only be the last value returned
> from 'do':
> >
> > (defmacro transparent-chan [ch]
> >   (do
> > `(def ~ch (chan))
> > `(def (log-name ~ch) (atom []))
> > `(println "new transparent channel created!")))
> >
> > that is, a list like this:
> >
> > `(println "new transparent channel created!")
> >
> > ...which will then get evaluated at run-time.  So your def calls will
> > never run!  If we know that we can adjust it--
> >
> > (defmacro transparent-chan [ch]
> >   `(do (def ~ch (async/chan))
> >(def (log-name ~ch) (atom []))
> >(println "new transparent channel created!")))
> >
> > ...but then we get:
> >
> > user=> (transparent-chan my-chan)
> >
> > CompilerException java.lang.RuntimeException: First argument to
> def must
> > be a Symbol, compiling... ; etc.
> > user=>
> >
> > Hmm...still a problem.  Let's see, when is the 'log-name' function
> > getting run?  Oh, at *run-time*...but we want it run at compile-time.
> > So, knowing that, we can adjust it again:
> >
> > (defmacro transparent-chan [ch]
> >   `(do (def ~ch (async/chan))
> >(def ~(log-name ch) (atom []))
> >(println "new transparent channel created!")))
> >
> > Now we see:
> >
> > user=> (transparent-chan my-chan)
> > new transparent channel created!
> 

[ANN] Clojure RETE implementation - CLIPS-like expert system shell. New version 4.3

[ru]

New feature: added Java interface. Eclipse project example.

Home: https://github.com/rururu/rete4frames

Have fun!

Sincerely,
  Ru

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

[Phillip Lord]

I'd always assumed that was the case anyway; the fact that Google was
prepared to risk that this was not the case was never a good guide for
the little people anyway. Google can afford to get sued by Oracle.

Oracle have, however, given you permission to use the Java API and
release it under (several different) licenses. The problem with Google
was that they were in breach of the terms of these licenses and were
claiming that they just didn't need one since the API was not
copyrightable anyway.

Phil

 writes:

> It appears that the Java API can be copyright protected.
> This would mean that you have to get Oracle's permission
> and possibly pay a fee to use it. 
>
> http://www.theverge.com/2014/5/9/5699958/federal-court-overturns-google-v-oracle
>
> Tim Daly

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

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

[C K Kashyap]

Thanks David,

hmmm  perhaps I'll try and see if it is usable after the repl comes up.

clojurescript route would involve writing/compiling the code on a regular
machine right?

Regards,
Kashyap


On Mon, May 12, 2014 at 6:47 PM, David Powell  wrote:

> Yeah I had similar issues.  I guess the standard JDK is a bit a
> heavyweight for the raspberry pi.
>
> I wonder if clojurescript on nodejs might be an easier route?
>
>
> On Mon, May 12, 2014 at 10:40 AM, C K Kashyap  wrote:
>
>> Hi,
>>
>> I finally got my robotic vehicle working using raspberry pi. I was hoping
>> to make it do tricks using the clojure repl - however, I found that repl
>> took well over 2 minutes to start. Is that normal or are folks seeing
>> better performance?
>>
>> Regards,
>> Kashyap
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Licensing program written in Clojure under GPL

[Phillip Lord]

This is, I think, incorrect. The GPL includes a standard "linking
exception". Look for this part

A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.


If what you say is correct, for example, it would be impossible to
produce GPL code which would run on Windows or Mac since in all of these
cases the OS itself is non-GPL (nor even free). But it is possible to do
this -- you can run linux, for example, in windows user space with no
legal issues, or Emacs, or cygwin. Or, indeed, write a GPL program in
Java.

In the case of Clojure, you can link a GPL library to Clojure itself.
So, in this case, library G really is relevant. If G is GPLv3 and B uses
it, then B must also be GPLv3 because of this. So, the issue is, what
"other Clojure libraries" is A dependent on. If it is dependant on the
"standard interface" there is not a problem. If not, then I don't think
the program can be legally distributed.

Phil



Jozef Wagner  writes:

> Do you want to distribute binaries (.class files) of the program B? If not,
> you may license your sources in any license you want. If yes, then it will
> be possible only if the library G has a linking exception in its license
> [1], as the clojure itself is EPL so it does not matter how the library A
> is licensed. Without linking exception  you cannot distribute the combined
> work from EPL and GPL sources [2] [3].
>
> [1] http://en.wikipedia.org/wiki/GPL_linking_exception
> [2] https://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE
> [3] http://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/
>
> Jozef
>
>
> On Sat, May 10, 2014 at 5:44 PM, Gunnar Völkel <
> gunnar.voel...@googlemail.com> wrote:
>
>> I have written a Clojure library A which is licensed under Eclipse Public
>> License (EPL) as usual which depends on other Clojure libraries with EPL
>> license.
>> In a different program B I use library A and another library G which is
>> licensed under GPLv3.
>>
>> Now, the question arises which license I am allowed to use (or even must
>> use) for program B.
>>
>> As far as I have read it is not possible to license B under EPL because
>> library G is licensed under GPLv3.
>> Leaving the only option to license program B under GPLv3 - does that sound
>> correct to 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.
>>

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

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

[martin_clausen]

Tim,

Judge Alsup did not conflate patent and copyright law. With regards to 
asserting copyright in the Java API he concludes:

"To repeat, Section 102(b) states that “in no case does copyright 
protection for an original work of authorship extend to any idea, 
procedure, process, system, method of operation . . . regardless of the 
form . . . .” That a system or method of operation has thousands of 
commands arranged in a creative taxonomy does not change its character as a 
method of operation. Yes, it is creative. Yes, it is original. Yes, it 
resembles a taxonomy. But it is nevertheless a command structure, a system 
or method of operation — a long hierarchy of over six thousand commands to 
carry out pre-assigned functions. For that reason, it cannot receive 
copyright protection — patent protection perhaps — but not copyright 
protection."

Martin



On Sunday, May 11, 2014 8:37:36 AM UTC+2, da...@axiom-developer.org wrote:
>
> > At the risk of getting slightly off-topic here, here's a comment on 
> > Hacker News from a well-respected commenter on legal issues - he's a 
> > lawyer specialising in startup and technology law and his analysis is 
> > uniformly excellent. He argues that while the result may be 
> > unpalatable, it's by no means the stitch-up by technological 
> > ignoramuses that that article makes it sound: 
> > https://news.ycombinator.com/item?id=7722674 
>
> Judge Alsop conflated two distinct and non-overlapping areas of 
> intellectual property law by claiming that a copyrightable work 
> (the API) must "rise to the level of warranting patent protection". 
> While that's a novel idea, it is nowhere in the copyright law. 
> (Oracle, by the way, also holds patents on Java). 
>
> Where the new decision might have a direct impact on Clojure would be 
> if someone were to create a stand-alone Clojure (or other products 
> that enable a developer to use Java directly in their products) that 
> was compatible with the JVM-hosted version. There would seem to be a 
> need for API-compatible functions. Doubly so if you could excute jar 
> files. The court could find that "infringing", it seems. 
>
> On April 29th, Steven Vaughan-Nichols (a lawyer) predicted that Oracle 
> would be defeated in court [0]... and he was wrong. Text is "born 
> with copyright" and the API is a text specification. 
>
> The EFF lawyer [1] who provided a friend-of-the-court brief seems very 
> unhappy with the decision. 
>
> Florian Mueller [2] at fosspatents.com has a much more in-depth 
> analysis and basically agrees with the decision. He includes detailed 
> quotes from the Court. 
>
> Google claims that Sun issued Java under the GPL2. But Oracle has the 
> freedom to change a license on its products and has made Java API 
> changes since the Sun Java purchase. They did the same thing with 
> MySQL, also GPL2, which is now "pay-to-play". 
>
> Our trouble with the Courts, and possibly with the lawyer's reasoning, 
> is that they are not programmers. The other problem is that they are 
> deciding the case on what the law SAYS, not on the effects. But the 
> judge ruled that 
>   (a) Oracle could copyright the API 
>   (b) Google infringed that copyright 
>
> Google's defense rests on "fair use" [3] quoted below. I have learned 
> that "legalese" is NOT English so words don't mean what you think they 
> mean. "Legalese" is also not logical but depends on prior cases. With 
> those caveats, I don't see that Google has any chance to prevail. Oracle 
> can certainly claim that the listed exceptions don't apply and that 
> the 4 listed criteria all weigh in on their side. 
>
> As we all know, a widely used API has "network effects"... you use it 
> because everybody uses it. That's essentially why Google chose it 
> rather than create their own. They can leverage the huge number of 
> programmers who already use it. It would be a challenge to convince 
> designers creating an API to create a "competing, non-infringing 
> version". Of course, Oracle claims that their API is very valuable 
> intellectual property, vital to their business, and copyrighted. 
>
> I personally hate the Court's decision but I also think they 
> read the law as it was intended. Oracle is not SCO; they won't 
> go away any time soon. 
>
> So what would a non-JVM Clojure do?  A non-profit JVM-compatible 
> Clojure product would potentially escape using clause (1) below [3], 
> assuming it was used for "non-profit educational purposes". 
>
> Can a non-Java Clojure be defined? 
>
> Tim Daly 
>
> = 
>
> [0] 
> http://www.zdnet.com/blog/open-source/oracle-vs-google-dead-lawsuit-walking/10843
>  
>
> [1] 
> https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-federal-circuit-reverses-sensible-lower-court
>  
>
> [2] 
> http://www.fosspatents.com/2014/05/oracle-wins-android-java-copyright.html 
>
> [3] Copyright Law Exceptions (quoted for "comment" purposes) :-) 

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

[Phillip Lord]

I added some stuff on the Elisp documentation. Others can update if they
think I am wrong!

Phil

Val Waeselynck  writes:
> So it would be nice if people who are knowledgeable about other doc systems 
> could contribute to it. From what I see, that may involve Tim for Emacs, 
> Sean for reStructured, and Daniel for docco, for example?
>
> Thanks in advance!
>
> Le samedi 26 avril 2014 18:39:04 UTC+2, Val Waeselynck a écrit :
>>
>> Hello to all,
>>
>> *Short version :* I think Clojure needs a documentation system in 
>> Clojure, I would like to know if some efforts exist in that direction, and 
>> I am willing to create it / contribute to it.
>>
>> *Long version :*
>>
>> I've been thinking for a while that the Clojure community could benefit a 
>> lot from a more sophisticated and ergonomic documentation system. 
>>
>> I have seen some existing plugins like lein-sphinx, but I think it would 
>> be really good to have documentation that would be written in Clojure, for 
>> the following reasons :
>>
>>- we're all very fond of Clojure data structures and their syntax. (I 
>>don't know about you, but I find that even HTML looks better in
>> Clojurethan in HTML). Plus, Clojure
>> programmers already know how to edit them.
>>- (better reason) The facts that Vars are first-class citizens and 
>>that symbols can be referred explicitly with hardly any ceremony (macros) 
>>are a exceptional opportunity to make smart and highly-structured 
>>documentation very easily.
>>- if it's in Clojure, Clojure programmers can seamlessly build *ad
>> hoc*documentation functionality on top of it to suit their own particular
>> needs.
>>
>> I haven't found anything of the like yet, and if it exists, I would be 
>> grateful if someone would redirect me to it.
>>
>> Here are *my thoughts on this :*
>>
>>1. Clojure doc-strings, although they are quite handy as reminders and 
>>for doc-indexation, are *too raw a content*. Even when they are done 
>>right, they tend to be cumbersome, and it's too bad to have such concise 
>>code drown in the middle of so much documentation. What's more, I believe 
>>that when programmers program a function (or anything), they tend to 
>> think 
>>more about the implementation than the (uninformed) usage, so they have 
>>little incentive to make it right.
>>2. Building on 1. having a system where documentation and programs 
>>live in separate files, in the same way as tests, would enforce a healthy 
>>separation of concerns. Importantly, it would make life much easier on 
>> the 
>>Version Control perspective.
>>3. Documentation should probably be made differently than what people 
>>have got accustomed to by classical languages. Because you seldom find 
>>types, and because IMHO Clojure programs are formed more by factoring out 
>>recurring mechanisms in code than from implementing intellectual 
>>abstractions, the relevant concepts tend not to be obvious in the code. 
>>Since in Clojure we program with verbs, not
>> nouns,
>>I think *documentation is best made by example*.
>>4. Documentation of a Var should not be a formal description of what 
>>it is and what it does with some cryptically-named variables. *Every 
>>bit of documentation should be a micro-tutorial*. Emphasis should be 
>>put on usage, examples, tips, pitfalls, howtos.
>>5. There should be structure in the documentation, and it shouldn't be 
>>just :see-also links - *there should be semantics* in it.  For 
>>example, some functions/macros are really meant to be nothing but 
>>shorthands for calling other functions : that kind of relationship should 
>>be explicitly documented.
>>6. Documentation should not be just information about each separate 
>>Var in a namespace. There should be a hierarchy to make the most useful 
>>elements of an API more obvious. Also, adding cross-vars documentation 
>>elements such as tags and topics could make it easier to navigate and 
>>understand.
>>7. *Documentation in the REPL is great*, it was one of the very good 
>>surprises when I started learning Clojure. However, a rich and 
>> good-looking 
>>presentation like in Javadocs would be welcome too.
>>
>> Of course, all of the above are just vague principles. Here is *some 
>> functionality I suggest for a start :*
>>
>>1. Documentation content elements could be written in a Clojure DSL 
>>emulating some kind of docbook-like markup language.
>>2. On the user side, the documentation would be accessible through a 
>>generated web interface, a REPL interface, and maybe other formats like 
>>Wiki.
>>3. Documentation could be programmed anywhere in a project by simply 
>>referring to the relevant Vars and calling the documentation API. 
>> Ideally,

Re: Experiencing extremely slow performance on raspberry pi (model b)

[David Powell]

Yeah I had similar issues.  I guess the standard JDK is a bit a heavyweight
for the raspberry pi.

I wonder if clojurescript on nodejs might be an easier route?


On Mon, May 12, 2014 at 10:40 AM, C K Kashyap  wrote:

> Hi,
>
> I finally got my robotic vehicle working using raspberry pi. I was hoping
> to make it do tricks using the clojure repl - however, I found that repl
> took well over 2 minutes to start. Is that normal or are folks seeing
> better performance?
>
> Regards,
> Kashyap
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: data.xml namespace aware?

[Timothy Washington]

Interesting. Definitely keep us posted on progress.

Thanks for this Herwig.


Tim Washington
Interruptsoftware.com 


On Sat, May 10, 2014 at 7:25 AM, Herwig Hochleitner
wrote:

> test_namespace.clj just contains some unit tests for now. The final patch
> will have usage examples.
>
> With the proposal, you can define your xml namespaces on a
> clojure-namespace level and refer them via keyword namespaces:
>
> (ns thing)
>
> (xml-default-prefix *ns* "thing")
> (xml-prefix *ns*
>   "thing" "http://thing";)
>
> (def e4 (xml/sexp-as-element
>   [::first {} [::second {}]]))
>
> This improves on handling raw xml-prefixes in two ways:
> - The full xml namespace "http://thing"; is known for an xml name like
> ::first, ::second, not just the prefix you happened to assign in code.
> - You can combine xml fragments from different parts of code, without
> worrying about prefix assignment. The emitter takes care of assigning xmlns
> declarations.
>
> cheers
>
>
> 2014-05-10 0:22 GMT+02:00 Timothy Washington :
>
>> Thanks Herwig. I take it 
>> test_namespace.cljis
>>  the interesting file. Given the example in my previous message, is there
>> a more idiomatic way of defining namespaces with this proposal?
>>
>>
>> Thanks again
>>
>> Tim Washington
>> Interruptsoftware.com 
>>
>>
>>
>> On Thu, May 8, 2014 at 10:54 AM, Herwig Hochleitner <
>> hhochleit...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm the guy working on the newer proposal, which is almost done (TM). It
>>> seems you have found the way to emulate namespacing with the current
>>> data.xml impl: by taking care of xmlns attributes and prefixes yourself. I
>>> definitely want to keep compatibility with that representation. Feel free
>>> to check out my proposal branch here https://github.com/bendlas/data.xml
>>>
>>> cheers
>>>
>>>
>>> 2014-05-06 21:53 GMT+02:00 Timothy Washington :
>>>
 Ok, scratch that. I got it working, lol :)

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

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


 ...gives you this:

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

 
 http://thing";>
   
 



 Tim Washington
 Interruptsoftware.com 


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

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

Re: using atoms as logs for channels in core.async

[gamma235]

Your description of what is going on with my macro was really helpful. In 
my head I was imagining recursive evals running over the code, saying 
first, then, etc. I didn't really think about  compile time vs. run-time. 

I am impressed with James' code as well, but I am having trouble fully 
understanding it and getting it to run. From the transparent put 
definition, it doesn't seem like it is possible to pass a channel value as 
a parameter in the call. The x is referring to the map that is to be added 
in as a parameter, right? at least that is why I learned, when I studied 
destructuring: 

(def point {:x 5 :y 7})
>
 

> (let [{:keys [x y]} point]
>   (println "x:" x "y:" y))
>
 

> => :x 5 :y 7


Does it work different different for defining function parameters? I posted 
more under his comment above, please have a look. 

Like you said, I also feel like I'm *starting* to get it and it is really 
exciting :) Thanks for your advice. 

Jesse

On Monday, May 12, 2014 7:46:34 PM UTC+9, David Della Costa wrote:
>
> > to reason about and can be dangerous. I would suggest putting 
> > dynamically created channels in a collection inside an atom if you 
> > need to create them like this. 
>
> P.S. I just read James's response and I see he said something similar 
> regarding this--it's better to structure this as a hash-map or other 
> data structure, and use an atom if it needs to be updated dynamically. 
> Notice that his code is far simpler and easier to reason about, and 
> avoids the use of macros. 
>
> DD 
>
> (2014/05/12 19:40), Dave Della Costa wrote: 
> >> I think I am confused about how to distinguish between a symbol and a 
> >> variable, as I thought that the symbol being derefed pointed to the 
> >> atom that it was made to define when transparent-chan was called. 
> > 
> > I think it's not so much that, as being mistaken about what is going at 
> > compile-time vs. run-time in your macros.  Going back to your original 
> > code, your log-name function is just fine: 
> > 
> > (defn log-name [ch] (symbol (str ch '-log))) 
> > 
> > It returns a symbol, which is what you want for the second arg to def. 
> > 
> > However, keep in mind that this is going to return a list which will 
> > then get evaluated, but it will only be the last value returned from 
> 'do': 
> > 
> > (defmacro transparent-chan [ch] 
> >   (do 
> > `(def ~ch (chan)) 
> > `(def (log-name ~ch) (atom [])) 
> > `(println "new transparent channel created!"))) 
> > 
> > that is, a list like this: 
> > 
> > `(println "new transparent channel created!") 
> > 
> > ...which will then get evaluated at run-time.  So your def calls will 
> > never run!  If we know that we can adjust it-- 
> > 
> > (defmacro transparent-chan [ch] 
> >   `(do (def ~ch (async/chan)) 
> >(def (log-name ~ch) (atom [])) 
> >(println "new transparent channel created!"))) 
> > 
> > ...but then we get: 
> > 
> > user=> (transparent-chan my-chan) 
> > 
> > CompilerException java.lang.RuntimeException: First argument to def must 
> > be a Symbol, compiling... ; etc. 
> > user=> 
> > 
> > Hmm...still a problem.  Let's see, when is the 'log-name' function 
> > getting run?  Oh, at *run-time*...but we want it run at compile-time. 
> > So, knowing that, we can adjust it again: 
> > 
> > (defmacro transparent-chan [ch] 
> >   `(do (def ~ch (async/chan)) 
> >(def ~(log-name ch) (atom [])) 
> >(println "new transparent channel created!"))) 
> > 
> > Now we see: 
> > 
> > user=> (transparent-chan my-chan) 
> > new transparent channel created! 
> > nil 
> > user=> my-chan 
> > # > clojure.core.async.impl.channels.ManyToManyChannel@7b3287a> 
> > user=> my-chan-log 
> > # 
> > user=> my-chan-log 
> > 
> > Etc. I think that you need to keep playing with it and you'll get it; it 
> > doesn't seem too far off. 
> > 
> > That said, if I were you I'd still try it the simpler way I proposed 
> > before--this seems like a lot of work for not a lot of payoff, when you 
> > can just dump out logging information at the time you send or receive a 
> > message. And in general creating vars like this dynamically is not easy 
> > to reason about and can be dangerous. I would suggest putting 
> > dynamically created channels in a collection inside an atom if you need 
> > to create them like this. 
> > 
> >> Later I was thinking about incorporating it into a gui to see 
> >> if it's possible to design an asynchronous message passing system 
> >> using drag and drop icons that represent pubs and subs, channels with 
> >> a drop-down contents tab, and running listening processes. 
> >> I know this is probably out of my league, but I was just asking 
> >> myself how something like that might be implemented. 
> > 
> > I think it's totally possible and there's no reason it would be out of 
> > your league. Just keep trying and asking questions here (and on IRC too 
> > if you want to jump on, plenty of folks there willing to help out). 
> > 
> > DD 
> > 
> >

Re: How do I mock request with content-type in Ring?

[Ivan Schuetz]

Thanks, that works!

I'm new to Clojure and studying Ring's source to find this would probably 
require more time than I have available… this should be documented in the 
api shouldn't it?

About providing details, my question was more of the kind "what do I have 
to do" than "why isn't it working"... didn't see any sense in providing 
them when it's evidently an incorrect usage of the api, which should be 
visible with the code...

But thanks again, next time I'll try to reserve extra time to study the 
source :)






Am Sonntag, 11. Mai 2014 16:16:14 UTC+2 schrieb John Hume:
>
> On Sunday, May 11, 2014 3:18:56 AM UTC-5, Ivan Schuetz wrote:
>>
>> I tried
>>
>> (let [response (app
>> (content-type (request :post "/login" {:username 
>> "jane" :password "test"})
>>   "application/json"))]  )
>>
>
> Take a look at the source. Params passed to ring-mock.request/request for 
> non-GET, non-HEAD requests will always be passed through to 'body[1], and 
> if those params are a map, they'll always be urlencoded, and the content 
> type of the request will be set to "application/x-www-form-urlencoded"[2]. 
> Your call to content-type is changing the declared content-type of the 
> request, but the body is still urlencoded. If you instead pass in a json 
> string, it will be converted to a byte-array and wrapped in a 
> ByteArrayInputStream without further encoding[3]. So you should be able to 
> do something like the following (untested).
>
>   (-> (request :post "/login" 
>(clojure.data.json/write-str {:username "jane" :password 
> "test"}))
> (content-type "application/json"))
>
> [1]: 
> https://github.com/weavejester/ring-mock/blob/master/src/ring/mock/request.clj#L92-L104
> [2]: 
> https://github.com/weavejester/ring-mock/blob/master/src/ring/mock/request.clj#L70-L73
> [3]: 
> https://github.com/weavejester/ring-mock/blob/master/src/ring/mock/request.clj#L62-L68
>
> Doesn't work...
>>
>
> In the future, it would be helpful to say more about how it doesn't work. 
> For example, you could show us the return value of (content-type (request 
> :post "/login" {:username "jane" :password "test"}) "application/json") 
> and, if you can see what's wrong with it, tell us what's wrong.
>
> The Stack Overflow post you linked to is about peridot, a different 
> library for testing Ring apps.
>
>

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

[Dave Della Costa]

I can give you places to begin at least--recur is a special form and in
Clojure is written in Java,

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L42

whereas in ClojureScript it's written in Clojure:

https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/analyzer.clj#L381-L382

DD

(2014/05/12 20:33), Catonano wrote:
> Where is the source code for recur ? How could I inspect it ?
> 
> 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.

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

[Jozef Wagner]

recur is a special form which is handled by the compiler. The relevant part
of the compiler is at
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L6213
same goes for fn and loop, which are recur targets.

Jozef


On Mon, May 12, 2014 at 1:33 PM, Catonano  wrote:

> Where is the source code for recur ? How could I inspect it ?
>
> 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.
>

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

recur code

[Catonano]

Where is the source code for recur ? How could I inspect it ?

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: Gradle: how to deal with it

[Catonano]

For now I just wrote a quick project file and used lein. I made my
exploration.

Thanks to the both of you





2014-05-10 17:53 GMT+02:00 Dave Ray :

> You should use Clojuresque [1]. The latest version (1.7.0) can start an
> nrepl server for you. Since I'm a bad user (and because of various
> dependency-related hurdles at work), I still haven't actually started using
> it though. Luckily, with earlier versions it's pretty easy to define a new
> task that starts an nrepl server. Here's an example:
>
>
> https://github.com/Netflix/RxJava/blob/master/language-adaptors/rxjava-clojure/build.gradle#L55
>
> With Cider 0.6.0, you can just M-X cider and connect. If you have the
> latest alpha, well, good luck getting back to 0.6.0. For ac-nrepl
> auto-complete you'll want to add clojure-complete [2] as a dependency as
> well.
>
> Good luck,
> Dave
>
> [1] https://bitbucket.org/clojuresque/clojuresque
> [2] https://clojars.org/clojure-complete
>
>
>
> On Sat, May 10, 2014 at 4:00 AM, Catonano  wrote:
>
>> Hello
>>
>> I use to press M-. in Emacs to jump to the definition of a function and
>> M-, to jump back to where I came from
>>
>> This requires an nREPL to be working
>>
>> Now I'd like to explore a project using Gradle.
>>
>> Can I get an nREPL with Gradle ? Can Gradle export a project file so that
>> I can use lein to have an nREPL ?
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: using atoms as logs for channels in core.async

[Dave Della Costa]

> to reason about and can be dangerous. I would suggest putting
> dynamically created channels in a collection inside an atom if you
> need to create them like this.

P.S. I just read James's response and I see he said something similar
regarding this--it's better to structure this as a hash-map or other
data structure, and use an atom if it needs to be updated dynamically.
Notice that his code is far simpler and easier to reason about, and
avoids the use of macros.

DD

(2014/05/12 19:40), Dave Della Costa wrote:
>> I think I am confused about how to distinguish between a symbol and a
>> variable, as I thought that the symbol being derefed pointed to the
>> atom that it was made to define when transparent-chan was called.
> 
> I think it's not so much that, as being mistaken about what is going at
> compile-time vs. run-time in your macros.  Going back to your original
> code, your log-name function is just fine:
> 
> (defn log-name [ch] (symbol (str ch '-log)))
> 
> It returns a symbol, which is what you want for the second arg to def.
> 
> However, keep in mind that this is going to return a list which will
> then get evaluated, but it will only be the last value returned from 'do':
> 
> (defmacro transparent-chan [ch]
>   (do
> `(def ~ch (chan))
> `(def (log-name ~ch) (atom []))
> `(println "new transparent channel created!")))
> 
> that is, a list like this:
> 
> `(println "new transparent channel created!")
> 
> ...which will then get evaluated at run-time.  So your def calls will
> never run!  If we know that we can adjust it--
> 
> (defmacro transparent-chan [ch]
>   `(do (def ~ch (async/chan))
>(def (log-name ~ch) (atom []))
>(println "new transparent channel created!")))
> 
> ...but then we get:
> 
> user=> (transparent-chan my-chan)
> 
> CompilerException java.lang.RuntimeException: First argument to def must
> be a Symbol, compiling... ; etc.
> user=>
> 
> Hmm...still a problem.  Let's see, when is the 'log-name' function
> getting run?  Oh, at *run-time*...but we want it run at compile-time.
> So, knowing that, we can adjust it again:
> 
> (defmacro transparent-chan [ch]
>   `(do (def ~ch (async/chan))
>(def ~(log-name ch) (atom []))
>(println "new transparent channel created!")))
> 
> Now we see:
> 
> user=> (transparent-chan my-chan)
> new transparent channel created!
> nil
> user=> my-chan
> # clojure.core.async.impl.channels.ManyToManyChannel@7b3287a>
> user=> my-chan-log
> #
> user=> my-chan-log
> 
> Etc. I think that you need to keep playing with it and you'll get it; it
> doesn't seem too far off.
> 
> That said, if I were you I'd still try it the simpler way I proposed
> before--this seems like a lot of work for not a lot of payoff, when you
> can just dump out logging information at the time you send or receive a
> message. And in general creating vars like this dynamically is not easy
> to reason about and can be dangerous. I would suggest putting
> dynamically created channels in a collection inside an atom if you need
> to create them like this.
> 
>> Later I was thinking about incorporating it into a gui to see
>> if it's possible to design an asynchronous message passing system
>> using drag and drop icons that represent pubs and subs, channels with
>> a drop-down contents tab, and running listening processes.
>> I know this is probably out of my league, but I was just asking
>> myself how something like that might be implemented.
> 
> I think it's totally possible and there's no reason it would be out of
> your league. Just keep trying and asking questions here (and on IRC too
> if you want to jump on, plenty of folks there willing to help out).
> 
> DD
> 
> (2014/05/12 17:26), gamma235 wrote:
>> Thank you for your answer David. 
>>
>> I think I am confused about how to distinguish between a symbol and a
>> variable, as I thought that the symbol being derefed pointed to the atom
>> that it was made to define when transparent-chan was called.
>>
>> Also, I am trying to specifically solve the logging problem  to
>> understand how I might use stored values or state outside the scope of
>> the channel as a means of creating the illusion of referencing its
>> contents. Later I was thinking about incorporating it into a gui to see
>> if it's possible to design an asynchronous message passing system using
>> drag and drop icons that represent pubs and subs, channels with a
>> drop-down contents tab, and running listening processes. I know this is
>> probably out of my league, but I was just asking myself how something
>> like that might be implemented. I will of course continue to learn and
>> reinforce the basics though on my own. 
>>
>> Jesse
>>
>> On Monday, May 12, 2014 1:26:57 PM UTC+9, David Della Costa wrote:
>>
>> I apologize, apparently you can't use go-loop how I did below,
>>
>> => (def my-go-loop (async/go-loop [msg (async/> msg "
>> msg " from channel " 'c)))
>>
>> ...try this instead:
>>
>> (def my-go-loo

Re: using atoms as logs for channels in core.async

[Dave Della Costa]

> I think I am confused about how to distinguish between a symbol and a
> variable, as I thought that the symbol being derefed pointed to the
> atom that it was made to define when transparent-chan was called.

I think it's not so much that, as being mistaken about what is going at
compile-time vs. run-time in your macros.  Going back to your original
code, your log-name function is just fine:

(defn log-name [ch] (symbol (str ch '-log)))

It returns a symbol, which is what you want for the second arg to def.

However, keep in mind that this is going to return a list which will
then get evaluated, but it will only be the last value returned from 'do':

(defmacro transparent-chan [ch]
  (do
`(def ~ch (chan))
`(def (log-name ~ch) (atom []))
`(println "new transparent channel created!")))

that is, a list like this:

`(println "new transparent channel created!")

...which will then get evaluated at run-time.  So your def calls will
never run!  If we know that we can adjust it--

(defmacro transparent-chan [ch]
  `(do (def ~ch (async/chan))
   (def (log-name ~ch) (atom []))
   (println "new transparent channel created!")))

...but then we get:

user=> (transparent-chan my-chan)

CompilerException java.lang.RuntimeException: First argument to def must
be a Symbol, compiling... ; etc.
user=>

Hmm...still a problem.  Let's see, when is the 'log-name' function
getting run?  Oh, at *run-time*...but we want it run at compile-time.
So, knowing that, we can adjust it again:

(defmacro transparent-chan [ch]
  `(do (def ~ch (async/chan))
   (def ~(log-name ch) (atom []))
   (println "new transparent channel created!")))

Now we see:

user=> (transparent-chan my-chan)
new transparent channel created!
nil
user=> my-chan
#
user=> my-chan-log
#
user=> my-chan-log

Etc. I think that you need to keep playing with it and you'll get it; it
doesn't seem too far off.

That said, if I were you I'd still try it the simpler way I proposed
before--this seems like a lot of work for not a lot of payoff, when you
can just dump out logging information at the time you send or receive a
message. And in general creating vars like this dynamically is not easy
to reason about and can be dangerous. I would suggest putting
dynamically created channels in a collection inside an atom if you need
to create them like this.

> Later I was thinking about incorporating it into a gui to see
> if it's possible to design an asynchronous message passing system
> using drag and drop icons that represent pubs and subs, channels with
> a drop-down contents tab, and running listening processes.
> I know this is probably out of my league, but I was just asking
> myself how something like that might be implemented.

I think it's totally possible and there's no reason it would be out of
your league. Just keep trying and asking questions here (and on IRC too
if you want to jump on, plenty of folks there willing to help out).

DD

(2014/05/12 17:26), gamma235 wrote:
> Thank you for your answer David. 
> 
> I think I am confused about how to distinguish between a symbol and a
> variable, as I thought that the symbol being derefed pointed to the atom
> that it was made to define when transparent-chan was called.
> 
> Also, I am trying to specifically solve the logging problem  to
> understand how I might use stored values or state outside the scope of
> the channel as a means of creating the illusion of referencing its
> contents. Later I was thinking about incorporating it into a gui to see
> if it's possible to design an asynchronous message passing system using
> drag and drop icons that represent pubs and subs, channels with a
> drop-down contents tab, and running listening processes. I know this is
> probably out of my league, but I was just asking myself how something
> like that might be implemented. I will of course continue to learn and
> reinforce the basics though on my own. 
> 
> Jesse
> 
> On Monday, May 12, 2014 1:26:57 PM UTC+9, David Della Costa wrote:
> 
> I apologize, apparently you can't use go-loop how I did below,
> 
> => (def my-go-loop (async/go-loop [msg (async/ msg "
> msg " from channel " 'c)))
> 
> ...try this instead:
> 
> (def my-go-loop (async/go-loop [] (let [msg (async/ msg " msg " from channel " 'c
> 
> Sorry about that!
> 
> DD
> 
> (2014/05/12 13:21), Dave Della Costa wrote:
> >
> >> 1) I feel like it is a redundant to define bindings multiple
> times in
> >> my go's let exprs when the params have already been passed in as
> >> arguments. Is there a more idiomatic way to do this?
> >
> > I think the fact that you are re-binding in a let should show you
> that
> > these variables are already in scope: that let is wholly
> redundant, just
> > remove it.
> >
> >
> >> 2) Whenever I try to create a generic process to automatically
> >> generate a log-name for each channel and then call update, I get a
>

Re: using atoms as logs for channels in core.async

[gamma235]

When I try this using your code above I get a stack-trace that I can't 
understand. Am I using it wrong?

(transparent-chan c)
> (transparent-put c 42)
> (transparent-take c)



   - 
>
>"Exception in thread \"async-dispatch-64\" "
>"java.lang.IllegalArgumentException: No implementation of method: 
>:take! of protocol: #'clojure.core.async.impl.protocols/ReadPort found for 
>class: nil"
>"\tat clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541)"
   
   





On Monday, May 12, 2014 1:16:19 PM UTC+9, James Reeves wrote:
>
> On 12 May 2014 03:41, gamma235 > wrote:
>
>>
>> (defn log-name [ch] (symbol (str ch '-log)))
>>>  
>>>  ;; Is this efficiently written?
>>> (defmacro transparent-chan [ch]   
>>>   (do
>>> `(def ~ch (chan))
>>> `(def (log-name ~ch) (atom []))
>>> `(println "new transparent channel created!")))
>>>
>>
> This looks like you're replicating the functionality of maps using defs. 
> Instead, consider something like:
>
> (defn transparent-chan [ch]
>   {:channel ch, :buffer (atom [])})
>
> Another improvement you may wish to consider is to use a queue, rather 
> than a vector. Immutable queues exist in Clojure, but are something of a 
> hidden feature.
>
> (defn transparent-chan [ch]
>   {:channel ch, :buffer (atom clojure.lang.PersistentQueue/EMPTY)})
>
> Queues act more like channels, in that popping a queue strips off the 
> oldest item, whereas popping a vector strips off the newest.
>
> With this in mind, you could write functions like:
>
> (defn transparent-put [{:keys [channel buffer]} x]
>   (go
> (>! channel x)
> (swap! buffer conj x)))
>
> (defn transparent-take [{:keys [channel buffer]} x]
>   (go
> (let [x (   (swap! buffer pop)
>   x)))
>
> (defn transparent-buffer [{keys [buffer]}]
>   (vec @buffer))
>
> - James
>

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

Experiencing extremely slow performance on raspberry pi (model b)

[C K Kashyap]

Hi,

I finally got my robotic vehicle working using raspberry pi. I was hoping
to make it do tricks using the clojure repl - however, I found that repl
took well over 2 minutes to start. Is that normal or are folks seeing
better performance?

Regards,
Kashyap

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

[Colin Fleming]

If you're releasing source, then I think Jozef is correct that you can use
whichever licence you like. However if those sources rely on library G to
work, then you're essentially releasing something that's impossible for
your users to use according to the terms of the licences. From the EPL FAQ
link that Jozef provided:

you may not combine EPL and GPL code in any scenario where linking exists
> between code made available under those licenses.
>

That sounds pretty cut and dried to me, my interpretation has always been
that GPL libs are impossible to use from Clojure, and that Clojure may not
be used from GPL applications.

I'm not a lawyer however, and this stuff generally gives me hives, so take
with a pinch of salt.


On 12 May 2014 20:22, Gunnar Völkel  wrote:

> Program B will be released as source. So in this case I can choose the
> license of program B independently since it is no "derivative work" of
> library G? As far as I read a hint that program B is not "derivative work"
> of library G is that I could exchange library G with a different library
> which implements similar functionality.
>
> In general it would be helpful to gather information about these licensing
> issues for Clojure library authors.
>
> @Colin: Library G is in fact a Java library.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: using atoms as logs for channels in core.async

[gamma235]

Thanks James,

I played around with the persistent queues before I started this exercise, 
but opted for atoms, after seeing this behavior (a la JOC): 




I never considered sticking the persistent queue in the atom and your code 
above made me realize that maps are a way better way to do this. 

Rock on, 

Jesse

On Monday, May 12, 2014 1:16:19 PM UTC+9, James Reeves wrote:
>
> On 12 May 2014 03:41, gamma235 > wrote:
>
>>
>> (defn log-name [ch] (symbol (str ch '-log)))
>>>  
>>>  ;; Is this efficiently written?
>>> (defmacro transparent-chan [ch]   
>>>   (do
>>> `(def ~ch (chan))
>>> `(def (log-name ~ch) (atom []))
>>> `(println "new transparent channel created!")))
>>>
>>
> This looks like you're replicating the functionality of maps using defs. 
> Instead, consider something like:
>
> (defn transparent-chan [ch]
>   {:channel ch, :buffer (atom [])})
>
> Another improvement you may wish to consider is to use a queue, rather 
> than a vector. Immutable queues exist in Clojure, but are something of a 
> hidden feature.
>
> (defn transparent-chan [ch]
>   {:channel ch, :buffer (atom clojure.lang.PersistentQueue/EMPTY)})
>
> Queues act more like channels, in that popping a queue strips off the 
> oldest item, whereas popping a vector strips off the newest.
>
> With this in mind, you could write functions like:
>
> (defn transparent-put [{:keys [channel buffer]} x]
>   (go
> (>! channel x)
> (swap! buffer conj x)))
>
> (defn transparent-take [{:keys [channel buffer]} x]
>   (go
> (let [x (   (swap! buffer pop)
>   x)))
>
> (defn transparent-buffer [{keys [buffer]}]
>   (vec @buffer))
>
> - James
>

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

Re: using atoms as logs for channels in core.async

[gamma235]

Thank you for your answer David. 

I think I am confused about how to distinguish between a symbol and a 
variable, as I thought that the symbol being derefed pointed to the atom 
that it was made to define when transparent-chan was called. 

Also, I am trying to specifically solve the logging problem  to understand 
how I might use stored values or state outside the scope of the channel as 
a means of creating the illusion of referencing its contents. Later I was 
thinking about incorporating it into a gui to see if it's possible to 
design an asynchronous message passing system using drag and drop icons 
that represent pubs and subs, channels with a drop-down contents tab, and 
running listening processes. I know this is probably out of my league, but 
I was just asking myself how something like that might be implemented. I 
will of course continue to learn and reinforce the basics though on my own. 

Jesse

On Monday, May 12, 2014 1:26:57 PM UTC+9, David Della Costa wrote:
>
> I apologize, apparently you can't use go-loop how I did below, 
>
> => (def my-go-loop (async/go-loop [msg (async/ msg " from channel " 'c))) 
>
> ...try this instead: 
>
> (def my-go-loop (async/go-loop [] (let [msg (async/ msg " msg " from channel " 'c 
>
> Sorry about that! 
>
> DD 
>
> (2014/05/12 13:21), Dave Della Costa wrote: 
> > 
> >> 1) I feel like it is a redundant to define bindings multiple times in 
> >> my go's let exprs when the params have already been passed in as 
> >> arguments. Is there a more idiomatic way to do this? 
> > 
> > I think the fact that you are re-binding in a let should show you that 
> > these variables are already in scope: that let is wholly redundant, just 
> > remove it. 
> > 
> > 
> >> 2) Whenever I try to create a generic process to automatically 
> >> generate a log-name for each channel and then call update, I get a 
> >> 'symbol cannot be cast to atom' error. How can I get around this? It 
> >> seems to happen even if I don't use the log-name function. 
> > 
> > It's simple: a symbol is not an atom.  It's telling you exactly what you 
> > need to know: you cannot call swap! on a symbol.  Make sure your atom is 
> > the first argument to swap! wherever you use it. 
> > 
> > 
> >> 3) Is there a better way to keep track of what's on a channel that 
> >> doesn't use macros? 
> > 
> > You cannot look inside of a channel, but to do what you want and get a 
> > sense of how core.async works, I think you are on the right track by 
> > logging as you put stuff in and take it out. 
> > 
> > That said, I would start by getting rid of the log and the macro--these 
> > are unnecessary complications--and do things very simply: 
> > 
> > => (require '[clojure.core.async :as async]) 
> > nil 
> > => (def c (async/chan)) 
> > #'user/c 
> > => (def my-go-loop (async/go-loop [msg (async/ > msg " from channel " 'c))) 
> > #'user/my-go-loop 
> > => (defn put-and-print! [c msg] (println "putting msg " msg " onto 
> > channel " 'c) (async/put! c msg)) 
> > #'user/put-and-print! 
> > => (put-and-print! c "I am a message!") 
> > putting msg  I am a message!  onto channel  c 
> > got msg  I am a message!  from channel  c 
> > nil 
> > => 
> > 
> > Printing out "channel c" is kind of silly since there is only one, but 
> > it sounds like you may want to do this with multiple channels so this is 
> > one way to print out the variable name--simply quote it. 
> > 
> > DD 
> > 
> > (2014/05/12 11:41), gamma235 wrote: 
> >> Hi everyone, 
> >> 
> >> I am getting my feet wet with core.async and am trying to attach atoms 
> >> to channels that update automatically and print out to the console as 
> >> you take and put. This is not for anything serious, just a way to get 
> >> familiar with the behavior and functionality of the library and 
> practice 
> >> my Clojure skills. Thanks in advaan 
> >> 
> >> Here is my code: 
> >> 
> >> (defn log-name [ch] (symbol (str ch '-log))) 
> >>   
> >>  ;; Is this efficiently written? 
> >> (defmacro transparent-chan [ch]   
> >>   (do 
> >> `(def ~ch (chan)) 
> >> `(def (log-name ~ch) (atom [])) 
> >> `(println "new transparent channel created!"))) 
> >>   
> >> (defn- update [log v] 
> >>   (do 
> >> (swap! log conj v) 
> >> (println "log test passed: " v " has been logged") 
> >> (println "channel contents: " @log))) 
> >>   
> >>  (defn transparent-put [ch v] 
> >>(let [log (log-name ch)] 
> >>  (go 
> >>   (let [ch ch 
> >> v v] 
> >> (>! ch v) 
> >> (println v " has been successfully moved through the 
> channel"))) 
> >>  (update log v) 
> >>  (println "put test passed: " v " has been put on the channel") 
> >>  (println " rechecking channel contents: " @log))) 
> >>   
> >> (defn transparent-take [ch] 
> >>   (go 
> >>(let [v ( >>  log-name (symbol (str ch '-log))] 

Re: Licensing program written in Clojure under GPL

[Gunnar Völkel]

Program B will be released as source. So in this case I can choose the 
license of program B independently since it is no "derivative work" of 
library G? As far as I read a hint that program B is not "derivative work" 
of library G is that I could exchange library G with a different library 
which implements similar functionality.

In general it would be helpful to gather information about these licensing 
issues for Clojure library authors.

@Colin: Library G is in fact a Java library.

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