Re: [ANN] riddley: code-walking without caveats

[Konrad Hinsen]

Zach Tellman writes:

 > I see.  This is honestly something I hadn't considered, but since
 > Riddley actually uses the Clojure compiler internals to track
 > locals, this would be as simple as a (when-not (contains?
 > (riddley.compiler/locals) (first expr)) ...) guard in the
 > macroexpansion.

If you don't need complete recursive expansion, that's indeed an
approach worth exploring. For tools.macros that's not an option
because the compiler knows nothing about local macros and symbol
macros.

 > As Ben points out, using the compiler this way is the only way to
 > make sure that locals are consistent everywhere, rather than just
 > in your own targeted use to track shadowing.

Well, either you use the compiler or you replicate what it does.  For
tools.macro I had to choose the second approach. I don't claim it has
no bugs, I just claim I haven't had any bug reports ;-) (until today
at least).

Konrad

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

Re: [ANN] riddley: code-walking without caveats

[Zach Tellman]

I'm not sure what you mean by "complete recursive expansion".  Could you
expand on that?

As for replicating the behavior of the compiler, I'd assert that unless
&env is precisely what it would be without ahead of time macroexpansion,
the compiler's behavior isn't being replicated.  The tools.macro library
emulates an aspect of its behavior, certainly, and the fact that Clojure's
existed this long without anyone doing something like this indicates that
maybe this isn't such a huge omission, but without there remains an uncanny
valley.


On Wed, Sep 4, 2013 at 12:09 AM, Konrad Hinsen <
googlegro...@khinsen.fastmail.net> wrote:

> Zach Tellman writes:
>
>  > I see.  This is honestly something I hadn't considered, but since
>  > Riddley actually uses the Clojure compiler internals to track
>  > locals, this would be as simple as a (when-not (contains?
>  > (riddley.compiler/locals) (first expr)) ...) guard in the
>  > macroexpansion.
>
> If you don't need complete recursive expansion, that's indeed an
> approach worth exploring. For tools.macros that's not an option
> because the compiler knows nothing about local macros and symbol
> macros.
>
>  > As Ben points out, using the compiler this way is the only way to
>  > make sure that locals are consistent everywhere, rather than just
>  > in your own targeted use to track shadowing.
>
> Well, either you use the compiler or you replicate what it does.  For
> tools.macro I had to choose the second approach. I don't claim it has
> no bugs, I just claim I haven't had any bug reports ;-) (until today
> at least).
>
> Konrad
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/a68aThpvP4o/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[ANN] "Type Coverage" - core.typed 0.2.3, lein-typed 0.3.0

[Ambrose Bonnaire-Sergeant]

Hi,

core.typed  0.2.3 is up, and comes
with two new functions:
- statistics
- 
var-coverage

*statistics* returns a map of data on the results of type checking some
namespaces. *var-coverage* is an example of how to leverage this data to
write quick and easy aggregating functions.

This works well at the REPL, for example var-coverage accepts zero
arguments for the current namespace.

clojure.core.typed.utils=> (t/var-coverage)
Start collecting clojure.core.typed.utils
Finished collecting clojure.core.typed.utils
Collected 1 namespaces in 347.052768 msecs
Checked 0 namespaces (approx. 0 lines) in 347.38633 msecs
Found 12 annotated vars out of 51 vars
23% var annotation coverage
nil


lein-typed  0.3.0 is also
released, and supports a new
coveragecommand.
It requires core.typed 0.2.3 or later to use.

$ lein typed coverage
Initializing core.typed ...
"Elapsed time: 4505.279024 msecs"
core.typed initialized.
Start collecting typed-demo.core
Finished collecting typed-demo.core
Collected 1 namespaces in 4619.570363 msecs
Checked 0 namespaces (approx. 0 lines) in 4621.945525 msecs
Start collecting typed-demo.nil
Finished collecting typed-demo.nil
Collected 1 namespaces in 20.48361 msecs
Checked 0 namespaces (approx. 0 lines) in 20.645363 msecs
Found 2 annotated vars out of 2 vars
100% var annotation coverage

This is all part of Brandon Bloom's ideal vision of how types should be
used in Clojure. Thanks for the great idea!

Enjoy!
Ambrose

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

Re: Design Composition and Performance

[Sam Aaron]

On 3 Sep 2013, at 18:39, Stan Dyck  wrote:

> (Not giving up on emacs-live tho. Can we wire on a theremin somehow in the 
> next release?)

I already have prototypes of wiring in MIDI controllers directly to values in 
arbitrary Emacs buffers. It wouldn't be hard to switch to using a Leap Motion 
controller which would have a similar effect as a theremin...

Sam

---
http://sam.aaron.name


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

Re: hashing binary data

[Brian Craft]

On Tuesday, September 3, 2013 10:03:00 PM UTC-7, Mikera wrote:
>
>
>
> On Wednesday, 4 September 2013 12:37:33 UTC+8, Brian Craft wrote:
>>
>>
>>
>> On Tuesday, September 3, 2013 9:14:30 PM UTC-7, Mikera wrote:
>>>
>>> On Wednesday, 4 September 2013 10:00:42 UTC+8, Brian Craft wrote:
>>>
 I'm loading data files of about 1-2G, which are composed of a bunch of 
 numeric data blocks. I need to store the data blocks w/o storing 
 duplicates. They arrive as vectors of floats, and are stored as primitive 
 byte arrays.

 I first tried memoizing the function that saves a block (returning an 
 id), with the core memoize function. This failed because every block 
 became 
 a different key in the memoization, regardless of the content. It looks 
 like clojure treats variables referencing primitive arrays as equal only 
 if 
 they refer to the same array. Note:

 cavm.core=> ({[1 2 3] "foo"} [1 2 3])
 "foo"
 cavm.core=> ({(float-array [1 2 3]) "foo"} (float-array [1 2 3]))
 nil
 cavm.core=> (let [a (float-array [1 2 3])] ({a "foo"} a))
 "foo"



 I next tried memoizing over the vector of floats, however performance 
 became pathologically slow, and the process threw an OOM. I'm guessing 
 this 
 is due to the memory requirements of a clojure vector of floats vs. a 
 primitive array of bytes holding the same data. Is there an easy way to 
 compare the storage requirements?

 Any suggestions on how better to handle this?

>>>
>>> You may want to use the :ndarray-float array implementation in the 
>>> latest version of core.matrix.
>>>
>>> This is effectively a wrapper over a raw Java float array: so your 
>>> storage requirement should be close to the size of the raw byte data 
>>> (assuming the data blocks are large enough that the size of the wrapper is 
>>> negligible)
>>>
>>
>> Ah, interesting.
>>
>> > *matrix-implementation*
>> :vectorz
>> > ({(matrix [1 2 3 4]) "foo"} (matrix [1 2 3 4]))
>> "foo"
>>
>> I don't otherwise need core.matrix at this point in the loader, but this 
>> is convenient. Why does that work?
>>
>
> That works because Vectorz (the underlying Java lib) has a sane 
> implementation of .equals and .hashCode. It's pretty fast as well, though 
> it is still O(n) since it doesn't do hashcode caching.
>
> Note that the :vectorz implementation uses 8-byte doubles rather than 
> 4-byte floats though - so if you really need single precision to keep the 
> overall memory usage down then it might not be the best choice. I 
> personally never use 4-byte floats because the numerical errors soon become 
> problematic, but YMMV.
>
>
It looks like I can get this working for byte arrays as follows.

(deftype BAHashable [ba] 
  Object
  (equals [f g] (java.util.Arrays/equals ba (.ba g)))
  (hashCode [f] (java.util.Arrays/hashCode ba)))

