EDN for Objective-C (iOS/OS X)

[Matthew Phillips]

Hello,

a quick search of this group, and the web at large, doesn't get any hits 
for an Obj-C EDN implementation. Is there anyone working on this?

If not, I'll likely go ahead and implement a basic subset of the EDN spec 
for my own needs, which I'd be happy to share.

Cheers,

Matthew.

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

[Lee Spector]

On Feb 5, 2013, at 12:15 AM, Rich Morin wrote:

> On Feb 4, 2013, at 19:49, deliminator wrote:
>> Long story short: want more people to love lisp?
>> Implement paredit for more editors.
> 
> +1!

-1

Just another data point and YMMV, but I've long loved Lisp and long hated 
paredit. I do agree, however, that editor features are key. For me, what makes 
the difference is bracket/parentheses *matching* (showing what matches what, 
but not typing for me) and good auto-reindentation. In my experience those 
features make it so obvious what the code structure is that it's simple to keep 
things balanced correctly. Paredit, however, goes too far by thinking it knows 
more than I do about what I want to type when, and gets in the way when I want 
to type my ideas in a weird order and/or cut/paste unbalanced things, which I 
basically do continuously.

FWIW I also teach new programmers Lisp with some regularity, and I don't get 
the sense that parentheses are ever a big issue (in the context of the editors 
that I provide, which always have bracket matching and auto-reindentation -- 
yes, it' d be great for those to be more ubiquitous). On the other hand, 
defeating students' existing typing/cutting/pasting habits, or making them deal 
with emacs arcana: problems.

Again, YMMV!

 -Lee

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

[Sung Pae]

On Sat, Feb 02, 2013 at 06:28:09PM -0800, Alexandros Bantis wrote:

> Hello all. I'm working through the Project Euler problems in Java,
> Scala, & Clojure (trying to learn all three?!?). I notice that for one
> particular problem, I use--more or less--a similar algorithm for all
> three, but the clojure code runs about 20-30 times slower than the
> java/scala versions. Does anyone have any idea why this might be? It
> strikes me that it might have something to do with every? but I don't
> know because I'm a newbie with Clojure.

Daniel Solano Gómez gave a very interesting talk last summer about
numerical performance in Clojure:

http://www.infoq.com/presentations/Crunching-Numbers-Clojure

While there are many technical tips about boosting math performance,
Daniel's overarching point is that the best speed boost is the _right
algorithm_. For instance, this solution to the problem runs in ~2ms:

```

(def primes
  "This should be a lazy-seq of primes generated by a bit-sieve, but for
   this example the largest prime we need is 3!"
  [2 3])

(defn prime-factors [n]
  (loop [n n fs []]
(if-let [p (first (for [p primes
:while (<= p (int (Math/sqrt n)))
:when (zero? (rem n p))]
p))]
  (recur (/ n p) (conj fs p))
  (conj fs n

(defn lcm
  "The lowest common multiple of a set of numbers is the product of the
   distinct prime factors in the set each raised to the power of the
   greatest occurence in a single number."
  [& xs]
  (let [fqs (map #(frequencies (prime-factors %)) xs)]
(apply * (map (fn [p] (Math/pow p (apply max (map #(get % p 0) fqs
  (set (mapcat keys fqs))

(time
  (long (apply lcm (range 2 21

"Elapsed time: 2.010032 msecs"
232792560

```

I know you are explicitly asking for language implementation
differences, but I believe you would be better served in this instance
by studying more elegant algorithms.

The fastest code in any language is the code that does not execute;
designing with this in mind is especially important in Clojure, where
the functional abstractions are beautiful, but somewhat costly.

guns

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

[Shouxun Yang]

When I taught myself Scheme and Common Lisp more than ten years ago, I
didn't have any problem with the parentheses, probably because I just
learned a little bit of C/C++ or Pascal (Delphi) and were eager to
learn Emacs (one of the two major editors in the Unix/Linux world)
when I switched to the then emerging free GNU/Linux OS from
virus-ridden Windows.

I believe if one is ready to learn new things and has access to
capable editors, parentheses won't be the real block. Of course,
saying this won't solve the problem Sergey meant to solve.

This problem has been raised numerous times and there have been many
attempts to remove the parentheses in Lisp languages for those not
getting it. Dylan could be considered as one of the most fruitful one.
Dylan, as you know, has not been a mainstream language all the same,
probably due to bad luck when Objective C was chosen instead for Mac
development before it really got off.

Anyone who is interested in implementing such a system is welcome to
go ahead and experiment, though the result may not be that
encouraging, given the history in Lisp languages.

Also, it seems that alternative syntax for other languages, such as
the revised syntax for OCaml, is difficult to gain widespread use and
even fragments the user community in some way.

Just some random thoughts.

On Tue, Feb 5, 2013 at 7:38 PM, Lee Spector  wrote:
>
> On Feb 5, 2013, at 12:15 AM, Rich Morin wrote:
>
>> On Feb 4, 2013, at 19:49, deliminator wrote:
>>> Long story short: want more people to love lisp?
>>> Implement paredit for more editors.
>>
>> +1!
>
> -1
>
> Just another data point and YMMV, but I've long loved Lisp and long hated 
> paredit. I do agree, however, that editor features are key. For me, what 
> makes the difference is bracket/parentheses *matching* (showing what matches 
> what, but not typing for me) and good auto-reindentation. In my experience 
> those features make it so obvious what the code structure is that it's simple 
> to keep things balanced correctly. Paredit, however, goes too far by thinking 
> it knows more than I do about what I want to type when, and gets in the way 
> when I want to type my ideas in a weird order and/or cut/paste unbalanced 
> things, which I basically do continuously.
>
> FWIW I also teach new programmers Lisp with some regularity, and I don't get 
> the sense that parentheses are ever a big issue (in the context of the 
> editors that I provide, which always have bracket matching and 
> auto-reindentation -- yes, it' d be great for those to be more ubiquitous). 
> On the other hand, defeating students' existing typing/cutting/pasting 
> habits, or making them deal with emacs arcana: problems.
>
> Again, YMMV!
>
>  -Lee
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.

constructing matrix-like structures with list-comprehension

[Jim foo.bar]

Hi all,

I 'm a bit confused with this - I'm trying to think but I can't!!! 
Probably cos I've not had any food yet!
Up till now I thought I could construct matrices with 'for'...So (for [i 
(range 3)] i) gives us a 1d structure (a list)...
(for [i (range 3) j (range 4)] [i j]) gives us a 2d structure (list of 
vectors)


On that basis I wrote the following little macro thinking I'd be bale to 
create matrices with arbitrary dimensions:


(defn matrix [& dim-lengths]
(let [bindings (vec (mapcat #(vector (gensym) `(range ~%)) dim-lengths))
  symbols  (mapv first (partition 2 bindings))
  counts (count symbols)]
  `(for ~bindings  (if (< counts 1) ~symbols (first ~symbols)

Now, even though this expands to the 'for' I want I'm starting to think 
this is not the right approach for matrices...all I get is 2d structures 
regardless of how many dimensions I pass in...


any ideas anyone?

Jim




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

To unsubscribe from 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.

Puzzle with lazy sequences

[N8Dawgrr]

If the head is retained on a lazy sequence we have a potential memory leak.

I set my JVM memory low, 64mb and ran the following:

user> (defn test1 [coll] (reduce + coll))
#'user/test1
user> (test1 (take 1000 (iterate inc 0)))
499500
user> 

Now if we do:

user> (defn test2 [coll] [(reduce + coll) (reduce + coll)])
#'user/test2
user> (test2 (take 1000 (iterate inc 0)))
OutOfMemoryError Java heap space  [trace missing]
user> 

Which OOMs as expected. The question is, why doens't the first example blow 
up? What magics happening?

I would expect coll which is a function argument to be retained by the 
garbage collector and hence blow up.

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

[Jim foo.bar]

I do hate writing code on thunderbird!!!  '(< counts 1)'  should 
obviously be '(> ~counts 1)'...


Jim


On 05/02/13 15:03, Jim foo.bar wrote:

Hi all,

I 'm a bit confused with this - I'm trying to think but I can't!!! 
Probably cos I've not had any food yet!
Up till now I thought I could construct matrices with 'for'...So (for 
[i (range 3)] i) gives us a 1d structure (a list)...
(for [i (range 3) j (range 4)] [i j]) gives us a 2d structure (list of 
vectors)


On that basis I wrote the following little macro thinking I'd be bale 
to create matrices with arbitrary dimensions:


(defn matrix [& dim-lengths]
(let [bindings (vec (mapcat #(vector (gensym) `(range ~%)) dim-lengths))
  symbols  (mapv first (partition 2 bindings))
  counts (count symbols)]
  `(for ~bindings  (if (< counts 1) ~symbols (first ~symbols)

Now, even though this expands to the 'for' I want I'm starting to 
think this is not the right approach for matrices...all I get is 2d 
structures regardless of how many dimensions I pass in...


any ideas anyone?

Jim






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

To unsubscribe from 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: Puzzle with lazy sequences

[Herwig Hochleitner]

Clojure has a feature called locals clearing, which sets 'coll to nil
before calling reduce in test1, because the compiler can prove it won't be
used afterwards.
In test2, coll has to be retained, because reduce is called a second time
on it.


2013/2/5 N8Dawgrr 

> If the head is retained on a lazy sequence we have a potential memory leak.
>
> I set my JVM memory low, 64mb and ran the following:
>
> user> (defn test1 [coll] (reduce + coll))
> #'user/test1
> user> (test1 (take 1000 (iterate inc 0)))
> 499500
> user>
>
> Now if we do:
>
> user> (defn test2 [coll] [(reduce + coll) (reduce + coll)])
> #'user/test2
> user> (test2 (take 1000 (iterate inc 0)))
> OutOfMemoryError Java heap space  [trace missing]
> user>
>
> Which OOMs as expected. The question is, why doens't the first example
> blow up? What magics happening?
>
> I would expect coll which is a function argument to be retained by the
> garbage collector and hence blow up.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Puzzle with lazy sequences

[Jim foo.bar]

Couldn't the compiler infer that the 2 expressions are identical with 
identical arguments and perform the reduce only once? Basically what the 
programmer would do in a let statement? Would that be too expensive?


Jim

On 05/02/13 15:21, Herwig Hochleitner wrote:
Clojure has a feature called locals clearing, which sets 'coll to nil 
before calling reduce in test1, because the compiler can prove it 
won't be used afterwards.
In test2, coll has to be retained, because reduce is called a second 
time on it.



2013/2/5 N8Dawgrr >


If the head is retained on a lazy sequence we have a potential
memory leak.

I set my JVM memory low, 64mb and ran the following:

user> (defn test1 [coll] (reduce + coll))
#'user/test1
user> (test1 (take 1000 (iterate inc 0)))
499500
user>

Now if we do:

user> (defn test2 [coll] [(reduce + coll) (reduce + coll)])
#'user/test2
user> (test2 (take 1000 (iterate inc 0)))
OutOfMemoryError Java heap space  [trace missing]
user>

Which OOMs as expected. The question is, why doens't the first
example blow up? What magics happening?

I would expect coll which is a function argument to be retained by
the garbage collector and hence blow up.

-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from 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.




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

To unsubscribe from 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: Puzzle with lazy sequences

[N8Dawgrr]

Hi Thanks for the super fast response, Still a little confused. If coll is 
set to nil before reduce is called, then what is reduce called with?

On Tuesday, February 5, 2013 3:21:14 PM UTC, Herwig Hochleitner wrote:
>
> Clojure has a feature called locals clearing, which sets 'coll to nil 
> before calling reduce in test1, because the compiler can prove it won't be 
> used afterwards.
> In test2, coll has to be retained, because reduce is called a second time 
> on it.
>
>
> 2013/2/5 N8Dawgrr >
>
>> If the head is retained on a lazy sequence we have a potential memory 
>> leak.
>>
>> I set my JVM memory low, 64mb and ran the following:
>>
>> user> (defn test1 [coll] (reduce + coll))
>> #'user/test1
>> user> (test1 (take 1000 (iterate inc 0)))
>> 499500
>> user> 
>>
>> Now if we do:
>>
>> user> (defn test2 [coll] [(reduce + coll) (reduce + coll)])
>> #'user/test2
>> user> (test2 (take 1000 (iterate inc 0)))
>> OutOfMemoryError Java heap space  [trace missing]
>> user> 
>>
>> Which OOMs as expected. The question is, why doens't the first example 
>> blow up? What magics happening?
>>
>> I would expect coll which is a function argument to be retained by the 
>> garbage collector and hence blow up.
>>
>>  -- 
>> -- 
>> 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.

leiningen checkout dependencies

[Taylor Sando]

I have a main project and a subproject and I'm trying to get them to work 
together.  I created the checkouts folder in the main project, and made a 
symlink to the subproject in it.  I use lein repl in the main project, and 
then I make a (require 'subproject.ns).  It works in the sense that it's 
finding the subproject source files, but since the sub project has 
dependencies that are not in the main project, it is not working.  I tried 
adding the sub project to the :dependencies in the main project's 
project.clj, but then all I get is an error that it can't resolve the 
dependencies of the subproject, because it can't find it.  How do I get the 
main project to resolve the dependencies for the sub project?

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

[r0man]

When I started this library I wanted something that was based on
clj-http and the concept of middleware. At that time Matt's
library was not based on clj-http yet. But this has changed ...

On Tuesday, February 5, 2013 6:37:13 AM UTC+1, Leonardo Borges wrote:
>
> Nobody ever replied to this and I'm now wondering the same.
>
> Any opinions one way or the other?
>
> On Tuesday, January 24, 2012 5:08:44 PM UTC+11, Dave Sann wrote:
>>
>> Hi r0man,
>>
>> I am curious as to similarities/differences of your library to: 
>> https://github.com/mattrepl/clj-oauth
>>
>> Dave
>>
>

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

[Phillip Lord]

>> So, I really would like to hook into the doc function so that I can
>> return a documentation string pulled directly from the underlying Java
>> object; I already have a function for doing this, but do not know how to
>> get the native Clojure facilities to call this, rather than just take
>> the documentation directly from the metadata. 


Brian Marick  writes:
> Could you wrap clojure.repl/print-doc using something like Robert Hooke?
> https://github.com/technomancy/robert-hooke


Hugo Duncan  writes:
> Could you initialise the var metadata using the docstring pulled from
> the java object. You would probably need your macros to generate
> alter-var-root forms to add the metadata.


So, in the end, I did a combination of the two. I've used Robert Hooke
to hook the print-doc function -- hooking doc directly doesn't work as
it's a macro; so even running macroexpand forces the hook, which didn't
seem ideal.

My hook then places the docstring onto the var before. Not ideal, as
things like apropos or find-doc are still not going to work; but then
these are limited for larger namespaces. I already have 50,000 symbols
in one namespace, and string matching is just not going to cut it. 

Thanks anyway for the help. Much appreciated. 

Phil

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

ANN: Tawny-OWL 0.9

[Phillip Lord]

Tawny-OWL is a clojure library which provides a DSL for the construction
of OWL Ontologies (http://www.w3.org/2004/OWL/). The practical upshot of
this, is that allows a form of logic reasoning over sets of facts about
the world, with strong computational guarantees about decidability.

At it's simplest it looks rather like the Manchester Syntax, but is
fully programmatic language, which allows for arbitrary templating of
expressions. Where possible, it uses clojure facilities directly, so
things like autocomplete, and documentation look up work out-of-the-box,
in what ever IDE is your poison. 

It comes complete with reasoner support using HermiT
(http://www.hermit-reasoner.com/) or ELK
(http://code.google.com/p/elk-reasoner/). Tawny-OWL current implements
all of the object and annotation side of OWL; expression of datatype
properties will follow shortly. 

Although, it's been available for a while, this is the first release
that I have announced here. I'd welcome feedback. The Clojure is a bit
nasty at places--I learnt the language at the same time. 

https://github.com/phillord/tawny-owl

and on clojars. 

Phil


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

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

[Michael Klishin]

2013/2/5 Phillip Lord 

> Although, it's been available for a while, this is the first release
> that I have announced here. I'd welcome feedback.
>

Phillip,

Please add dependency (artifacts) information to the README.
Otherwise beginners won't be able to use your project.

Thank you.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

[Timothy Baldridge]

>Hi Thanks for the super fast response, Still a little confused. If coll is
set to nil before >reduce is called, then what is reduce called with?

Remember, the JVM is a stack machine (before the JIT is run). So the code
produced is something like this:

push coll
push nil
pop-into coll
call-fn reduce

Timothy


On Tue, Feb 5, 2013 at 9:31 AM, Herwig Hochleitner
wrote:

> 2013/2/5 N8Dawgrr 
>
>> Hi Thanks for the super fast response, Still a little confused. If coll
>> is set to nil before reduce is called, then what is reduce called with?
>
>
> It's called with the value coll had right before it being set to nil.
>
> Clojure even has Util.retl, with a dummy arg, to do this even in plain
> java, for example:
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3458
>
> Jim:
>
> > Couldn't the compiler infer that the 2 expressions are identical with
> identical arguments and perform the reduce only once? Basically what the
> programmer would do in a let statement? Would that be too expensive?
>
> No the compiler could only do that, if it knew that reduce (and its
> reducing fn) has no side effects. Clojure has no mutability analysis.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: ANN: Tawny-OWL 0.9

[AtKaaZ]

you can release that on LGPL License ?
does that work with the EPL of clojure ? or is it only an issue when lein
uberjar-ed ?



On Tue, Feb 5, 2013 at 5:57 PM, Phillip Lord
wrote:

>
>
> Tawny-OWL is a clojure library which provides a DSL for the construction
> of OWL Ontologies (http://www.w3.org/2004/OWL/). The practical upshot of
> this, is that allows a form of logic reasoning over sets of facts about
> the world, with strong computational guarantees about decidability.
>
> At it's simplest it looks rather like the Manchester Syntax, but is
> fully programmatic language, which allows for arbitrary templating of
> expressions. Where possible, it uses clojure facilities directly, so
> things like autocomplete, and documentation look up work out-of-the-box,
> in what ever IDE is your poison.
>
> It comes complete with reasoner support using HermiT
> (http://www.hermit-reasoner.com/) or ELK
> (http://code.google.com/p/elk-reasoner/). Tawny-OWL current implements
> all of the object and annotation side of OWL; expression of datatype
> properties will follow shortly.
>
> Although, it's been available for a while, this is the first release
> that I have announced here. I'd welcome feedback. The Clojure is a bit
> nasty at places--I learnt the language at the same time.
>
> https://github.com/phillord/tawny-owl
>
> and on clojars.
>
> Phil
>
>
> --
> Phillip Lord,   Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email:
> phillip.l...@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,   skype: russet_apples
> Newcastle University,   msn: m...@russet.org.uk
> NE1 7RU twitter: phillord
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>


-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: Inflection on clojure.java.io/reader and writer

[Kanwei Li]

That's funny, I did exactly the same thing and wrote BufferedReader for 
both. DOH!

Although I have no idea how the internals of type hinting is, I do think 
it's peculiar that there doesn't seem to be type error checking, even 
though we are explicitly "defining" the type. I would feel like it should 
error, instead of falling back on reflection.

Kanwei

On Monday, February 4, 2013 12:36:51 PM UTC-5, AtKaaZ wrote:
>
> in other words:
> this:
>
>   (let [in (clojure.java.io/reader src)
> out (clojure.java.io/writer dest)
>
>
> becomes this:
> (let [^java.io.BufferedReader in (clojure.java.io/reader src)
>^java.io.BufferedWriter out (clojure.java.io/writer dest)
>
>
> and it works for me too. (but I wasted some time by having BufferedReader 
> in both places)
>
>
> On Mon, Feb 4, 2013 at 6:26 PM, Andy Fingerhut 
> 
> > wrote:
>
>> I don't have CCW Eclipse installed to test, but by saving that file on my 
>> Mac (should also work on Linux) in a subdirectory "obj", and editing it to 
>> add the ^java.io.BufferedReader in and ^java.io.BufferedWriter out type 
>> hints as suggested by Luc P. earlier in this thread, I was able to 
>> eliminate the reflection warnings:
>>
>> % mkdir obj
>> % cp  obj/solutions.clj
>>
>> # Original file without the type hints gives reflection warnings as 
>> expected
>>
>> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj 
>> clojure.lang.Compile solution
>> Compiling solution to ./obj
>> Reflection warning, solution.clj:38 - reference to field readLine can't 
>> be resolved.
>> Reflection warning, solution.clj:45 - reference to field readLine can't 
>> be resolved.
>> Reflection warning, solution.clj:63 - reference to field newLine can't be 
>> resolved.
>> Reflection warning, solution.clj:54 - reference to field newLine can't be 
>> resolved.
>>
>> # Now I hand-edit obj/solutions.clj to add the type hints, and recompile. 
>>  No reflection warnings.
>> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj 
>> clojure.lang.Compile solution
>> Compiling solution to ./obj
>> % 
>>
>> Perhaps you should try verifying that you added the type hints correctly, 
>> saved the source file, recompiled the one you wanted to in CCW Eclipse, etc.
>>
>> Andy
>>
>>
>> On Feb 4, 2013, at 9:10 AM, Kanwei Li wrote:
>>
>> Hey Andy,
>>
>> Thanks for offering to help. Here's a gist: 
>> https://gist.github.com/4696105
>>
>> As you can see at the bottom, I want the main method to read/write to 
>> STDIN/STDOUT, but for testing, I want to read from files instead.
>>
>> This is what I get in both CCW Eclipse and nrepl:
>>
>> Reflection warning, NO_SOURCE_PATH:4 - reference to field readLine can't 
>> be resolved.
>>
>> Reflection warning, NO_SOURCE_PATH:11 - reference to field readLine can't 
>> be resolved.
>>
>> Reflection warning, NO_SOURCE_PATH:29 - reference to field newLine can't 
>> be resolved.
>>
>> Reflection warning, NO_SOURCE_PATH:20 - reference to field newLine can't 
>> be resolved.
>> Thanks!
>>
>> On Sunday, February 3, 2013 4:38:38 PM UTC-5, Andy Fingerhut wrote:
>>>
>>> Can you post a larger chunk of code for us to examine, perhaps on github 
>>> or as a gist if it is over 30 lines of code or so?  Many of us have had 
>>> good success with eliminating reflection using type hints, so it should be 
>>> possible to make it work.
>>>
>>> Andy
>>>
>>> On Feb 3, 2013, at 12:50 PM, Kanwei Li wrote:
>>>
>>> Unfortunately it doesn't work.
>>>
>>> Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved.
>>>
>>> Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't 
>>> be resolved.
>>>
>>> On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote:

 Why not add type hints like this ? 

 (let [^java.io.BufferedReader in  
^java.io.BufferedWriter out ...] 
 .. 

 Luc P. 

 > Hey guys, 
 > 
 > I'm trying to read a lot of data, sometimes from *in* and sometimes 
 from a 
 > file. I extensively use the native .write and .read java methods. 
 > 
 > According to the clojure doc for reader, it says that "Default 
 > implementations always return a BufferedReader". However, when I 
 write, 
 > 
 > (*defn* solve [src dest] 
 > 
 >   (*let* [in (clojure.java.io/reader src) 
 > 
 > out (clojure.java.io/writer dest) 
 > 
 > I get a bunch of reflection warnings on .read and .write, and most of 
 the 
 > running time is spent on reflection. AFAIK you can't type hint a 
 (let) 
 > construct, so what should I do here? 
 > 
 > 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 
>> F

Re: Inflection on clojure.java.io/reader and writer

[AtKaaZ]

*I would love it if it would be* at least a warning if not even better *an
error*, but I feel it wouldn't be idiomatic clojure to err, but to warn
would maybe be accepted...


On Tue, Feb 5, 2013 at 6:34 PM, Kanwei Li  wrote:

> That's funny, I did exactly the same thing and wrote BufferedReader for
> both. DOH!
>
> Although I have no idea how the internals of type hinting is, I do think
> it's peculiar that there doesn't seem to be type error checking, even
> though we are explicitly "defining" the type. I would feel like it should
> error, instead of falling back on reflection.
>
> Kanwei
>
>
> On Monday, February 4, 2013 12:36:51 PM UTC-5, AtKaaZ wrote:
>
>> in other words:
>> this:
>>
>>   (let [in (clojure.java.io/reader src)
>> out (clojure.java.io/writer dest)
>>
>>
>> becomes this:
>> (let [^java.io.BufferedReader in (clojure.java.io/reader src)
>>^java.io.BufferedWriter out (clojure.java.io/writer dest)
>>
>>
>> and it works for me too. (but I wasted some time by having BufferedReader
>> in both places)
>>
>>
>> On Mon, Feb 4, 2013 at 6:26 PM, Andy Fingerhut wrote:
>>
>>> I don't have CCW Eclipse installed to test, but by saving that file on
>>> my Mac (should also work on Linux) in a subdirectory "obj", and editing it
>>> to add the ^java.io.BufferedReader in and ^java.io.BufferedWriter out type
>>> hints as suggested by Luc P. earlier in this thread, I was able to
>>> eliminate the reflection warnings:
>>>
>>> % mkdir obj
>>> % cp  obj/solutions.clj
>>>
>>> # Original file without the type hints gives reflection warnings as
>>> expected
>>>
>>> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj
>>> clojure.lang.Compile solution
>>> Compiling solution to ./obj
>>> Reflection warning, solution.clj:38 - reference to field readLine can't
>>> be resolved.
>>> Reflection warning, solution.clj:45 - reference to field readLine can't
>>> be resolved.
>>> Reflection warning, solution.clj:63 - reference to field newLine can't
>>> be resolved.
>>> Reflection warning, solution.clj:54 - reference to field newLine can't
>>> be resolved.
>>>
>>> # Now I hand-edit obj/solutions.clj to add the type hints, and
>>> recompile.  No reflection warnings.
>>> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj
>>> clojure.lang.Compile solution
>>> Compiling solution to ./obj
>>> %
>>>
>>> Perhaps you should try verifying that you added the type hints
>>> correctly, saved the source file, recompiled the one you wanted to in CCW
>>> Eclipse, etc.
>>>
>>> Andy
>>>
>>>
>>> On Feb 4, 2013, at 9:10 AM, Kanwei Li wrote:
>>>
>>> Hey Andy,
>>>
>>> Thanks for offering to help. Here's a gist: https://gist.github.com/**
>>> 4696105 
>>>
>>> As you can see at the bottom, I want the main method to read/write to
>>> STDIN/STDOUT, but for testing, I want to read from files instead.
>>>
>>> This is what I get in both CCW Eclipse and nrepl:
>>>
>>> Reflection warning, NO_SOURCE_PATH:4 - reference to field readLine can't
>>> be resolved.
>>>
>>> Reflection warning, NO_SOURCE_PATH:11 - reference to field readLine
>>> can't be resolved.
>>>
>>> Reflection warning, NO_SOURCE_PATH:29 - reference to field newLine can't
>>> be resolved.
>>>
>>> Reflection warning, NO_SOURCE_PATH:20 - reference to field newLine can't
>>> be resolved.
>>> Thanks!
>>>
>>> On Sunday, February 3, 2013 4:38:38 PM UTC-5, Andy Fingerhut wrote:

 Can you post a larger chunk of code for us to examine, perhaps on
 github or as a gist if it is over 30 lines of code or so?  Many of us have
 had good success with eliminating reflection using type hints, so it should
 be possible to make it work.

 Andy

 On Feb 3, 2013, at 12:50 PM, Kanwei Li wrote:

 Unfortunately it doesn't work.

 Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved.

 Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine
 can't be resolved.

 On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote:
>
> Why not add type hints like this ?
>
> (let [^java.io.BufferedReader in 
>^java.io.BufferedWriter out ...]
> ..
>
> Luc P.
>
> > Hey guys,
> >
> > I'm trying to read a lot of data, sometimes from *in* and sometimes
> from a
> > file. I extensively use the native .write and .read java methods.
> >
> > According to the clojure doc for reader, it says that "Default
> > implementations always return a BufferedReader". However, when I
> write,
> >
> > (*defn* solve [src dest]
> >
> >   (*let* [in (clojure.java.io/reader src)
> >
> > out (clojure.java.io/writer dest)
> >
> > I get a bunch of reflection warnings on .read and .write, and most
> of the
> > running time is spent on reflection. AFAIK you can't type hint a
> (let)
> > construct, so what should I do here?
> >
> > Thanks!


>

Re: leiningen checkout dependencies

[Phil Hagelberg]

Taylor Sando writes:

> I tried adding the sub project to the :dependencies in the main
> project's project.clj, but then all I get is an error that it can't
> resolve the dependencies of the subproject, because it can't find it.
> How do I get the main project to resolve the dependencies for the sub
> project?

This is the correct way to do it, but you need to run `lein install` in
the sub project first.

-Phil

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

Re: Clojure - Python Style suggestion

[John Jacobsen]

Having written Python code professionally for about 7 years and taken to 
Clojure as a serious hobby for a year and a half, I have thought a lot 
about the differences between the two languages.

While parens provide simple and powerful homoiconicity (and they have a 
somewhat pleasing aesthetic -- let's face it, if you feel strongly 
otherwise you'll just steer clear of any Lisp), they do introduce some 
visual noise while reading code.  Readability matters to me quite a bit 
(but not as much as simplicity), and Python still seems more readable to 
me.  I have seen others express this opinion on this list.

A simple workaround I've considered, but haven't gotten around to doing 
anything about in e.g. Emacs, is to simply tone down the parens visually in 
the editor.  Hierarchy of color, size, contrast, etc. matters a lot in 
perception, and by making the parens slightly less obvious visually one's 
eye would be drawn to the actual functions more, "parsing" the parentheses 
only when several symbols exist on the same line.  Similar to what 
colorizing parentheses does - the color tells you more, if you pay 
attention to it.

Despite a passion for Clojure I do keep an eye on other languages and I am 
curious about e.g. template Haskell and Julia, both of which do the 
homoiconicity thing without all the parens.

When I program in Python I sure do miss other features of Clojure - speed, 
immutable data structures, and especially macros.

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

Must pass a garbage param to clj-oauth/request token, only in REPL

[lrrrgg]

In REPL:

(oauth/request-token consumer "http://localhost:3000/callback/twitter";)

IllegalArgumentException No value supplied for key: 
http://localhost:3000/callback/twitter  
clojure.lang.PersistentHashMap.createWithCheck (PersistentHashMap.java:89)

If I do:

(oauth/request-token consumer "http://localhost:3000/callback/twitter"; 
"junk")

{:oauth_token "HzfxciDhS1gtQVgI3Q2HnjcGY5kRt2b45LAV8tnlos", 
:oauth_token_secret "grAV72ilyLFohdms1YyRtcde6ZQSWD2K1FdExXiV0vc", 
:oauth_callback_confirmed "true"}

clj-oauth makes no mention of this extra "hash map value." How is hashmap 
even coming into play for a function argument?

FWIW, when running with "lein ring server" instead of REPL, it works 
without the "junk" (and complains about the extra arg if "junk" is there).

So what is the REPL doing?

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

[Taylor Sando]

That worked, 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: constructing matrix-like structures with list-comprehension

[Jim - FooBar();]

Ok, I think I cracked it but as usual someone else might come up with a 
cleaner approach...:-)


(defn matrix [dim & dim-lengths]
{:pre [(not (nil? dim))]} ;;cannot accept
(let [bindings (map #(vector (gensym) `(range ~%)) dim-lengths)
  symbols  (mapv first bindings)
  counts   (inc (count symbols)) ;;include dim in count
  curr-sym (or (first symbols) (gensym))]
(if (> counts 1) ;;more dimensions?
  `(for ~(vector curr-sym `(range ~dim))
~(apply matrix (first dim-lengths) (next dim-lengths))) ;;recurse 
for each element
 `(for ~(vector curr-sym `(range ~dim))  ~curr-sym  ;;revert to 
plain 'for'



The behaviour is as expected for matrices and the precondition is very 
informative with regards to the failing condition... I'm really curious 
to see any different approaches...


Jim



On 05/02/13 15:09, Jim foo.bar wrote:
I do hate writing code on thunderbird!!!  '(< counts 1)'  should 
obviously be '(> ~counts 1)'...


Jim


On 05/02/13 15:03, Jim foo.bar wrote:

Hi all,

I 'm a bit confused with this - I'm trying to think but I can't!!! 
Probably cos I've not had any food yet!
Up till now I thought I could construct matrices with 'for'...So (for 
[i (range 3)] i) gives us a 1d structure (a list)...
(for [i (range 3) j (range 4)] [i j]) gives us a 2d structure (list 
of vectors)


On that basis I wrote the following little macro thinking I'd be bale 
to create matrices with arbitrary dimensions:


(defn matrix [& dim-lengths]
(let [bindings (vec (mapcat #(vector (gensym) `(range ~%)) dim-lengths))
  symbols  (mapv first (partition 2 bindings))
  counts (count symbols)]
  `(for ~bindings  (if (< counts 1) ~symbols (first ~symbols)

Now, even though this expands to the 'for' I want I'm starting to 
think this is not the right approach for matrices...all I get is 2d 
structures regardless of how many dimensions I pass in...


any ideas anyone?

Jim








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

To unsubscribe from 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 - Python Style suggestion

[Stefan Kamphausen]

>
> A simple workaround I've considered, but haven't gotten around to doing 
> anything about in e.g. Emacs, is to simply tone down the parens visually in 
> the editor.  Hierarchy of color, size, contrast, etc. matters a lot in 
> perception, and by making the parens slightly less obvious visually one's 
> eye would be drawn to the actual functions more, "parsing" the parentheses 
> only when several symbols exist on the same line.  Similar to what 
> colorizing parentheses does - the color tells you more, if you pay 
> attention to it.
>
>
> you might be pleased with the look of parens, that rainbow-delimiters.el 
provides:

https://raw.github.com/jlr/rainbow-delimiters/master/rainbow-delimiters.el 

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

[Softaddicts]

You are not defining a type here. A type hint is just that... a hint so the 
compiler
can optimize the code it generates to call the readLine method on this specific
object class.

As an example, if io/reader returned an object of a different class at runtime
than BufferedReader, it would not fail even if the hint says "expect an object 
of this class".

The generated code testing that the object is not of the hinted class would
resort to reflection on the object class to find if the readLine method exists.
If not you will get the usual runtime error saying that the method does not 
exists.

The Clojure compiler has no type checking equivalent to Java, C, ...
You can define stuff that is not even bound to a value, it would be hard to 
type check on 
these at compile time, no ?

Welcome to a world of values, not containers (the blue pieces can only fit in 
the blue 
container, the red ones  you get the picture) or as Rich says places.

Luc P.


> That's funny, I did exactly the same thing and wrote BufferedReader for 
> both. DOH!
> 
> Although I have no idea how the internals of type hinting is, I do think 
> it's peculiar that there doesn't seem to be type error checking, even 
> though we are explicitly "defining" the type. I would feel like it should 
> error, instead of falling back on reflection.
> 
> Kanwei
> 
> On Monday, February 4, 2013 12:36:51 PM UTC-5, AtKaaZ wrote:
> >
> > in other words:
> > this:
> >
> >   (let [in (clojure.java.io/reader src)
> > out (clojure.java.io/writer dest)
> >
> >
> > becomes this:
> > (let [^java.io.BufferedReader in (clojure.java.io/reader src)
> >^java.io.BufferedWriter out (clojure.java.io/writer dest)
> >
> >
> > and it works for me too. (but I wasted some time by having BufferedReader 
> > in both places)
> >
> >
> > On Mon, Feb 4, 2013 at 6:26 PM, Andy Fingerhut 
> > 
> > > wrote:
> >
> >> I don't have CCW Eclipse installed to test, but by saving that file on my 
> >> Mac (should also work on Linux) in a subdirectory "obj", and editing it to 
> >> add the ^java.io.BufferedReader in and ^java.io.BufferedWriter out type 
> >> hints as suggested by Luc P. earlier in this thread, I was able to 
> >> eliminate the reflection warnings:
> >>
> >> % mkdir obj
> >> % cp  obj/solutions.clj
> >>
> >> # Original file without the type hints gives reflection warnings as 
> >> expected
> >>
> >> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj 
> >> clojure.lang.Compile solution
> >> Compiling solution to ./obj
> >> Reflection warning, solution.clj:38 - reference to field readLine can't 
> >> be resolved.
> >> Reflection warning, solution.clj:45 - reference to field readLine can't 
> >> be resolved.
> >> Reflection warning, solution.clj:63 - reference to field newLine can't be 
> >> resolved.
> >> Reflection warning, solution.clj:54 - reference to field newLine can't be 
> >> resolved.
> >>
> >> # Now I hand-edit obj/solutions.clj to add the type hints, and recompile. 
> >>  No reflection warnings.
> >> % java -Dclojure.compile.path=./obj -cp clojure-1.4.0.jar:./obj 
> >> clojure.lang.Compile solution
> >> Compiling solution to ./obj
> >> % 
> >>
> >> Perhaps you should try verifying that you added the type hints correctly, 
> >> saved the source file, recompiled the one you wanted to in CCW Eclipse, 
> >> etc.
> >>
> >> Andy
> >>
> >>
> >> On Feb 4, 2013, at 9:10 AM, Kanwei Li wrote:
> >>
> >> Hey Andy,
> >>
> >> Thanks for offering to help. Here's a gist: 
> >> https://gist.github.com/4696105
> >>
> >> As you can see at the bottom, I want the main method to read/write to 
> >> STDIN/STDOUT, but for testing, I want to read from files instead.
> >>
> >> This is what I get in both CCW Eclipse and nrepl:
> >>
> >> Reflection warning, NO_SOURCE_PATH:4 - reference to field readLine can't 
> >> be resolved.
> >>
> >> Reflection warning, NO_SOURCE_PATH:11 - reference to field readLine can't 
> >> be resolved.
> >>
> >> Reflection warning, NO_SOURCE_PATH:29 - reference to field newLine can't 
> >> be resolved.
> >>
> >> Reflection warning, NO_SOURCE_PATH:20 - reference to field newLine can't 
> >> be resolved.
> >> Thanks!
> >>
> >> On Sunday, February 3, 2013 4:38:38 PM UTC-5, Andy Fingerhut wrote:
> >>>
> >>> Can you post a larger chunk of code for us to examine, perhaps on github 
> >>> or as a gist if it is over 30 lines of code or so?  Many of us have had 
> >>> good success with eliminating reflection using type hints, so it should 
> >>> be 
> >>> possible to make it work.
> >>>
> >>> Andy
> >>>
> >>> On Feb 3, 2013, at 12:50 PM, Kanwei Li wrote:
> >>>
> >>> Unfortunately it doesn't work.
> >>>
> >>> Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved.
> >>>
> >>> Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't 
> >>> be resolved.
> >>>
> >>> On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote:
> 
>  Why not add type hints like this ? 
> 
>  (let [^java.io.BufferedReader in ..

Re: [ANN] oauth-clj

[Leonardo Borges]

Thanks for the answer Roman!

In the end I went with Matt's lib purely based on the number of stars
and forks - so far so good.

Cheers,
Leonardo Borges
www.leonardoborges.com


On Wed, Feb 6, 2013 at 3:25 AM, r0man  wrote:
> When I started this library I wanted something that was based on
> clj-http and the concept of middleware. At that time Matt's
> library was not based on clj-http yet. But this has changed ...
>
> On Tuesday, February 5, 2013 6:37:13 AM UTC+1, Leonardo Borges wrote:
>>
>> Nobody ever replied to this and I'm now wondering the same.
>>
>> Any opinions one way or the other?
>>
>> On Tuesday, January 24, 2012 5:08:44 PM UTC+11, Dave Sann wrote:
>>>
>>> Hi r0man,
>>>
>>> I am curious as to similarities/differences of your library to:
>>> https://github.com/mattrepl/clj-oauth
>>>
>>> Dave
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Puzzle with lazy sequences

[Herwig Hochleitner]

Me:

> No 

Well, actually Ambrose of core.typed has proposed an interface to let the
compiler know about type information.
That seems to make it conceivable to mark functions as pure, hence,
implement the optimization you proposed, Jim.
Sorry if my first response sounded a tad negative, btw

Anyway, while the thought is intriguing, the state of art still needs
someone to write it down.

cheers

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

Re: EDN for Objective-C (iOS/OS X)

[Herwig Hochleitner]

According to the "Implementations" page of the edn wiki [1], libclj [2]
seems to be a possible starting point for that plan.

[1] https://github.com/edn-format/edn/wiki/Implementations
[2] https://github.com/brandonbloom/libclj


2013/2/5 Matthew Phillips 

> Hello,
>
> a quick search of this group, and the web at large, doesn't get any hits
> for an Obj-C EDN implementation. Is there anyone working on this?
>
> If not, I'll likely go ahead and implement a basic subset of the EDN spec
> for my own needs, which I'd be happy to share.
>
> Cheers,
>
> Matthew.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 - Python Style suggestion

[Herwig Hochleitner]

2013/2/4 Sergey Didenko 

> My point is to introduce a second-class syntax to attract orthodox
> users. Definitely not migrating.
>

OK, I can see how I missed that point. I would say then: go ahead,
transform a couple of clojure source files to that style and see, if you
can lure someone orthodox out from under their rock with it.
_If_ it does work, a couple of orthodox users might just be the right
catalyst to make clojure greater in an even faster pace.
They'll have their own syntax to play with. We'll call it "infix the
reader". jk with that last part.

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

[Softaddicts]

Orthodox synonyms:

according to the book, acknowledged, admitted, approved, authoritative, 
buttoned-down, by the numbers, canonical, conformist, conservative, 
conventional, correct, customary, devout, die-hard, doctrinal, established, in 
line, legitimate, official, old-line, pious, proper, punctilious, reactionary, 
received, recognized, religious, right, rightful, sanctioned, sound, square, 
standard, straight, straight arrow, traditionalistic, true, well-established

Good luck :)

Luc P.



> 2013/2/4 Sergey Didenko 
> 
> > My point is to introduce a second-class syntax to attract orthodox
> > users. Definitely not migrating.
> >
> 
> OK, I can see how I missed that point. I would say then: go ahead,
> transform a couple of clojure source files to that style and see, if you
> can lure someone orthodox out from under their rock with it.
> _If_ it does work, a couple of orthodox users might just be the right
> catalyst to make clojure greater in an even faster pace.
> They'll have their own syntax to play with. We'll call it "infix the
> reader". jk with that last part.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Possible bug in clojure.java.jdbc

[alex]

Hey all,

I've been using clojure.java.jdbc to write a simple database app. When I 
use the `update-or-insert-values` function, I get an SQLException thrown 
whenever my column names have special characters in them (like a space or 
an ampersand). I think the solution is in line 908: the column-strs should 
be quoted before calling `interpose`. If you do `(map #(str "\"" %1 "\"") 
column-strs)` that should do it?

I can get around this by just writing my own version, but I wanted to patch 
it for everybody. I was told in #clojure that I can't? Anyways, I'm going 
to try to get in contact with the maintainer, but if anyone here has 
contributing rights, and would like to patch it, you have my thanks.

--semisight

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

[Andy Fingerhut]

You can create a ticket for java.jdbc here if you wish that describes the 
problem and what you think will fix it.  Then any of the 500+ Clojure 
contributors can take a shot at fixing it:

http://dev.clojure.org/jira/browse/JDBC

Andy

On Feb 5, 2013, at 7:07 PM, a...@bitlimn.com wrote:

> Hey all,
> 
> I've been using clojure.java.jdbc to write a simple database app. When I use 
> the `update-or-insert-values` function, I get an SQLException thrown whenever 
> my column names have special characters in them (like a space or an 
> ampersand). I think the solution is in line 908: the column-strs should be 
> quoted before calling `interpose`. If you do `(map #(str "\"" %1 "\"") 
> column-strs)` that should do it?
> 
> I can get around this by just writing my own version, but I wanted to patch 
> it for everybody. I was told in #clojure that I can't? Anyways, I'm going to 
> try to get in contact with the maintainer, but if anyone here has 
> contributing rights, and would like to patch it, you have my thanks.
> 
> --semisight

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

[John Gabriele]

On Tuesday, February 5, 2013 12:08:43 PM UTC-5, AtKaaZ wrote:

> you can release that on LGPL License ?
> does that work with the EPL of clojure ? or is it only an issue when lein 
> uberjar-ed ?
>
>  
LGPL just means that the library itself is copyleft (if you make changes to 
it, and distribute the modified library, you've got to distribute your 
changes along with it (under the same conditions) as well).

Issues of license compatibility generally only come up when you're linking 
to *GPL* (not LGPL) libs/apps.

Incidentally, Phillip, in your license notice you say the lib is LGPL, but 
then just below it say it's GPL. Also, it doesn't look like you've included 
the full text of the license in the project. I've found 
 to be very helpful in getting 
the license stuff set up.

---John



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

Re: Clojure - Python Style suggestion

[Mikera]

Please No!!

I don't think it would help newcomers at all - it takes only a few days to 
get used to s-expressions. Coming from a C/Java world I found significant 
whitespace in Python to be just as much of a mental leap. And it would 
cause enormous confusion if two different syntaxes were in use.

But more importantly from a language design perspective, replacing an 
extremely flexible, general purpose code block delimiter with significant 
whitespace is an extremely backwards step. With s-expressions, you are free 
to format your code for clarity, using whitespace to display the code in 
the structure that makes most sense to humans while leaving the parens for 
the machine.

If you lose the parens, you lose the semantic structure of the code and 
introduce significant ambiguity.

Just to prove the point, what does the following evaluate to?

   and true or true true not true

I'd really hate to debug code with ambiguous execution order like that..

As the icing on the cake, losing the parens would make Clojure editors much 
less effective. Being able to select / cut / move whole s-expressions based 
on paren-matching is one of the key productivity advantages when editing 
Clojure code, we certainly wouldn't want to lose this.

On Tuesday, 5 February 2013 04:01:30 UTC+8, Sergey Didenko wrote:
>
> Hi, 
>
> For us as Clojure community it is easy to see how Clojure benefits 
> from being a Lisp. Homoiconity, extreme conciseness, esoteric look and 
> feel, etc. 
>
> However it is hard to see from the inside how Clojure as ecosystem 
> (probably) suffer from being a Lisp. Please don't throw rotten eggs at 
> me, I mean only the part of Lisp that is ... parentheses. 
>
> I remember a number of people that mention parentheses as obstacles to 
> the wider Clojure adoption, in the Clojure space - in the Clojure 
> related discussions, even on this mailing list IIRC. 
>
> But the number of people thinking this way outside the Clojure groups 
> is even bigger! We probably don't notice it because got immune to this 
> famous argument "it has too many parentheses" early when diving into 
> Clojure. 
>
> I suggest there are a big number of people that could gain interest in 
> clojure if we provide them with parentheses-lite Clojure syntax. For 
> example we can steal Python way of intending blocks. 
>
> For example the following quicksort implementation 
>
> (defn qsort [[pivot & xs]] 
>   (when pivot 
> (let [smaller #(< % pivot)] 
>   (lazy-cat (qsort (filter smaller xs)) 
> [pivot] 
> (qsort (remove smaller xs)) 
>
> could be written as 
>
> (set! python-style-op-op true) 
>
> defn qsort [[pivot & xs]] 
>   when pivot 
> let [smaller #(< % pivot)] 
>   lazy-cat 
> qsort 
>   filter smaller xs 
> [pivot] 
> qsort 
>   remove smaller xs 
>
> What do you think? 
>
> Isn't is less complex? 
>
>
> P.S. Ok, I must confess, the mention of the C-Word in the last 
> sentence was just a desperate way to get Rich's attention. 
>
> P.P.S. Actually I would also love to see Clojure community making 
> video clip "Clojure - Python Style" as a remix for "G... Style", but 
> this idea is probably way ahead of its time. 
>
>
> Regards, Sergey. 
>

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

[Typed-Clojure] Where is the definition of All?

[James Xu]

e.g.
(ann test1 (All [x y] [x y -> x]))

where is the 'All' defined?
-- 
Github: https://github.com/xumingming
Blog:http://xumingming.sinaapp.com
Weibo: http://weibo.com/xumingmingt

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

[AtKaaZ]

Thank you.


On Wed, Feb 6, 2013 at 4:52 AM, John Gabriele  wrote:

> On Tuesday, February 5, 2013 12:08:43 PM UTC-5, AtKaaZ wrote:
>
>> you can release that on LGPL License ?
>> does that work with the EPL of clojure ? or is it only an issue when lein
>> uberjar-ed ?
>>
>>
> LGPL just means that the library itself is copyleft (if you make changes
> to it, and distribute the modified library, you've got to distribute your
> changes along with it (under the same conditions) as well).
>
> Issues of license compatibility generally only come up when you're linking
> to *GPL* (not LGPL) libs/apps.
>
> Incidentally, Phillip, in your license notice you say the lib is LGPL, but
> then just below it say it's GPL. Also, it doesn't look like you've included
> the full text of the license in the project. I've found <
> http://www.gnu.org/licenses/gpl-howto.html> to be very helpful in getting
> the license stuff set up.
>
> ---John
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: [Typed-Clojure] Where is the definition of All?

[AtKaaZ]

without looking, I'm thinking maybe it's like "thrown?" when using it for
the "is" macro
(is (thrown? ArithmeticException (/ 1 0)))
where "thrown?" is not defined anywhere and it only has meaning inside "is"
( actually it's *(defmethod assert-expr 'thrown? [msg form]* ... )


On Wed, Feb 6, 2013 at 7:02 AM, James Xu wrote:

>
> e.g.
> (ann test1 (All [x y] [x y -> x]))
>
> where is the 'All' defined?
> --
> Github: https://github.com/xumingming
> Blog:http://xumingming.sinaapp.com
> Weibo: http://weibo.com/xumingmingt
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: [Typed-Clojure] Where is the definition of All?

[AtKaaZ]

maybe this one:
https://github.com/frenchy64/typed-clojure/blob/a5944e7c11fa8fe27a86f781feab63a0d218868f/src/typed/parse.clj#L184



On Wed, Feb 6, 2013 at 7:02 AM, James Xu wrote:

>
> e.g.
> (ann test1 (All [x y] [x y -> x]))
>
> where is the 'All' defined?
> --
> Github: https://github.com/xumingming
> Blog:http://xumingming.sinaapp.com
> Weibo: http://weibo.com/xumingmingt
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate 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: [Typed-Clojure] Where is the definition of All?

[xumingmingv]

Ah, thanks AtKaaZ!

在 2013-2-6，下午2:33，AtKaaZ  写道：

> maybe this one:
> https://github.com/frenchy64/typed-clojure/blob/a5944e7c11fa8fe27a86f781feab63a0d218868f/src/typed/parse.clj#L184
> 
> 
> 
> On Wed, Feb 6, 2013 at 7:02 AM, James Xu  wrote:
> 
> e.g.
> (ann test1 (All [x y] [x y -> x]))
> 
> where is the 'All' defined?
> -- 
> Github: https://github.com/xumingming
> Blog:http://xumingming.sinaapp.com
> Weibo: http://weibo.com/xumingmingt
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.
>  
>  
> 
> 
> 
> -- 
> Please correct me if I'm wrong or incomplete,
> even if you think I'll subconsciously hate 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: Possible bug in clojure.java.jdbc

[Sean Corfield]

Andy's right on process... but as maintainer of clojure.java.jdbc, I
have to ask: why on earth do you have column names containing spaces
or & or other weird characters? That's a serious question: how do you
get into that situation?

I'm not saying clojure.java.jdbc can't be updated to support it, I'm
just questioning whether it should...

On Tue, Feb 5, 2013 at 7:32 PM, Andy Fingerhut  wrote:
> You can create a ticket for java.jdbc here if you wish that describes the 
> problem and what you think will fix it.  Then any of the 500+ Clojure 
> contributors can take a shot at fixing it:
>
> http://dev.clojure.org/jira/browse/JDBC
>
> Andy
>
> On Feb 5, 2013, at 7:07 PM, a...@bitlimn.com wrote:
>
>> Hey all,
>>
>> I've been using clojure.java.jdbc to write a simple database app. When I use 
>> the `update-or-insert-values` function, I get an SQLException thrown 
>> whenever my column names have special characters in them (like a space or an 
>> ampersand). I think the solution is in line 908: the column-strs should be 
>> quoted before calling `interpose`. If you do `(map #(str "\"" %1 "\"") 
>> column-strs)` that should do it?
>>
>> I can get around this by just writing my own version, but I wanted to patch 
>> it for everybody. I was told in #clojure that I can't? Anyways, I'm going to 
>> try to get in contact with the maintainer, but if anyone here has 
>> contributing rights, and would like to patch it, you have my thanks.
>>
>> --semisight
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Possible bug in clojure.java.jdbc

[alex]

@Andy: Sorry, I didn't know the proper channel, I'll post it there.

I don't control the column names. They're imported from an excel 
spreadsheet or assigned by the client I'm writing the app for. From 
experience, it is certainly *possible*, at least to add these columns. 
Currently I just have a function that "escapes" the user input, replacing 
special characters with lookalikes (i.e. space with an underscore).

On Tuesday, February 5, 2013 10:42:50 PM UTC-8, Sean Corfield wrote:
>
> Andy's right on process... but as maintainer of clojure.java.jdbc, I 
> have to ask: why on earth do you have column names containing spaces 
> or & or other weird characters? That's a serious question: how do you 
> get into that situation? 
>
> I'm not saying clojure.java.jdbc can't be updated to support it, I'm 
> just questioning whether it should... 
>
> On Tue, Feb 5, 2013 at 7:32 PM, Andy Fingerhut 
> > 
> wrote: 
> > You can create a ticket for java.jdbc here if you wish that describes 
> the problem and what you think will fix it.  Then any of the 500+ Clojure 
> contributors can take a shot at fixing it: 
> > 
> > http://dev.clojure.org/jira/browse/JDBC 
> > 
> > Andy 
> > 
> > On Feb 5, 2013, at 7:07 PM, al...@bitlimn.com  wrote: 
> > 
> >> Hey all, 
> >> 
> >> I've been using clojure.java.jdbc to write a simple database app. When 
> I use the `update-or-insert-values` function, I get an SQLException thrown 
> whenever my column names have special characters in them (like a space or 
> an ampersand). I think the solution is in line 908: the column-strs should 
> be quoted before calling `interpose`. If you do `(map #(str "\"" %1 "\"") 
> column-strs)` that should do it? 
> >> 
> >> I can get around this by just writing my own version, but I wanted to 
> patch it for everybody. I was told in #clojure that I can't? Anyways, I'm 
> going to try to get in contact with the maintainer, but if anyone here has 
> contributing rights, and would like to patch it, you have my thanks. 
> >> 
> >> --semisight 
> > 
> > -- 
> > -- 
> > 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@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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.