({(BAHashable. (byte-array (map byte [1 2 3]))) "foo"} (BAHashable. 
(byte-array (map byte [1 2 3]
"foo"


I'm less certain of whether this is a good idea.

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

Re: [ANN] riddley: code-walking without caveats

[Konrad Hinsen]

On Wed, Sep 4, 2013, at 09:25 AM, Zach Tellman wrote:



I'm not sure what you mean by "complete recursive expansion".
Could you expand

on that?



Completely ;-)


By complete recursive expansion I mean that you get a form that is
fully reduced to

the core language, i.e. it contains no more macro applications at any
level.


If you leave macro expansion to the compiler, it does it when it
arrives at the

macro during evaluation. Then it does a plain non-recursive macroexpand
and goes on

evaluating. Any macro thus has access to the unexpanded contents of its
form, but

not to what it eventually expands to. For many applications that's just
fine, which

is why this approach has been the default in the Lisp world for a long
time.



As for replicating the behavior of the compiler, I'd assert that
unless &env is

precisely what it would be without ahead of time macroexpansion,
the compiler's

behavior isn't being replicated.



I agree. tools.macro predates &env, which is why it is not supported.
Since I have

never need &env support and nobody ever asked for it (before now), it's
not there.

I don't see any reason why it couldn't be supported.


Konrad.

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

Re: Clojure for the Brave and True, an online book for beginners

[Daniel Higginbotham]

On Wednesday, September 4, 2013 12:17:12 AM UTC-4, Jason Lewis wrote:

> +1 for outsourcing editor infos. Is this on Github? I might be inclined to 
> open a pull request for Vim or LightTable.
> On Sep 3, 2013 8:42 PM, "Greg" > 
> wrote:
>
>> I think it could benefit from more posts on using Clojure with IDE/Editor 
>> ___.
>>
>> Perhaps outsource some of that with links to existing posts on the topic.
>>
>> I hesitate to recommend this to anyone because I can't recommend Emacs 
>> (even though it's my primary terminal editor).
>>
>> - Greg
>>
>

Thanks for the feedback! It is indeed on 
github: https://github.com/flyingmachine/brave-clojure-web

At the bottom of http://www.braveclojure.com/getting-started/ I link to 
resources for sublime text 2, vim, and CCW, and I'd definitely appreciate 
more links :) 

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

Re: core.async and referential transparency

[bertschi]

Hi Sean,

thanks for the link, but I did look at Elm before and read the papers a 
couple month ago ... as far as I remember the implementation somewhat 
follows FrTime/Flapjax, but with an additional async expression, which does 
not prevent glitches.

Best,

Nils  

On Tuesday, September 3, 2013 7:49:25 PM UTC+2, Sean Corfield wrote:
>
> Just an aside, Nils, have you take a look at Elm? It's a Haskell-like 
> language, designed for FRP, compiles to JS, and deliberately avoids 
> monads and arrows (at least in terminology) by having Signal and 
> Automaton abstractions... http://elm-lang.org 
>
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[Jeremy Wright]

I decided to start with the BeagleBone Black as the embedded controller, 
partly because of the low cost ($45) and partly because I have one on hand. 
So, the first thing I need to do is make sure that I can get the I2C 
interface to work from Clojure.

Gregg Harrington's post might work as a starting point: 
http://www.greggharrington.com/articles/beaglebone-i2c-java-adapter

I'm assuming that I can use Java interop in Clojure to do the same thing. I 
have a Melexis MLX90614 I2C temperature sensor laying around already, so 
I'll try to get data from it with the BeagleBone/Linux/Java/Clojure stack 
first. If that works I can try something more complex.

Here's a good (and quick) explanation of I2C (and SPI) for anyone not 
familiar with it: http://quick2wire.com/articles/i2c-and-spi/

On Monday, September 2, 2013 2:16:43 PM UTC-4, Jeremy Wright wrote:
>
> Thanks for the great information nakkaya. You've worked on some very cool 
> things.
>
> About the Java friendly micros - I mentioned Systronix, but it looks like 
> that community and product line may be dormant or even abandoned. There 
> haven't been any posts to their Google Groups or many of their forums for 
> at least a year.
>
> What about using the built-in I2C interface on the BeagleBone/BeagleBoard 
> to handle the I/O? For example, something like this 
> productfrom
>  Robot Shop. As you mentioned, you're still offloading the real-time 
> work onto another microcontroller (ATmega8L), but by using I2C bus devices 
> you can expand your control system as needed without an Arduino. Would 
> there be any disadvantages to doing this?
>
> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote:
>>
>> I recently watched Carin Meier's OSCON talk The Joy of Flying Robots 
>> with Clojure  and it made me 
>> wonder about Clojure on embedded systems. A quick search on this list 
>> didn't turn up much so I thought I'd ask. How much work has been done with 
>> Clojure on either Java friendly microcontroller systems (i.e. 
>> Systronix), 
>> or on something like a Beaglebone or Beagleboard? I'm very new to Clojure, 
>> so I don't yet understand the challenges that Clojure would face trying to 
>> run on a system that may not support all the JVM's features.
>>
>> Any thoughts on this? Any links you can give me on what's been/being done?
>>
>> Thanks.
>>
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[Jeremy Wright]

That's a great idea, thanks Omer. I'm still learning Clojure and haven't 
touched ClojureScript yet, but it doesn't sound like it's an overly 
difficult transition.

Another plus on the ClojureScript side (long term) might be execution 
speed. I recently watched a Clojure Conj 2012 presentation by Chris Granger 
where he talks about being able to obtain very good performance (as in 60 
frames per second in a game) with ClojureScript: 
http://www.youtube.com/watch?v=V1Eu9vZaDYw&list=TL6M8RJo7MDr0

On Wednesday, September 4, 2013 10:09:25 AM UTC-4, Omer Iqbal wrote:
>
> Another possible approach could be use clojurescript to a nodejs target. 
> From some cursory googling, there do seem to be node modules like 
> https://github.com/kelly/node-i2c which offer I2C support. 
> And I believe you might also get a better startup time. 
>
>
> On Wed, Sep 4, 2013 at 8:35 PM, Jeremy Wright 
> > wrote:
>
>> I decided to start with the BeagleBone Black as the embedded controller, 
>> partly because of the low cost ($45) and partly because I have one on hand. 
>> So, the first thing I need to do is make sure that I can get the I2C 
>> interface to work from Clojure.
>>
>> Gregg Harrington's post might work as a starting point: 
>> http://www.greggharrington.com/articles/beaglebone-i2c-java-adapter
>>
>> I'm assuming that I can use Java interop in Clojure to do the same thing. 
>> I have a Melexis MLX90614 I2C temperature sensor laying around already, so 
>> I'll try to get data from it with the BeagleBone/Linux/Java/Clojure stack 
>> first. If that works I can try something more complex.
>>
>> Here's a good (and quick) explanation of I2C (and SPI) for anyone not 
>> familiar with it: http://quick2wire.com/articles/i2c-and-spi/
>>
>> On Monday, September 2, 2013 2:16:43 PM UTC-4, Jeremy Wright wrote:
>>>
>>> Thanks for the great information nakkaya. You've worked on some very 
>>> cool things.
>>>
>>> About the Java friendly micros - I mentioned Systronix, but it looks 
>>> like that community and product line may be dormant or even abandoned. 
>>> There haven't been any posts to their Google Groups or many of their forums 
>>> for at least a year.
>>>
>>> What about using the built-in I2C interface on the 
>>> BeagleBone/BeagleBoard to handle the I/O? For example, something like this 
>>> productfrom
>>>  Robot Shop. As you mentioned, you're still offloading the real-time 
>>> work onto another microcontroller (ATmega8L), but by using I2C bus devices 
>>> you can expand your control system as needed without an Arduino. Would 
>>> there be any disadvantages to doing this?
>>>
>>> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote:

 I recently watched Carin Meier's OSCON talk The Joy of Flying Robots 
 with Clojure  and it made 
 me wonder about Clojure on embedded systems. A quick search on this list 
 didn't turn up much so I thought I'd ask. How much work has been done with 
 Clojure on either Java friendly microcontroller systems (i.e. 
 Systronix), 
 or on something like a Beaglebone or Beagleboard? I'm very new to Clojure, 
 so I don't yet understand the challenges that Clojure would face trying to 
 run on a system that may not support all the JVM's features.

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

 Thanks.

>>>  -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[Omer Iqbal]

Another possible approach could be use clojurescript to a nodejs target.
>From some cursory googling, there do seem to be node modules like
https://github.com/kelly/node-i2c which offer I2C support.
And I believe you might also get a better startup time.


On Wed, Sep 4, 2013 at 8:35 PM, Jeremy Wright  wrote:

> I decided to start with the BeagleBone Black as the embedded controller,
> partly because of the low cost ($45) and partly because I have one on hand.
> So, the first thing I need to do is make sure that I can get the I2C
> interface to work from Clojure.
>
> Gregg Harrington's post might work as a starting point:
> http://www.greggharrington.com/articles/beaglebone-i2c-java-adapter
>
> I'm assuming that I can use Java interop in Clojure to do the same thing.
> I have a Melexis MLX90614 I2C temperature sensor laying around already, so
> I'll try to get data from it with the BeagleBone/Linux/Java/Clojure stack
> first. If that works I can try something more complex.
>
> Here's a good (and quick) explanation of I2C (and SPI) for anyone not
> familiar with it: http://quick2wire.com/articles/i2c-and-spi/
>
> On Monday, September 2, 2013 2:16:43 PM UTC-4, Jeremy Wright wrote:
>>
>> Thanks for the great information nakkaya. You've worked on some very cool
>> things.
>>
>> About the Java friendly micros - I mentioned Systronix, but it looks like
>> that community and product line may be dormant or even abandoned. There
>> haven't been any posts to their Google Groups or many of their forums for
>> at least a year.
>>
>> What about using the built-in I2C interface on the BeagleBone/BeagleBoard
>> to handle the I/O? For example, something like this 
>> productfrom
>>  Robot Shop. As you mentioned, you're still offloading the real-time
>> work onto another microcontroller (ATmega8L), but by using I2C bus devices
>> you can expand your control system as needed without an Arduino. Would
>> there be any disadvantages to doing this?
>>
>> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote:
>>>
>>> I recently watched Carin Meier's OSCON talk The Joy of Flying Robots
>>> with Clojure  and it made
>>> me wonder about Clojure on embedded systems. A quick search on this list
>>> didn't turn up much so I thought I'd ask. How much work has been done with
>>> Clojure on either Java friendly microcontroller systems (i.e. 
>>> Systronix),
>>> or on something like a Beaglebone or Beagleboard? I'm very new to Clojure,
>>> so I don't yet understand the challenges that Clojure would face trying to
>>> run on a system that may not support all the JVM's features.
>>>
>>> Any thoughts on this? Any links you can give me on what's been/being
>>> done?
>>>
>>> Thanks.
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] "Type Coverage" - core.typed 0.2.3, lein-typed 0.3.0

[Brandon Bloom]

> lein-typed  0.3.0 is also 
released, and supports a new 
coverage
 command.

Awesome!
 
> This is all part of Brandon Bloom's ideal vision of how types should be 
used in Clojure. Thanks for the great idea!

Heh, you're welcome! Thanks for doing this & the shout out.

Just wanted to elaborate a little bit on the views I shared with Ambrose 
and why I pushed him to do this lein plugin, and then to add the coverage 
command. In short, I view types as just one more tool in the verification 
and correctness toolbox. They have lots of other uses, such as for aiding 
optimization in compilers, but they can (and should!) be part of a varied 
suite of tests for robust applications.

However, just as approaching 100% unit test coverage has diminishing 
returns, so does approaching 100% "type coverage". Type annotations can fit 
in right next to your unit and integration tests, outside of your src 
directory. Alternatively, you can include your type annotations inline, 
just like :pre and :post conditions, or validators. For modules that fit at 
the intersection of easily and precisely typed, core.typed can save you a 
lot of manual verification work!

As for the lein plugin, I think that low barriers to use will encourage 
more people to try core.typed as a verification tool. My dream is to be 
able to run a single command that infers all the types in my program, with 
separate annotations on the public interface from the private ones. Then I 
can then validate and check-in the public annotations and discard the 
private annotations. Whenever I change the public interface or experience 
cascading type inference failures in private code, I'd get a test error 
with lein. In this world, I can get 80% of the benefits of types with only 
20% of the cost.

Cheers,
Brandon

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

Screencast: understanding the thread-first and thread-last macros

[Jernau]

Hi everyone,

I made a screencast about Clojure's *thead-first* (->) and *thread-last* (->>) 
macros:

http://www.youtube.com/watch?v=qxE5wDbt964

If you already have a good understanding of these macros then I'd recommend 
skipping it, but hopefully newcomers to Clojure might learn something 
useful.

Cheers, 
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/groups/opt_out.

Re: Screencast: understanding the thread-first and thread-last macros

[Giacomo Cosenza]

Very clear and easy to follow explanation of Clojure thread macros. Highly 
recommended for Clojure beginners and intermediates.
We should do a lot more screencasts like this. Unfortunately my spoken english 
is too affected by italian accent :(

Highly recommended both for clojure beginners and intermediates.

Mimmo

On Sep 4, 2013, at 5:42 PM, Jernau wrote:

> Hi everyone,
> 
> I made a screencast about Clojure's thead-first (->) and thread-last (->>) 
> macros:
> 
> http://www.youtube.com/watch?v=qxE5wDbt964
> 
> If you already have a good understanding of these macros then I'd recommend 
> skipping it, but hopefully newcomers to Clojure might learn something useful.
> 
> Cheers, 
> 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/groups/opt_out.

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

Re: Clojure for the Brave and True, an online book for beginners

[Dima Sabanin]

Hi Daniel,

Keep up the great work! I really enjoyed the material and how it's
presented.

Thanks,
Dima


On Mon, Sep 2, 2013 at 11:35 AM, Daniel Higginbotham  wrote:

> Hi all,
>
> I've been putting together http://www.braveclojure.com/ and would love
> feedback. I've tried to make it entertaining and super beginner-friendly.
>
> Thanks!
> Daniel
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Best regards,
Dima Sabanin
http://twitter.com/dimasabanin

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

Re: [ANN] riddley: code-walking without caveats

[Zach Tellman]

So "complete recursive expansion" is postwalk macroexpansion?  It seems
like that could break anaphoric macros, and likely others.  A macro has the
option of calling macroexpand-all on its own contents if it wants only
special forms, but it shouldn't be forced to take only special forms.

Also, here's a sketch of how you could do symbol macros using Riddley:
https://gist.github.com/ztellman/6439318.  Please let me know if I'm
missing something w.r.t. how symbol macros are done in tools.macros.

Zach


On Wed, Sep 4, 2013 at 2:16 AM, Konrad Hinsen <
googlegro...@khinsen.fastmail.net> wrote:

> **
> On Wed, Sep 4, 2013, at 09:25 AM, Zach Tellman wrote:
>
> I'm not sure what you mean by "complete recursive expansion".  Could
> you expand
> on that?
>
> Completely ;-)
>
> By complete recursive expansion I mean that you get a form that is fully
> reduced to
> the core language, i.e. it contains no more macro applications at any
> level.
>
> If you leave macro expansion to the compiler, it does it when it arrives
> at the
> macro during evaluation. Then it does a plain non-recursive macroexpand
> and goes on
> evaluating. Any macro thus has access to the unexpanded contents of its
> form, but
> not to what it eventually expands to. For many applications that's just
> fine, which
> is why this approach has been the default in the Lisp world for a long
> time.
>
> As for replicating the behavior of the compiler, I'd assert that
> unless &env is
> precisely what it would be without ahead of time macroexpansion, the
> compiler's
> behavior isn't being replicated.
>
> I agree. tools.macro predates &env, which is why it is not supported.
> Since I have
> never need &env support and nobody ever asked for it (before now), it's
> not there.
> I don't see any reason why it couldn't be supported.
>
> Konrad.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/a68aThpvP4o/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] riddley: code-walking without caveats

[Zach Tellman]

Actually, postwalk expansion (if that is in fact what you were describing)
would ignore any binding forms created by the outer macro.  This means that
something simple like:

(defmacro with-db [db & body]
  `(with-open [~db (create-db)]
 ~@body))

would be expanded without any knowledge of the 'db' local variable, since
that would only get turned into a let form later.  Prewalk is pretty much
the only way this works.


On Wed, Sep 4, 2013 at 9:50 AM, Ben Wolfson  wrote:

> Postwalk expansion would break macros that inspect their argument forms
> for e.g. writing special-purpose queries, if they *also* adopt the symbols
> "and" and "or" for conjunction or disjunction. Korma's "where", for
> instance, does this; one can write
>
> (select my-table (where (and (...) (...
>
> And the "where" detects the "and".
>
> Arguably this is wrongheaded behavior from the get-go (it can be somewhat
> confusing and makes it necessary to use something like clojure.core/and
> within "where" if you want normal clojure-land "and" semantics), but it's a
> style of non-anaphoric macro that relies on receiving an unexpanded form.
>
>
> On Wed, Sep 4, 2013 at 9:27 AM, Zach Tellman  wrote:
>
>> So "complete recursive expansion" is postwalk macroexpansion?  It seems
>> like that could break anaphoric macros, and likely others.  A macro has the
>> option of calling macroexpand-all on its own contents if it wants only
>> special forms, but it shouldn't be forced to take only special forms.
>>
>> Also, here's a sketch of how you could do symbol macros using Riddley:
>> https://gist.github.com/ztellman/6439318.  Please let me know if I'm
>> missing something w.r.t. how symbol macros are done in tools.macros.
>>
>> Zach
>>
>>
>> On Wed, Sep 4, 2013 at 2:16 AM, Konrad Hinsen <
>> googlegro...@khinsen.fastmail.net> wrote:
>>
>>> **
>>> On Wed, Sep 4, 2013, at 09:25 AM, Zach Tellman wrote:
>>>
>>> I'm not sure what you mean by "complete recursive expansion".  Could
>>> you expand
>>> on that?
>>>
>>> Completely ;-)
>>>
>>> By complete recursive expansion I mean that you get a form that is fully
>>> reduced to
>>> the core language, i.e. it contains no more macro applications at any
>>> level.
>>>
>>> If you leave macro expansion to the compiler, it does it when it arrives
>>> at the
>>> macro during evaluation. Then it does a plain non-recursive macroexpand
>>> and goes on
>>> evaluating. Any macro thus has access to the unexpanded contents of its
>>> form, but
>>> not to what it eventually expands to. For many applications that's just
>>> fine, which
>>> is why this approach has been the default in the Lisp world for a long
>>> time.
>>>
>>> As for replicating the behavior of the compiler, I'd assert that
>>> unless &env is
>>> precisely what it would be without ahead of time macroexpansion, the
>>> compiler's
>>> behavior isn't being replicated.
>>>
>>> I agree. tools.macro predates &env, which is why it is not supported.
>>> Since I have
>>> never need &env support and nobody ever asked for it (before now), it's
>>> not there.
>>> I don't see any reason why it couldn't be supported.
>>>
>>> Konrad.
>>>
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/clojure/a68aThpvP4o/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> clojure+unsubscr...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which
> may be sweet, aromatic, fermented or spirit-based. ... Family and social
> life also offer numerou

Clojure JIRA votes

[Alex Miller]

A comment from Andy F on another thread prompted me to write this. There
has been a lot going on in jira land lately and I promise that I will soon
write lots more about it.

In the process  of
getting things moving a bit I've been trying to ferret out what tickets are
most important and/or desired. The best tool I have for this is votes and
watches in JIRA .

In particular, I look at both absolute counts and the weighted vote
reportthat
Andy has automated. The weighted vote decreases weight based on the
number of votes a user makes (so more votes means each vote counts less).

There are many tickets that look at corner cases or extensions to
"complete" the core library functions (adding 0 arity support to a function
for example). I would love to fix all of those but I put a higher priority
on fixing problems that are actually affecting people's work first. Please
vote on things that are affecting you and "spend" your votes wisely!

If you'd like to vote or browse, sign up
here.
To actually contribute patches you must be a
contributor.
Lots more links here 
.

I have created some semi-standard labels (doc'ed at the end of Creating
Tickets ) and
updated many of the existing tickets. You can search for those labels or
just by keyword to find open things. For example, here is a search for open
CLJ tickets about
errormsgs
(one
of the labels).

If you have questions about any of this, I'm happy to answer them.

Alex

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

Re: [ANN] riddley: code-walking without caveats

[Ben Wolfson]

Postwalk expansion would break macros that inspect their argument forms for
e.g. writing special-purpose queries, if they *also* adopt the symbols
"and" and "or" for conjunction or disjunction. Korma's "where", for
instance, does this; one can write

(select my-table (where (and (...) (...

And the "where" detects the "and".

Arguably this is wrongheaded behavior from the get-go (it can be somewhat
confusing and makes it necessary to use something like clojure.core/and
within "where" if you want normal clojure-land "and" semantics), but it's a
style of non-anaphoric macro that relies on receiving an unexpanded form.


On Wed, Sep 4, 2013 at 9:27 AM, Zach Tellman  wrote:

> So "complete recursive expansion" is postwalk macroexpansion?  It seems
> like that could break anaphoric macros, and likely others.  A macro has the
> option of calling macroexpand-all on its own contents if it wants only
> special forms, but it shouldn't be forced to take only special forms.
>
> Also, here's a sketch of how you could do symbol macros using Riddley:
> https://gist.github.com/ztellman/6439318.  Please let me know if I'm
> missing something w.r.t. how symbol macros are done in tools.macros.
>
> Zach
>
>
> On Wed, Sep 4, 2013 at 2:16 AM, Konrad Hinsen <
> googlegro...@khinsen.fastmail.net> wrote:
>
>> **
>> On Wed, Sep 4, 2013, at 09:25 AM, Zach Tellman wrote:
>>
>> I'm not sure what you mean by "complete recursive expansion".  Could
>> you expand
>> on that?
>>
>> Completely ;-)
>>
>> By complete recursive expansion I mean that you get a form that is fully
>> reduced to
>> the core language, i.e. it contains no more macro applications at any
>> level.
>>
>> If you leave macro expansion to the compiler, it does it when it arrives
>> at the
>> macro during evaluation. Then it does a plain non-recursive macroexpand
>> and goes on
>> evaluating. Any macro thus has access to the unexpanded contents of its
>> form, but
>> not to what it eventually expands to. For many applications that's just
>> fine, which
>> is why this approach has been the default in the Lisp world for a long
>> time.
>>
>> As for replicating the behavior of the compiler, I'd assert that
>> unless &env is
>> precisely what it would be without ahead of time macroexpansion, the
>> compiler's
>> behavior isn't being replicated.
>>
>> I agree. tools.macro predates &env, which is why it is not supported.
>> Since I have
>> never need &env support and nobody ever asked for it (before now), it's
>> not there.
>> I don't see any reason why it couldn't be supported.
>>
>> Konrad.
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/a68aThpvP4o/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

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

Catching Exceptions from Threads in REPL

[JvJ]

I'm working on a multithreaded program, and debugging in the repl is very 
hard.  Every time an exception occurs, the thread either shuts down or 
deals with it in some other way.  Is there a way I can get the REPL to 
intercept the exception and display it?

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

Re: hashing binary data

[Brian Craft]

On Wednesday, September 4, 2013 2:13:12 AM UTC-7, Brian Craft wrote:
>
>
>
> On Tuesday, September 3, 2013 10:03:00 PM UTC-7, Mikera wrote:
>>
>>
>>
>> On Wednesday, 4 September 2013 12:37:33 UTC+8, Brian Craft wrote:
>>>
>>>
>>>
>>> On Tuesday, September 3, 2013 9:14:30 PM UTC-7, Mikera wrote:

 On Wednesday, 4 September 2013 10:00:42 UTC+8, Brian Craft wrote:

> I'm loading data files of about 1-2G, which are composed of a bunch of 
> numeric data blocks. I need to store the data blocks w/o storing 
> duplicates. They arrive as vectors of floats, and are stored as primitive 
> byte arrays.
>
> I first tried memoizing the function that saves a block (returning an 
> id), with the core memoize function. This failed because every block 
> became 
> a different key in the memoization, regardless of the content. It looks 
> like clojure treats variables referencing primitive arrays as equal only 
> if 
> they refer to the same array. Note:
>
> cavm.core=> ({[1 2 3] "foo"} [1 2 3])
> "foo"
> cavm.core=> ({(float-array [1 2 3]) "foo"} (float-array [1 2 3]))
> nil
> cavm.core=> (let [a (float-array [1 2 3])] ({a "foo"} a))
> "foo"
>
>
>
> I next tried memoizing over the vector of floats, however performance 
> became pathologically slow, and the process threw an OOM. I'm guessing 
> this 
> is due to the memory requirements of a clojure vector of floats vs. a 
> primitive array of bytes holding the same data. Is there an easy way to 
> compare the storage requirements?
>
> Any suggestions on how better to handle this?
>

 You may want to use the :ndarray-float array implementation in the 
 latest version of core.matrix.

 This is effectively a wrapper over a raw Java float array: so your 
 storage requirement should be close to the size of the raw byte data 
 (assuming the data blocks are large enough that the size of the wrapper is 
 negligible)

>>>
>>> Ah, interesting.
>>>
>>> > *matrix-implementation*
>>> :vectorz
>>> > ({(matrix [1 2 3 4]) "foo"} (matrix [1 2 3 4]))
>>> "foo"
>>>
>>> I don't otherwise need core.matrix at this point in the loader, but this 
>>> is convenient. Why does that work?
>>>
>>
>> That works because Vectorz (the underlying Java lib) has a sane 
>> implementation of .equals and .hashCode. It's pretty fast as well, though 
>> it is still O(n) since it doesn't do hashcode caching.
>>
>> Note that the :vectorz implementation uses 8-byte doubles rather than 
>> 4-byte floats though - so if you really need single precision to keep the 
>> overall memory usage down then it might not be the best choice. I 
>> personally never use 4-byte floats because the numerical errors soon become 
>> problematic, but YMMV.
>>
>>
> It looks like I can get this working for byte arrays as follows.
>
> (deftype BAHashable [ba] 
>   Object
>   (equals [f g] (java.util.Arrays/equals ba (.ba g)))
>   (hashCode [f] (java.util.Arrays/hashCode ba)))
>
> ({(BAHashable. (byte-array (map byte [1 2 3]))) "foo"} (BAHashable. 
> (byte-array (map byte [1 2 3]
> "foo"
>
>
> I'm less certain of whether this is a good idea.
>


This gives me a number of reflection warnings, on field ba, on equals, and 
on hashCode. I can eliminate the one on hashCode by type hinting the ba 
parameter of BAHashable.

The one on (.ba g) and equals remains. Is there any way to hint these?

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

Re: Catching Exceptions from Threads in REPL

[Neale Swinnerton]

Have you experimented with setting a default uncaught exception handler?

See
http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)




*Neale Swinnerton*
{t: @sw1nn , w: sw1nn.com }


On 4 September 2013 18:32, JvJ  wrote:

>
> I'm working on a multithreaded program, and debugging in the repl is very
> hard.  Every time an exception occurs, the thread either shuts down or
> deals with it in some other way.  Is there a way I can get the REPL to
> intercept the exception and display it?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [ANN] riddley: code-walking without caveats

[Konrad Hinsen]

--On 4 septembre 2013 09:27:12 -0700 Zach Tellman  
wrote:



So "complete recursive expansion" is postwalk macroexpansion?  It seems
like that could break anaphoric macros, and likely others.  A macro has
the option of calling macroexpand-all on its own contents if it wants
only special forms, but it shouldn't be forced to take only special forms.


Recursive macro expansion still works from outside in, so each macro gets 
to see the unexpanded form. It's only after the macro has done its 
transformation that the inner forms get expanded.



Also, here's a sketch of how you could do symbol macros using
Riddley: https://gist.github.com/ztellman/6439318.  Please let me know
if I'm missing something w.r.t. how symbol macros are done in
tools.macros.


It's on my reading list for tomorrow!

Konrad.

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

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

Re: Clojure for the Brave and True, an online book for beginners

[Gary Johnson]

Looks pretty solid. Great work so far.

Also +1 for the Emacs coverage. Despite the fact that our surveys still 
show the majority of Clojure users develop in Emacs, this mailing list 
frequently exhibits an anything-but-Emacs tone. By all means add links to 
other editors for folks who are already using something else, but I for one 
think you made a smart choice there. Better to learn Emacs now than to 
learn it later after trying two or three other editors that don't quite cut 
it.

Also, just a quick note, your Emacs search keybindings were incorrect in 
that chapter. C-s and C-r are just regular isearch-forward and 
isearch-backward. Regexp search keybindings (isearch-forward-regexp and 
isearch-backward-regexp) are C-M-s and C-M-r respectively.

  Over and out,
~Gary

On Wednesday, September 4, 2013 12:24:15 PM UTC-4, Dima Sabanin wrote:
>
> Hi Daniel,
>
> Keep up the great work! I really enjoyed the material and how it's 
> presented.
>
> Thanks,
> Dima
>
>
> On Mon, Sep 2, 2013 at 11:35 AM, Daniel Higginbotham 
> 
> > wrote:
>
>> Hi all,
>>
>> I've been putting together http://www.braveclojure.com/ and would love 
>> feedback. I've tried to make it entertaining and super beginner-friendly.
>>
>> Thanks!
>> Daniel
>>
>> -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>
>
> -- 
> Best regards,
> Dima Sabanin
> http://twitter.com/dimasabanin 
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[redc...@gmail.com]

I also have a vertigo inducing slide deck to go with the robot lightening 
talk (which I didn't end up using) 
http://thelibraryofcongress.s3.amazonaws.com/conj2012-robot/index.html 

On Sunday, September 1, 2013 8:21:46 PM UTC-7, Jeremy Wright wrote:
>
> Here are some updates on my own research.
>
>1. This 
> postis a 
> little over a year old, but has the type of information on the 
>BeagleBone I'm looking for. It covers doing some simple I/O using Clojure. 
>The author states that he's unsure what he's doing on the hardware side of 
>things, but it's a start.
>2. This 
> postsays it's easy 
> to get Clojure working on the Beagleboard, but is a couple 
>of years old and doesn't give too much detail. I do like that the author 
>does some benchmarking that could be adapted to the BeagleBone Black 
> though.
>3. This 
> postis
>  about a year old, and gives a benchmark comparison of OpenJDK vs 
>Oracle's Embedded JRE on a BeagleBone.
>4. Videos of Kevin Downey (less than a year old) showing a robot using 
>Clojure on a BeagleBone. He gives some insight into how to make using the 
>Bone's I/O system in Clojure a little easier.
>1. Video 1 of 3 
>   2. Video 2 of 3 
>   3. Video 3 of 3 
>5. Kevin Downey's Beaglebone robot code on 
> Github
>.
>6. Kevin Downey mentioned 
> clojure-jna which 
>should make working with native code (to do I/O) on the Bone a little 
>easier. The clojure-jna code on GitHub is about 4 years old though, and I 
>may have read something about a newer replacement on this mailing list. I 
>can't remember for sure though.
>
> That's what I've found so far. The information has some age on it and is 
> focused on the older BeagleBone and Beagleboard. It's good information to 
> get started with though I think.
>
> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote:
>>
>> I recently watched Carin Meier's OSCON talk The Joy of Flying Robots 
>> with Clojure  and it made me 
>> wonder about Clojure on embedded systems. A quick search on this list 
>> didn't turn up much so I thought I'd ask. How much work has been done with 
>> Clojure on either Java friendly microcontroller systems (i.e. 
>> Systronix), 
>> or on something like a Beaglebone or Beagleboard? I'm very new to Clojure, 
>> so I don't yet understand the challenges that Clojure would face trying to 
>> run on a system that may not support all the JVM's features.
>>
>> Any thoughts on this? Any links you can give me on what's been/being done?
>>
>> Thanks.
>>
>

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

Building with Java 7 but running on Java 6?

[Tom Emerson]

Greetings,

I develop with JDK 7 but have coworkers who (for reasons I don't want to 
get into) run Java 6, and they cannot run the uberjars I create because of 
the version mismatch. Is it possible for Clojure/Leiningen to generate 
compatible class files? Or do I need to setup a VM that has Java 6 
installed and build the code there?

Thanks in advance,

-tree

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

Re: Building with Java 7 but running on Java 6?

[r0man]

Hi Tom,

add this to your project.clj

:javac-options ["-target" "1.6" "-source" "1.6"]

I have the same problem with our Hadoop cluster ;)

On Wednesday, September 4, 2013 9:45:11 PM UTC+2, Tom Emerson wrote:
>
> Greetings,
>
> I develop with JDK 7 but have coworkers who (for reasons I don't want to 
> get into) run Java 6, and they cannot run the uberjars I create because of 
> the version mismatch. Is it possible for Clojure/Leiningen to generate 
> compatible class files? Or do I need to setup a VM that has Java 6 
> installed and build the code there?
>
> Thanks in advance,
>
> -tree
>
>

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

Re: Screencast: understanding the thread-first and thread-last macros

[Jernau]

> Very clear and easy to follow explanation of Clojure thread macros.
Thanks Mimmo, it's nice to hear that my approach was easy to follow.

> Unfortunately my spoken english is too affected by italian accent :(
As long as you can make yourself understood, I don't see why an accent 
should stop you making a Clojure screencast. If you choose an interesting 
subject, then I know I'd watch it!

But I also agree with your point that more screencasts from the community 
would be great. For me, there's something special about seeing *and*hearing 
somebody explain a subject, which usually elevates it above just 
reading the same content in a book or on a website. (I guess it might have 
something to do with the powerful combination of visual and auditory 
learning.) There are already some great Clojure screencasts out there, but 
it certainly wouldn't hurt the cause to have a few more!

Cheers, 
James

On Wednesday, September 4, 2013 6:24:11 PM UTC+2, Mimmo Cosenza wrote:
>
> Very clear and easy to follow explanation of Clojure thread macros. 
> Highly recommended for Clojure beginners and intermediates.
> We should do a lot more screencasts like this. Unfortunately my spoken 
> english is too affected by italian accent :(
>
> Highly recommended both for clojure beginners and intermediates.
>
> Mimmo
>
> On Sep 4, 2013, at 5:42 PM, Jernau wrote:
>
> Hi everyone,
>
> I made a screencast about Clojure's *thead-first* (->) and *thread-last* 
> (->>) 
> macros:
>
> http://www.youtube.com/watch?v=qxE5wDbt964
>
> If you already have a good understanding of these macros then I'd 
> recommend skipping it, but hopefully newcomers to Clojure might learn 
> something useful.
>
> Cheers, 
> James
>
> -- 
> -- 
> 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/groups/opt_out.
>
>
>

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

Re: hashing binary data

[Brian Craft]

On Wednesday, September 4, 2013 1:53:17 PM UTC-7, Karsten Schmidt wrote:
>
> On 4 September 2013 17:52, Brian Craft > 
> wrote: 
>
> > This gives me a number of reflection warnings, on field ba, on equals, 
> and 
> > on hashCode. I can eliminate the one on hashCode by type hinting the ba 
> > parameter of BAHashable. 
> > 
> > The one on (.ba g) and equals remains. Is there any way to hint these? 
>
> Brian, this seems to work (+ a bit more safe): 
>
> (set! *warn-on-reflection* true) 
>
> (deftype BAHashable [ba] 
>   Object 
>   (equals [this other] 
> (if (instance? BAHashable other) 
>   (java.util.Arrays/equals ^bytes ba ^bytes (.ba ^BAHashable other)) 
>   false)) 
>   (hashCode [this] 
> (java.util.Arrays/hashCode ^bytes ba))) 
> #_=>user.BAHashable 
>
> no more reflcopters! :) 
>


Thanks!

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

Re: Building with Java 7 but running on Java 6?

[Tom Emerson]

This is brilliant, many thanks!

On Wednesday, September 4, 2013 3:52:20 PM UTC-4, r0man wrote:
>
> Hi Tom,
>
> add this to your project.clj
>
> :javac-options ["-target" "1.6" "-source" "1.6"]
>
> I have the same problem with our Hadoop cluster ;)
>
> On Wednesday, September 4, 2013 9:45:11 PM UTC+2, Tom Emerson wrote:
>>
>> Greetings,
>>
>> I develop with JDK 7 but have coworkers who (for reasons I don't want to 
>> get into) run Java 6, and they cannot run the uberjars I create because of 
>> the version mismatch. Is it possible for Clojure/Leiningen to generate 
>> compatible class files? Or do I need to setup a VM that has Java 6 
>> installed and build the code there?
>>
>> Thanks in advance,
>>
>> -tree
>>
>>

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

Re: hashing binary data

[Karsten Schmidt]

On 4 September 2013 17:52, Brian Craft  wrote:

> This gives me a number of reflection warnings, on field ba, on equals, and
> on hashCode. I can eliminate the one on hashCode by type hinting the ba
> parameter of BAHashable.
>
> The one on (.ba g) and equals remains. Is there any way to hint these?

Brian, this seems to work (+ a bit more safe):

(set! *warn-on-reflection* true)

(deftype BAHashable [ba]
  Object
  (equals [this other]
(if (instance? BAHashable other)
  (java.util.Arrays/equals ^bytes ba ^bytes (.ba ^BAHashable other))
  false))
  (hashCode [this]
(java.util.Arrays/hashCode ^bytes ba)))
#_=>user.BAHashable

no more reflcopters! :)

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

Improving a nested if, or How to use multimethods the right way.

[Bruno Kim Medeiros Cesar]

I'm writing (another) basic graph library, and would like to treat inputs
depending on the type of the graph. A graph can be

   - Directed, in which case edges are vectors. Otherwise, edges are sets;
   - Looped, allowing edges from a node to itself;
   - Pseudo (or multi), allowing multiples edges between the same
   endpoints; and
   - Hyper, allowing edges with more than two vertices.

To illustrate better these characteristics you can think of a scientific
publication network as a directed, looped, pseudo-hypergraph. Vertices are
authors, and edges are articles containing multiple researchers (hyper) who
can publish alone (looped). There are multiple articles between the same
researchers (pseudo) and in some contexts author order matters (directed).

Now, I've created a flowchart  to decide if an
edge should be conjed in a graph :edges entry, that leads to the following
straightforward function:
(defn add-edge
  ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
  ([graph edge]
  (if (and (multi? graph) (not= 2 (count edge)))
graph
(if (and (looped? graph) (not (distinct? edge)))
  graph
  (let [e (if (directed? edge) (vec edge) (set edge))]
(update-in graph [:edges] conj e))

That looks ugly and a pattern that could propagate in a codebase. So I
tried to factor out multimethods from it, and ended with the following:

(defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
(defmulti ^:private add-edge1 (fn [g e] (looped? g)))
(defmulti ^:private add-edge2 (fn [g e] (directed? g)))
(defn ^:private add-edge3 [g e]
  (update-in g [:edges] conj e))

(defmethod add-edge0 :hyper [g e] (add-edge1 g e))
(defmethod add-edge0 :default [g e] (if (= 2 (count e))
  (add-edge1 g e)
  g))
(defmethod add-edge1 :looped  [g e] (add-edge2 g e))
(defmethod add-edge1 :default [g e] (if (distinct? e)
  (add-edge2 g e)
   g))
(defmethod add-edge2 :directed [g e] (add-edge3 g (vec e)))
(defmethod add-edge2 :default  [g e] (add-edge3 g (set e)))

(defn add-edge
  ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
  ([g edge]   (add-edge0 g edge)))

That doesn't look much better, as the amount of boilerplate increased, but
at least the concerns for each type are separated.

Do you have any suggestions on how to improve this design? Thanks for any
consideration!

Bruno Kim Medeiros Cesar
Engenheiro de Computação
Pesquisador em Redes Complexas
www.brunokim.com.br

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

Re: [ANN] riddley: code-walking without caveats

[Zach Tellman]

I guess I'm confused, then.  You contrast "complete recursive expansion"
with what the compiler does, and then say it's recursive prewalk expansion,
which is exactly what the compiler does.  Can you clarify the difference
between what you're doing and what the compiler does?


On Wed, Sep 4, 2013 at 11:54 AM, Konrad Hinsen <
googlegro...@khinsen.fastmail.net> wrote:

> --On 4 septembre 2013 09:27:12 -0700 Zach Tellman 
> wrote:
>
>  So "complete recursive expansion" is postwalk macroexpansion?  It seems
>> like that could break anaphoric macros, and likely others.  A macro has
>> the option of calling macroexpand-all on its own contents if it wants
>> only special forms, but it shouldn't be forced to take only special forms.
>>
>
> Recursive macro expansion still works from outside in, so each macro gets
> to see the unexpanded form. It's only after the macro has done its
> transformation that the inner forms get expanded.
>
>
>  Also, here's a sketch of how you could do symbol macros using
>> Riddley: 
>> https://gist.github.**com/ztellman/6439318.
>>  Please let me know
>> if I'm missing something w.r.t. how symbol macros are done in
>> tools.macros.
>>
>
> It's on my reading list for tomorrow!
>
>
> Konrad.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/**
> topic/clojure/a68aThpvP4o/**unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>

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

Re: Clojure On Java Friendly Microcontrollers, Beaglebone, etc

[Jeremy Wright]

Thanks for the slide deck Kevin. I'm not sure I've found all the slides 
yet, but it's great information. Do you have any links or information on 
Clojure robotics work you've done since the 2012 Conj? Any thoughts on 
using the GPIO pins through the file system versus using I2C (or maybe SPI)?

On Wednesday, September 4, 2013 3:59:33 PM UTC-4, red...@gmail.com wrote:
>
> I also have a vertigo inducing slide deck to go with the robot lightening 
> talk (which I didn't end up using) 
> http://thelibraryofcongress.s3.amazonaws.com/conj2012-robot/index.html 
>
> On Sunday, September 1, 2013 8:21:46 PM UTC-7, Jeremy Wright wrote:
>>
>> Here are some updates on my own research.
>>
>>1. This 
>> postis a 
>> little over a year old, but has the type of information on the 
>>BeagleBone I'm looking for. It covers doing some simple I/O using 
>> Clojure. 
>>The author states that he's unsure what he's doing on the hardware side 
>> of 
>>things, but it's a start.
>>2. This 
>> postsays it's 
>> easy to get Clojure working on the Beagleboard, but is a couple 
>>of years old and doesn't give too much detail. I do like that the author 
>>does some benchmarking that could be adapted to the BeagleBone Black 
>> though.
>>3. This 
>> postis
>>  about a year old, and gives a benchmark comparison of OpenJDK vs 
>>Oracle's Embedded JRE on a BeagleBone.
>>4. Videos of Kevin Downey (less than a year old) showing a robot 
>>using Clojure on a BeagleBone. He gives some insight into how to make 
>> using 
>>the Bone's I/O system in Clojure a little easier.
>>1. Video 1 of 3 
>>   2. Video 2 of 3 
>>   3. Video 3 of 3 
>>5. Kevin Downey's Beaglebone robot code on 
>> Github
>>.
>>6. Kevin Downey mentioned 
>> clojure-jna which 
>>should make working with native code (to do I/O) on the Bone a little 
>>easier. The clojure-jna code on GitHub is about 4 years old though, and I 
>>may have read something about a newer replacement on this mailing list. I 
>>can't remember for sure though.
>>
>> That's what I've found so far. The information has some age on it and is 
>> focused on the older BeagleBone and Beagleboard. It's good information to 
>> get started with though I think.
>>
>> On Saturday, August 31, 2013 11:13:59 PM UTC-4, Jeremy Wright wrote:
>>>
>>> I recently watched Carin Meier's OSCON talk The Joy of Flying Robots 
>>> with Clojure  and it made 
>>> me wonder about Clojure on embedded systems. A quick search on this list 
>>> didn't turn up much so I thought I'd ask. How much work has been done with 
>>> Clojure on either Java friendly microcontroller systems (i.e. 
>>> Systronix), 
>>> or on something like a Beaglebone or Beagleboard? I'm very new to Clojure, 
>>> so I don't yet understand the challenges that Clojure would face trying to 
>>> run on a system that may not support all the JVM's features.
>>>
>>> Any thoughts on this? Any links you can give me on what's been/being 
>>> done?
>>>
>>> Thanks.
>>>
>>

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

Re: Improving a nested if, or How to use multimethods the right way.

[Leonardo Borges]

You could use pattern matching with core.match
On 05/09/2013 6:57 AM, "Bruno Kim Medeiros Cesar" 
wrote:

> I'm writing (another) basic graph library, and would like to treat inputs
> depending on the type of the graph. A graph can be
>
>- Directed, in which case edges are vectors. Otherwise, edges are sets;
>- Looped, allowing edges from a node to itself;
>- Pseudo (or multi), allowing multiples edges between the same
>endpoints; and
>- Hyper, allowing edges with more than two vertices.
>
> To illustrate better these characteristics you can think of a scientific
> publication network as a directed, looped, pseudo-hypergraph. Vertices are
> authors, and edges are articles containing multiple researchers (hyper) who
> can publish alone (looped). There are multiple articles between the same
> researchers (pseudo) and in some contexts author order matters (directed).
>
> Now, I've created a flowchart  to decide if an
> edge should be conjed in a graph :edges entry, that leads to the following
> straightforward function:
> (defn add-edge
>   ([graph v1 v2 & vs] (add-edge graph (concat [v1 v2] vs)))
>   ([graph edge]
>   (if (and (multi? graph) (not= 2 (count edge)))
> graph
> (if (and (looped? graph) (not (distinct? edge)))
>   graph
>   (let [e (if (directed? edge) (vec edge) (set edge))]
> (update-in graph [:edges] conj e))
>
> That looks ugly and a pattern that could propagate in a codebase. So I
> tried to factor out multimethods from it, and ended with the following:
>
> (defmulti ^:private add-edge0 (fn [g e] (hyper? g)))
> (defmulti ^:private add-edge1 (fn [g e] (looped? g)))
> (defmulti ^:private add-edge2 (fn [g e] (directed? g)))
> (defn ^:private add-edge3 [g e]
>   (update-in g [:edges] conj e))
>
> (defmethod add-edge0 :hyper [g e] (add-edge1 g e))
> (defmethod add-edge0 :default [g e] (if (= 2 (count e))
>   (add-edge1 g e)
>   g))
> (defmethod add-edge1 :looped  [g e] (add-edge2 g e))
> (defmethod add-edge1 :default [g e] (if (distinct? e)
>   (add-edge2 g e)
>g))
> (defmethod add-edge2 :directed [g e] (add-edge3 g (vec e)))
> (defmethod add-edge2 :default  [g e] (add-edge3 g (set e)))
>
> (defn add-edge
>   ([g v1 v2 & vs] (add-edge g (concat [v1 v2] vs)))
>   ([g edge]   (add-edge0 g edge)))
>
> That doesn't look much better, as the amount of boilerplate increased, but
> at least the concerns for each type are separated.
>
> Do you have any suggestions on how to improve this design? Thanks for any
> consideration!
>
> Bruno Kim Medeiros Cesar
> Engenheiro de Computação
> Pesquisador em Redes Complexas
> www.brunokim.com.br
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Clojure for the Brave and True, an online book for beginners

[Daniel Higginbotham]

Thanks for the feedback, Dima and Gary! It's very encouraging.

With the C-s/C-r keybindings, I think the emacs.d I point has swapped 
isearch and regexp search. I'll double-check that.

Thanks,
Daniel

On Wednesday, September 4, 2013 2:58:54 PM UTC-4, Gary Johnson wrote:
>
> Looks pretty solid. Great work so far.
>
> Also +1 for the Emacs coverage. Despite the fact that our surveys still 
> show the majority of Clojure users develop in Emacs, this mailing list 
> frequently exhibits an anything-but-Emacs tone. By all means add links to 
> other editors for folks who are already using something else, but I for one 
> think you made a smart choice there. Better to learn Emacs now than to 
> learn it later after trying two or three other editors that don't quite cut 
> it.
>
> Also, just a quick note, your Emacs search keybindings were incorrect in 
> that chapter. C-s and C-r are just regular isearch-forward and 
> isearch-backward. Regexp search keybindings (isearch-forward-regexp and 
> isearch-backward-regexp) are C-M-s and C-M-r respectively.
>
>   Over and out,
> ~Gary
>
> On Wednesday, September 4, 2013 12:24:15 PM UTC-4, Dima Sabanin wrote:
>>
>> Hi Daniel,
>>
>> Keep up the great work! I really enjoyed the material and how it's 
>> presented.
>>
>> Thanks,
>> Dima
>>
>>
>> On Mon, Sep 2, 2013 at 11:35 AM, Daniel Higginbotham > > wrote:
>>
>>> Hi all,
>>>
>>> I've been putting together http://www.braveclojure.com/ and would love 
>>> feedback. I've tried to make it entertaining and super beginner-friendly.
>>>
>>> Thanks!
>>> Daniel
>>>
>>> -- 
>>> -- 
>>> 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/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> Best regards,
>> Dima Sabanin
>> http://twitter.com/dimasabanin 
>>
>

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

Why is clojure so powerful?

[Tomislav Tomšić]

 

I suspect, there are numerous possible ways to answer that question. One 
can ignore it, others would care to offer superficial, "no it isn't", but I 
guess, few would answer, it is because clojure is the member of the Lisp 
family of programming languages. Which immediately invites predictable 
question.


 Why is Lisp so powerful?

I guesstimate, there are three possible responses on that question. One is 
to ignore it, second one is to take it as encouragement for further 
inquiry, and the third one is to say something along the following lines: 
“It is because of the lists, dummy. Lisp is built on lists.”


Very well then, why are lists so powerful?


Yes, there is answer(s), but as I hope we all know, every answer opens the 
door for new questions and problems. In other words, we have an, hopefully 
clear and self-understandable, answer to why is Lisp so powerful, but we 
are now facing numerous, previously unimaginable choices and opportunities 
to improve Lisp further, which is the reason why I am putting this message 
here, in the group dedicated to the new and continually improving member of 
Lisp programming family.


I hope to solve and clarify as many as I can, but it demands time and other 
resources, which is why I decided to put answer(s) and reasons for them in 
a book. It is called “Arrogance of Abstraction”, and it is available 
through Amazon. Amazon allows, even encourages authors, to put an effort to 
contact audience. In other words, it will be available for free download 
from Amazon at following days this month: 2013-09-08 and 2013-09-13. I 
haven't decided yet at what other days will be available for download. If 
you have an advice, feel free to put it here.


Thank you for your patience

Tomislav Tomsic

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

Re: Why is clojure so powerful?

[Devin Walters]

Battle-tested libraries are nice, and Java has a lot of them. Clojure 
programmers can use all of them with relative ease. I recently tried 
Erlang/Elixir and was disappointed in the library ecosystem.

Another answer to why Clojure is powerful is the company it keeps. The people 
who work on Clojure and its ecosystem (libraries, build tools, blog posts, 
screencasts, podcasts, conferences, etc.) are a wonderful group of people who 
have never ceased to amaze me. The creativity, engineering, and generosity. In 
my life I've seldom been a part of such a vibrant and inspiring community.

I struggle to tap this into my phone without more evidence to support it, but 
it seems to me that Lisps just seem to attract the right kind of people. Take 
that on faith or not at all, but I struggle to find a better explanation. The 
technical explanations are all well and good, but "It's the people, stupid." 
seems like the best answer I can come up with.

On Sep 4, 2013, at 4:32 PM, Tomislav Tomšić  wrote:

> I suspect, there are numerous possible ways to answer that question. One can 
> ignore it, others would care to offer superficial, "no it isn't", but I 
> guess, few would answer, it is because clojure is the member of the Lisp 
> family of programming languages. Which immediately invites predictable 
> question.
> 
> Why is Lisp so powerful?
> I guesstimate, there are three possible responses on that question. One is to 
> ignore it, second one is to take it as encouragement for further inquiry, and 
> the third one is to say something along the following lines: “It is because 
> of the lists, dummy. Lisp is built on lists.”
> 
> Very well then, why are lists so powerful?
> 
> Yes, there is answer(s), but as I hope we all know, every answer opens the 
> door for new questions and problems. In other words, we have an, hopefully 
> clear and self-understandable, answer to why is Lisp so powerful, but we are 
> now facing numerous, previously unimaginable choices and opportunities to 
> improve Lisp further, which is the reason why I am putting this message here, 
> in the group dedicated to the new and continually improving member of Lisp 
> programming family.
> 
> I hope to solve and clarify as many as I can, but it demands time and other 
> resources, which is why I decided to put answer(s) and reasons for them in a 
> book. It is called “Arrogance of Abstraction”, and it is available through 
> Amazon. Amazon allows, even encourages authors, to put an effort to contact 
> audience. In other words, it will be available for free download from Amazon 
> at following days this month: 2013-09-08 and 2013-09-13. I haven't decided 
> yet at what other days will be available for download. If you have an advice, 
> feel free to put it here.
> 
> Thank you for your patience
> Tomislav Tomsic
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Screencast: understanding the thread-first and thread-last macros

[Curtis Gagliardi]

This is a pretty good demo of light table as well for people who haven't 
really been keeping up with it lately.  
On Wednesday, September 4, 2013 8:42:06 AM UTC-7, Jernau wrote:
>
> Hi everyone,
>
> I made a screencast about Clojure's *thead-first* (->) and *thread-last* 
> (->>) 
> macros:
>
> http://www.youtube.com/watch?v=qxE5wDbt964
>
> If you already have a good understanding of these macros then I'd 
> recommend skipping it, but hopefully newcomers to Clojure might learn 
> something useful.
>
> Cheers, 
> 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/groups/opt_out.

Handling name collisions with clojure.core

[Mikera]

Hi all,

While building the API for core.matrix, I've fun into a few cases where the 
"best" name is a direct clash with clojure.core.

Examples are "+", "zero?", "vector?", "=="

In many of these cases, the core.matrix behaviour is a natural extension of 
the clojure.core function (i.e. it extends the same functionality to 
arbitrary N-dimensional arrays). 

I'm not very happy with any of the options I can see for handling this:

A) Use the good names in the "clojure.core.matrix" namespace. Problem: that 
gives you a ton of nasty warnings of the type "WARNING: + already refers 
to: #'clojure.core/+ in namespace: test.blank, being replaced by: 
#'clojure.core.matrix/+". Significant boilerplate must be maintained by the 
user in their ns declaration to prevent these warnings. I don't like 
forcing users to maintain boilerplate, and I think that normal idiomatic 
usage should be warning-free.

B) Separate the name-clashing functions into separate namespaces - e.g. 
"clojure.core.matrix.operators". Problem: that's something of an artificial 
division, and again it forces users to do extra ns-management work to 
access the functions they want.

C) Use different names. Problem: names would be worse, and this would be 
inconsistent and confusing, especially for functions that do effectively 
the same thing.

D) Encourage users to use aliases. Problem: that's horrendously ugly and 
inconvenient for numerical code. Users with any sense of elegance in their 
coding style would quite rightly throw their hands up in disgust. 

Currently we're doing B), I'd prefer to do A) but can't figure out a way to 
automatically suppress the warnings.

Any better ideas?



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

Re: Handling name collisions with clojure.core

[Zach Tellman]

It is probably instructive to look at how (use-primitive-operators) works 
in primitive-math [1], though maybe not something you want to emulate.  The 
basic mechanism is pretty simple: use 'ns-unmap' to get rid of the 
operators you want to shadow, and bring in the operators from the alternate 
namespace.

Unfortunately, the next time you load the namespace, you'll get the same 
mess of collision warnings you were trying to avoid, because you haven't 
added the ':refer-clojure :exclude' clause to the ns declaration.  To get 
around this, use-primitive-operator hijacks 'ns' via alter-var-root so that 
this is automatically added if the alternate operators are detected [2], 
but otherwise leaves it unchanged.  This hijacking is undone if 
clojure.core is ever reloaded (usually by a :reload-all somewhere), 
however.  This could be fixed by adding a watcher to #'clojure.core/ns and 
forcing it back whenever it changes, but I haven't done that yet because it 
doesn't really affect me, and it feels hokey enough already.

Despite all that, though, it works pretty well.  Feel free to use this 
approach if you like, or create a less questionable variant if you can 
think of one.

Zach

[1] 
https://github.com/ztellman/primitive-math/blob/master/src/primitive_math.clj#L154
[2] 
https://github.com/ztellman/primitive-math/blob/master/src/primitive_math.clj#L135

On Wednesday, September 4, 2013 6:22:08 PM UTC-7, Mikera wrote:
>
> Hi all,
>
> While building the API for core.matrix, I've fun into a few cases where 
> the "best" name is a direct clash with clojure.core.
>
> Examples are "+", "zero?", "vector?", "=="
>
> In many of these cases, the core.matrix behaviour is a natural extension 
> of the clojure.core function (i.e. it extends the same functionality to 
> arbitrary N-dimensional arrays). 
>
> I'm not very happy with any of the options I can see for handling this:
>
> A) Use the good names in the "clojure.core.matrix" namespace. Problem: 
> that gives you a ton of nasty warnings of the type "WARNING: + already 
> refers to: #'clojure.core/+ in namespace: test.blank, being replaced by: 
> #'clojure.core.matrix/+". Significant boilerplate must be maintained by the 
> user in their ns declaration to prevent these warnings. I don't like 
> forcing users to maintain boilerplate, and I think that normal idiomatic 
> usage should be warning-free.
>
> B) Separate the name-clashing functions into separate namespaces - e.g. 
> "clojure.core.matrix.operators". Problem: that's something of an artificial 
> division, and again it forces users to do extra ns-management work to 
> access the functions they want.
>
> C) Use different names. Problem: names would be worse, and this would be 
> inconsistent and confusing, especially for functions that do effectively 
> the same thing.
>
> D) Encourage users to use aliases. Problem: that's horrendously ugly and 
> inconvenient for numerical code. Users with any sense of elegance in their 
> coding style would quite rightly throw their hands up in disgust. 
>
> Currently we're doing B), I'd prefer to do A) but can't figure out a way 
> to automatically suppress the warnings.
>
> Any better ideas?
>
>
>
>

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

Re: Handling name collisions with clojure.core

[Mikera]

Hmmm clever trick. I hadn't thought about hijacking "ns" :-)

Still, it's a colossal hack. Monkey patching always makes me feel uneasy.

Perhaps Clojure itself needs patching to make this use case a bit more 
palatable? Some obvious options:
- Turn off all warnings for symbol replacement by default.
- Allow ^:ns-replace metadata for library functions that are intended to 
replace existing symbols (which would suppress warnings). You'd still get 
warnings on unintentional replacement, but it would allow library authors 
to make everything work smoothly when it is desired.

On Thursday, 5 September 2013 10:42:56 UTC+8, Zach Tellman wrote:
>
> It is probably instructive to look at how (use-primitive-operators) works 
> in primitive-math [1], though maybe not something you want to emulate.  The 
> basic mechanism is pretty simple: use 'ns-unmap' to get rid of the 
> operators you want to shadow, and bring in the operators from the alternate 
> namespace.
>
> Unfortunately, the next time you load the namespace, you'll get the same 
> mess of collision warnings you were trying to avoid, because you haven't 
> added the ':refer-clojure :exclude' clause to the ns declaration.  To get 
> around this, use-primitive-operator hijacks 'ns' via alter-var-root so that 
> this is automatically added if the alternate operators are detected [2], 
> but otherwise leaves it unchanged.  This hijacking is undone if 
> clojure.core is ever reloaded (usually by a :reload-all somewhere), 
> however.  This could be fixed by adding a watcher to #'clojure.core/ns and 
> forcing it back whenever it changes, but I haven't done that yet because it 
> doesn't really affect me, and it feels hokey enough already.
>
> Despite all that, though, it works pretty well.  Feel free to use this 
> approach if you like, or create a less questionable variant if you can 
> think of one.
>
> Zach
>
> [1] 
> https://github.com/ztellman/primitive-math/blob/master/src/primitive_math.clj#L154
> [2] 
> https://github.com/ztellman/primitive-math/blob/master/src/primitive_math.clj#L135
>
> On Wednesday, September 4, 2013 6:22:08 PM UTC-7, Mikera wrote:
>>
>> Hi all,
>>
>> While building the API for core.matrix, I've fun into a few cases where 
>> the "best" name is a direct clash with clojure.core.
>>
>> Examples are "+", "zero?", "vector?", "=="
>>
>> In many of these cases, the core.matrix behaviour is a natural extension 
>> of the clojure.core function (i.e. it extends the same functionality to 
>> arbitrary N-dimensional arrays). 
>>
>> I'm not very happy with any of the options I can see for handling this:
>>
>> A) Use the good names in the "clojure.core.matrix" namespace. Problem: 
>> that gives you a ton of nasty warnings of the type "WARNING: + already 
>> refers to: #'clojure.core/+ in namespace: test.blank, being replaced by: 
>> #'clojure.core.matrix/+". Significant boilerplate must be maintained by the 
>> user in their ns declaration to prevent these warnings. I don't like 
>> forcing users to maintain boilerplate, and I think that normal idiomatic 
>> usage should be warning-free.
>>
>> B) Separate the name-clashing functions into separate namespaces - e.g. 
>> "clojure.core.matrix.operators". Problem: that's something of an artificial 
>> division, and again it forces users to do extra ns-management work to 
>> access the functions they want.
>>
>> C) Use different names. Problem: names would be worse, and this would be 
>> inconsistent and confusing, especially for functions that do effectively 
>> the same thing.
>>
>> D) Encourage users to use aliases. Problem: that's horrendously ugly and 
>> inconvenient for numerical code. Users with any sense of elegance in their 
>> coding style would quite rightly throw their hands up in disgust. 
>>
>> Currently we're doing B), I'd prefer to do A) but can't figure out a way 
>> to automatically suppress the warnings.
>>
>> Any better ideas?
>>
>>
>>
>>

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

Why does this overflow? (a try at the sieve of Eratosthenes)

[John Gabriele]

I tried implementing the sieve of Eratosthenes in Clojure. The approach is 
to loop while (A) keeping my current list of numbers which have not yet 
been eliminated, and (B) keeping track of the number I'm "on" (checking for 
multiples thereof).

Here's what I came up with (in a foo.clj file):

~~~clojure
(declare remove-multiples-of)
(declare next-one-after)

(defn main
  [max-num]
  (let [starting-nums (range 2 max-num)]
(loop [new-nums (remove-multiples-of 2 starting-nums)
   new-num  (next-one-after 2 new-nums)]
  (if (or (nil? new-num)
  (> new-num (* 0.5 max-num)))
new-nums
(recur (remove-multiples-of new-num new-nums)
   (next-one-after new-num new-nums))

(defn remove-multiples-of
  "Removes all multiples of n (but not $n * 1$) from xs."
  [n xs]
  (remove (fn [x] (and (> x n)
   (zero? (rem x n
  xs))

(defn next-one-after
  "It's assumed that xs is an ordered sequential collection of positive
integers, and that n is among xs. Returns the element right after n, unless
n is the last element --- if that's the case, just returns nil."
  [n xs]
  (second (drop-while (fn [x]
(not= x n))
  xs)))

;;---
(println (last (main 5000)))
~~~

Running that (via `lein exec foo.clj`), it appears to work.

However, if I change that 5000 to 5, I get a long disapproving-looking 
stack trace starting with java.lang.StackOverflowError. Why is it 
overflowing?

Thanks!

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

I am trying to use lein uberjar to package as jar file that can be executed. but it's not working for another library is not contained.

[Rooney]

The another library is just jar file what used to use at java.

the following is my project file.

the red part is problem that is not contained from jar file when i use lein 
uberjar command.

(defproject make-sentence "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
 [org.clojure/java.jdbc "0.0.6"]
 [org.xerial/sqlite-jdbc "3.7.2"]
 [seesaw "1.2.2"]]
  :plugins [[lein-swank "1.4.4"]
[lein-localrepo "0.5.2"]]
  :java-source-paths ["java"]
*  :resource-paths ["resource/simmetrics_jar_v1_6_2_d07_02_07.jar"]*
  :main make-sentence.core
  )


How can i solve?

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

Re: Handling name collisions with clojure.core

[Sean Corfield]

You only get the warning if you 'use' the namespace or 'refer all'
tho', correct?

And we've recently seen a lot of discussion that basically says "don't
do that" so it seems that either users of core.matric are going to
have two "approved" choices:
* require core.matrix with an alias, or choose to rename colliding
names however you want
* exclude the colliding symbols via refer-clojure and require them
from core.matrix as referred symbols

That's seems right to me: it is explicit and provides no surprises; it
gives the user control over how to manage things.

Sean

On Wed, Sep 4, 2013 at 6:22 PM, Mikera  wrote:
> Hi all,
>
> While building the API for core.matrix, I've fun into a few cases where the
> "best" name is a direct clash with clojure.core.
>
> Examples are "+", "zero?", "vector?", "=="
>
> In many of these cases, the core.matrix behaviour is a natural extension of
> the clojure.core function (i.e. it extends the same functionality to
> arbitrary N-dimensional arrays).
>
> I'm not very happy with any of the options I can see for handling this:
>
> A) Use the good names in the "clojure.core.matrix" namespace. Problem: that
> gives you a ton of nasty warnings of the type "WARNING: + already refers to:
> #'clojure.core/+ in namespace: test.blank, being replaced by:
> #'clojure.core.matrix/+". Significant boilerplate must be maintained by the
> user in their ns declaration to prevent these warnings. I don't like forcing
> users to maintain boilerplate, and I think that normal idiomatic usage
> should be warning-free.
>
> B) Separate the name-clashing functions into separate namespaces - e.g.
> "clojure.core.matrix.operators". Problem: that's something of an artificial
> division, and again it forces users to do extra ns-management work to access
> the functions they want.
>
> C) Use different names. Problem: names would be worse, and this would be
> inconsistent and confusing, especially for functions that do effectively the
> same thing.
>
> D) Encourage users to use aliases. Problem: that's horrendously ugly and
> inconvenient for numerical code. Users with any sense of elegance in their
> coding style would quite rightly throw their hands up in disgust.
>
> Currently we're doing B), I'd prefer to do A) but can't figure out a way to
> automatically suppress the warnings.
>
> Any better ideas?
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: Handling name collisions with clojure.core

[Dave Ray]

Maybe this is a dumb idea, but could you have a macro that rewrites code to
use your ops?

  (require '[clojure.core.matrix :as m])
  (m/with-ops (+ ... (* ...) ...))

and then all the "special" symbols get rewritten/qualified with
clojure.core.matrix?

Dave



On Wed, Sep 4, 2013 at 10:26 PM, Sean Corfield wrote:

> You only get the warning if you 'use' the namespace or 'refer all'
> tho', correct?
>
> And we've recently seen a lot of discussion that basically says "don't
> do that" so it seems that either users of core.matric are going to
> have two "approved" choices:
> * require core.matrix with an alias, or choose to rename colliding
> names however you want
> * exclude the colliding symbols via refer-clojure and require them
> from core.matrix as referred symbols
>
> That's seems right to me: it is explicit and provides no surprises; it
> gives the user control over how to manage things.
>
> Sean
>
> On Wed, Sep 4, 2013 at 6:22 PM, Mikera 
> wrote:
> > Hi all,
> >
> > While building the API for core.matrix, I've fun into a few cases where
> the
> > "best" name is a direct clash with clojure.core.
> >
> > Examples are "+", "zero?", "vector?", "=="
> >
> > In many of these cases, the core.matrix behaviour is a natural extension
> of
> > the clojure.core function (i.e. it extends the same functionality to
> > arbitrary N-dimensional arrays).
> >
> > I'm not very happy with any of the options I can see for handling this:
> >
> > A) Use the good names in the "clojure.core.matrix" namespace. Problem:
> that
> > gives you a ton of nasty warnings of the type "WARNING: + already refers
> to:
> > #'clojure.core/+ in namespace: test.blank, being replaced by:
> > #'clojure.core.matrix/+". Significant boilerplate must be maintained by
> the
> > user in their ns declaration to prevent these warnings. I don't like
> forcing
> > users to maintain boilerplate, and I think that normal idiomatic usage
> > should be warning-free.
> >
> > B) Separate the name-clashing functions into separate namespaces - e.g.
> > "clojure.core.matrix.operators". Problem: that's something of an
> artificial
> > division, and again it forces users to do extra ns-management work to
> access
> > the functions they want.
> >
> > C) Use different names. Problem: names would be worse, and this would be
> > inconsistent and confusing, especially for functions that do effectively
> the
> > same thing.
> >
> > D) Encourage users to use aliases. Problem: that's horrendously ugly and
> > inconvenient for numerical code. Users with any sense of elegance in
> their
> > coding style would quite rightly throw their hands up in disgust.
> >
> > Currently we're doing B), I'd prefer to do A) but can't figure out a way
> to
> > automatically suppress the warnings.
> >
> > Any better ideas?
> >
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: I am trying to use lein uberjar to package as jar file that can be executed. but it's not working for another library is not contained.

[Alan Busby]

This isn't the solution you were looking for, but it should work;

1. Add simmetrics to your local maven repo;
$ mvn install:install-file
-Dfile=*simmetrics_jar_v1_6_2_d07_02_07.jar* -DgroupId=simmetrics
-DartifactId=simmetrics -Dversion=1.6.2 -Dpackaging=jar -DgeneratePom=true

2. Refer to it in :dependencies of your project.clj file;
[simmetrics/simmetrics "1.6.2"]

3. Done :)
lein uberjar


On Thu, Sep 5, 2013 at 1:20 PM, Rooney  wrote:

> The another library is just jar file what used to use at java.
>
> the following is my project file.
>
> the red part is problem that is not contained from jar file when i use
> lein uberjar command.
>
> (defproject make-sentence "0.1.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :url "http://example.com/FIXME";
>   :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
>   :dependencies [[org.clojure/clojure "1.5.1"]
>  [org.clojure/java.jdbc "0.0.6"]
>  [org.xerial/sqlite-jdbc "3.7.2"]
>  [seesaw "1.2.2"]]
>   :plugins [[lein-swank "1.4.4"]
> [lein-localrepo "0.5.2"]]
>   :java-source-paths ["java"]
> *  :resource-paths ["resource/simmetrics_jar_v1_6_2_d07_02_07.jar"]*
>   :main make-sentence.core
>   )
>
>
> How can i solve?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

let bindings in tree-seq funciton

[Kuba Roth]

I'm currently working with tree-seq function from clojure.core and there is 
one thing I'm struggling to understand... Could you please explain why 
pretty much all of the body of the function sits within 'let binding' and 
not in the 'let body' where only (walk root) is placed?
Has it something to do with tail recursion?

Thank you,
Kuba

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

Re: Handling name collisions with clojure.core

[Alan Busby]

On Thu, Sep 5, 2013 at 2:35 PM, Dave Ray  wrote:

> could you have a macro that rewrites code to use your ops?
>
>   (require '[clojure.core.matrix :as m])
>   (m/with-ops (+ ... (* ...) ...))


I wonder if there is value in a more general (with-ns clojure.core.matrix
(foo (bar ...))) macro?
I can imagine a couple cases where I could use something like that.

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

Re: Handling name collisions with clojure.core

[Mikera]

On Thursday, 5 September 2013 13:26:28 UTC+8, Sean Corfield wrote:

> You only get the warning if you 'use' the namespace or 'refer all' 
> tho', correct? 
>
> And we've recently seen a lot of discussion that basically says "don't 
> do that" so it seems that either users of core.matric are going to 
> have two "approved" choices: 
> * require core.matrix with an alias, or choose to rename colliding 
> names however you want 
>
* exclude the colliding symbols via refer-clojure and require them 
> from core.matrix as referred symbols 
>
>
I remember the debates :-) and I don't think there was anything like a 
consensus that "don't do that" is the right answer. 

In particular note that neither "approved" choice is very nice for users:
- Aliases are pretty ugly for various DSL type situations. For numerical 
matrix code, it's really helpful to be able to write straightforward code 
without aliases e.g. (- R (+ M (* A x) (/ B y))) or similar. The equivalent 
with aliases is pretty unreadable by comparison.
- Manually excluding colliding symbols is just boilerplate to maintain. ns 
declarations are already complex/verbose enough, and we don't even have the 
tool support yet that makes this automatic in the way that Java does.
  
If there is a choice between improving the way that Clojure works or 
forcing extra inconveniences on users, I believe that we should choose the 
former every time.
 

> That's seems right to me: it is explicit and provides no surprises; it 
> gives the user control over how to manage things. 
>

I'm not against giving the user control. I just think the default behaviour 
should be super-friendly and not spit out warnings.

And in my view (:use clojure.core.matrix) is already being very explicit: 
our user wants to write numerical code in this namespace, and would like to 
have all the relevant functions available :-) 
 

>
> Sean 
>
> On Wed, Sep 4, 2013 at 6:22 PM, Mikera > 
> wrote: 
> > Hi all, 
> > 
> > While building the API for core.matrix, I've fun into a few cases where 
> the 
> > "best" name is a direct clash with clojure.core. 
> > 
> > Examples are "+", "zero?", "vector?", "==" 
> > 
> > In many of these cases, the core.matrix behaviour is a natural extension 
> of 
> > the clojure.core function (i.e. it extends the same functionality to 
> > arbitrary N-dimensional arrays). 
> > 
> > I'm not very happy with any of the options I can see for handling this: 
> > 
> > A) Use the good names in the "clojure.core.matrix" namespace. Problem: 
> that 
> > gives you a ton of nasty warnings of the type "WARNING: + already refers 
> to: 
> > #'clojure.core/+ in namespace: test.blank, being replaced by: 
> > #'clojure.core.matrix/+". Significant boilerplate must be maintained by 
> the 
> > user in their ns declaration to prevent these warnings. I don't like 
> forcing 
> > users to maintain boilerplate, and I think that normal idiomatic usage 
> > should be warning-free. 
> > 
> > B) Separate the name-clashing functions into separate namespaces - e.g. 
> > "clojure.core.matrix.operators". Problem: that's something of an 
> artificial 
> > division, and again it forces users to do extra ns-management work to 
> access 
> > the functions they want. 
> > 
> > C) Use different names. Problem: names would be worse, and this would be 
> > inconsistent and confusing, especially for functions that do effectively 
> the 
> > same thing. 
> > 
> > D) Encourage users to use aliases. Problem: that's horrendously ugly and 
> > inconvenient for numerical code. Users with any sense of elegance in 
> their 
> > coding style would quite rightly throw their hands up in disgust. 
> > 
> > Currently we're doing B), I'd prefer to do A) but can't figure out a way 
> to 
> > automatically suppress the warnings. 
> > 
> > Any better ideas? 
> > 
> > 
> > 
> > -- 
> > -- 
> > 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/groups/opt_out. 
>
>
>
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure