Re: New CSS library - Garden

2013-06-19 Thread Joel Holdbrooks
Jeremy,

Looks good. I've been tinkering with grid systems on and off for the past month 
or so. Have you thought of trying your hand at porting something like the 
Foundation or Gumby grid system?

One thing I've discovered, and you might try this with your 960 implementation, 
is that using higher order functions can be very handy for building them out. 
For example, a make-grid function which accepts a map of configuration options 
and returns a function which takes a column number and optional parameters for, 
say, push and pull. It's a nice way to package things up.

I'm close to wrapping up a small colors framework for Garden which will be 
available in the next beta (hopefully it won't be in beta much longer). When I 
take it out of beta it'll probably include a Clojure flavored implementation of 
either the grid system that ships with Bootstrap or Foundation (including the 
mobile parts).

On the side I've been taking of advantage of Clojure to create a new concept 
for a layout system. It's based on the font-size/line-height ratio and allows 
for the construction of stylesheets such that the grid system and typography 
are harmonious. IOW it's a fat pain in the ass, but I don't think I could even 
fathom the idea of doing it in Sass.

TL;DR you have Clojure at your disposal! Though we're SOL on some very nice 
Sass libraries, we can potentially do more and at a higher level!

Thanks for sharing! It's inspiring.

On Jun 18, 2013, at 4:41 AM, JeremyS jschoffen@gmail.com wrote:

 Hi Joel,
 
 I have a quick and dirty implementation of a 960-ish grid system using a DSL 
 similar to garden If you want to take a look.
 
 
 
 On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:
 It's funny you should bring that up! I've actually been working on extracting 
 the grid system from Bootstrap and modular scale from Foundation. But it's 
 mostly been tinkering.
 
   I am sorely tempted to give this a try.
 
 Please do! If I come up with something I'll be sure to share a Gist.
 
 
 On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach cli...@dreisbach.us 
 wrote:
 One interesting thing you could do, given both Garden and
 ClojureScript, is package CSS frameworks like Twitter Bootstrap or
 Zurb Foundation as a Clojure library. I am sorely tempted to give this
 a try.
 
 On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks cjhold...@gmail.com wrote:
  Murtaza,
 
  Thanks for having a look at the library. I'll try to answer you questions as
  best as I can.
 
 
  How does Garden compare to other pre processors such as sass and less?
 
  There are some similarities with Garden and other CSS preprocessors. I've
  tried to bring over the ones I found most useful when using them. Nested
  selectors and declarations, parent selector references, and unit arithmetic
  are all currently available to stylesheet authors.
 
  The big difference and, in my opinion, the big win is you can build your
  stylesheets with regular Clojure. This gives you a lot of power and freedom
  you won't find anywhere else (AFAIK). To name just a few benefits:
 
  There's no file parsing or interpretation step. It's just data
  transformation.
  There's no need for any sort of special @mixin syntax or macros, you can use
  Clojure function.
  There's no need for an @include directive thanks to clojure namespaces. This
  can help you organize your stylesheet in ways (I think) are much cleaner and
  less surprising than SASS and other preprocessors.
  Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which,
  if you look closely, can be pretty random in some places.
 
  WIth regard to the third point, if you've ever tried using the SMACSS
  approach to stylesheet authoring with a preprocessor like SASS, you can end
  up with an explosion of files and tons of @include directives. It's not fun,
  it's hard to manage, and it's difficult to see where code is coming from -
  especially when using 3rd-party libraries.
 
  Also can I use it in my clojurescript projects ? I mean does it have any
  java lib dependencies that would prevent it?
 
  It does have one small dependency on java.net.URI but I need some time to
  think about whether or not it would be worth dropping. As far as using it
  from a ClojureScript project, what sort of use case are you considering?
 
  What is the workflow when using Garden?
 
  My experience using Garden is probably close to others at this point. It's
  kind of funny in that regard. I'm building a tool and at the same time am
  learning how to use it. Personally, I create a namespace for my core
  stylesheets and separate namespaces for things like utilities and so forth
  (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a call
  to function that compiles and saves the stylesheet at the bottom of the
  core stylesheets. Since I develop with Emacs and nREPL this means all I
  have to do is reload the file and the CSS is refreshed.
 
  It isn't the best approach, but 

Re: Clojure in production

2013-06-19 Thread Nikita Prokopov
We're using Clojure for a year in one of our backend project (real-time 
social feeds aggregation  processing) at AboutEcho.com (Novosibirsk  
Ulyanovsk, Russia). 1.5.1 + a little bit of ClojureScript for internal 
dashboard.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: 'foldcat' slower than 'mapv' even for 10,000 elements

2013-06-19 Thread Tassilo Horn
Jim - FooBar(); jimpil1...@gmail.com writes:

Hi Jim,

 I'm finding that (r/foldcat (r/map f coll)) is consistently slower
 than a simple mapv, even for a collection of 10,000 elements and more!

I might be wrong, but I think reducers are only faster in situations
where you bash many filters/maps/mapcats/etc on top of each other.

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: 'foldcat' slower than 'mapv' even for 10,000 elements

2013-06-19 Thread Alan Busby
On Wed, Jun 19, 2013 at 4:03 PM, Tassilo Horn t...@gnu.org wrote:

 I might be wrong, but I think reducers are only faster in situations
 where you bash many filters/maps/mapcats/etc on top of each other.


Or use fold on a large vector with a multi-core machine.

You might try fold-into-vec to see if there is any difference;

(defn fold-into-vec [coll]
  Provided a reducer, concatenate into a vector.
Note: same as (into [] coll), but parallel.
  (r/fold (r/monoid into vector) conj coll))

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

2013-06-19 Thread Florian Over
Hi,
we at doo.net are using clojure and clojurescript for all our backend and
web development.
We are also still in need for clojure developers. :)

Florian


2013/6/19 Nikita Prokopov proko...@gmail.com

 We're using Clojure for a year in one of our backend project (real-time
 social feeds aggregation  processing) at AboutEcho.com (Novosibirsk 
 Ulyanovsk, Russia). 1.5.1 + a little bit of ClojureScript for internal
 dashboard.

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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 in production

2013-06-19 Thread Hussein B.
I mentioned that! :D

On Wednesday, June 19, 2013 9:40:57 AM UTC+2, Florian Over wrote:

 Hi,
 we at doo.net are using clojure and clojurescript for all our backend and 
 web development.
 We are also still in need for clojure developers. :)

 Florian


 2013/6/19 Nikita Prokopov prok...@gmail.com javascript:

 We're using Clojure for a year in one of our backend project (real-time 
 social feeds aggregation  processing) at AboutEcho.com (Novosibirsk  
 Ulyanovsk, Russia). 1.5.1 + a little bit of ClojureScript for internal 
 dashboard.

  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 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: core logic

2013-06-19 Thread 良ϖ
Hello Josh, I would be glad you share your code :)

Piotr


2013/6/18 David Nolen dnolen.li...@gmail.com

 This is a variant of the Zebra/Einstein Puzzle. You can probably Google
 for miniKanren core.logic zebra and find a solution if you get stuck ;)

 David


 On Tue, Jun 18, 2013 at 7:57 AM, Josh Kamau joshnet2...@gmail.com wrote:

 Hi ;

 I am trying to learn clojure core.logic. I have gone through some
 documentation on github by David Nolen.  I am now trying to solve this
 problem:  Anyone willing to do some practice can try and share the
 solution.

  *SOLVE THIS PROBLEM.*

 *The Diplomats at Muthaiga Estate*

 The facts essential to solving the problem - which can indeed be solved
 by combining deduction, analysis, and sheer persistence - are as follows.
 Givens

1.

There are five houses, each of a different colour and inhabited by
people of different nationalities, with different pets, drinks, and
pastimes.
2.

The English live in the Red house.
3.

The Spaniards own the Dog.
4.

Coffee is drunk in the Green house.
5.

The Ukrainians drink Tea.
6.

The Green house is immediately to the right (your right) of the Ivory
house.
7.

The Chess players own Snails.
8.

Scrabble is played in the Yellow house.
9.

Milk is drunk in the Middle house.
10.

The Norwegians live in the First house on the Left.
11.

People who play Cribbage live in the house next to the people who own
a pet Fox.
12.

Scrabble is played in the house next to the house where the Horse is
kept.
13.

The Bridge players drink Orange Juice.
14.

The Japanese play Monopoly.
15.

The Norwegians live next to the Blue house.





  *ANSWER THE FOLLOWING QUESTIONS*.

 Who drinks water? And who owns the Zebra?

 1. The WATER drinkers are:

1.

*English http://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
2.

*Spaniardshttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
3.

*Norwegianshttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*
4.

*Japanesehttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
5.

I Give UP!! *Tell Me Who Drinks The 
 Waterhttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*

  2. Who owns the Zebra?

1.

*English http://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
2.

*Spaniardshttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
3.

*Norwegianshttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*
4.

*Japanesehttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
5.

I Give UP!!! *Tell Me Who Drinks The Water And Who Owns The 
 Zebrahttp://www.brocku.ca/sdc/leadership/both_answers.php
*

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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: core logic

2013-06-19 Thread Josh Kamau
Piotr i will as soon as am done.

Josh


On Wed, Jun 19, 2013 at 11:26 AM, 良ϖ p2b@gmail.com wrote:

 Hello Josh, I would be glad you share your code :)

 Piotr


 2013/6/18 David Nolen dnolen.li...@gmail.com

 This is a variant of the Zebra/Einstein Puzzle. You can probably Google
 for miniKanren core.logic zebra and find a solution if you get stuck ;)

 David


 On Tue, Jun 18, 2013 at 7:57 AM, Josh Kamau joshnet2...@gmail.comwrote:

 Hi ;

 I am trying to learn clojure core.logic. I have gone through some
 documentation on github by David Nolen.  I am now trying to solve this
 problem:  Anyone willing to do some practice can try and share the
 solution.

  *SOLVE THIS PROBLEM.*

 *The Diplomats at Muthaiga Estate*

 The facts essential to solving the problem - which can indeed be solved
 by combining deduction, analysis, and sheer persistence - are as follows.
 Givens

1.

There are five houses, each of a different colour and inhabited by
people of different nationalities, with different pets, drinks, and
pastimes.
2.

The English live in the Red house.
3.

The Spaniards own the Dog.
4.

Coffee is drunk in the Green house.
5.

The Ukrainians drink Tea.
6.

The Green house is immediately to the right (your right) of the
Ivory house.
7.

The Chess players own Snails.
8.

Scrabble is played in the Yellow house.
9.

Milk is drunk in the Middle house.
10.

The Norwegians live in the First house on the Left.
11.

People who play Cribbage live in the house next to the people who
own a pet Fox.
12.

Scrabble is played in the house next to the house where the Horse is
kept.
13.

The Bridge players drink Orange Juice.
14.

The Japanese play Monopoly.
15.

The Norwegians live next to the Blue house.





  *ANSWER THE FOLLOWING QUESTIONS*.

 Who drinks water? And who owns the Zebra?

 1. The WATER drinkers are:

1.

*Englishhttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
2.

*Spaniardshttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
3.

*Norwegianshttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*
4.

*Japanesehttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
5.

I Give UP!! *Tell Me Who Drinks The 
 Waterhttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*

  2. Who owns the Zebra?

1.

*Englishhttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
2.

*Spaniardshttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
3.

*Norwegianshttp://www.brocku.ca/sdc/leadership/water_answer_page_1.php
*
4.

*Japanesehttp://www.brocku.ca/sdc/leadership/water_answer_page_2.php
*
5.

I Give UP!!! *Tell Me Who Drinks The Water And Who Owns The 
 Zebrahttp://www.brocku.ca/sdc/leadership/both_answers.php
*

  --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from 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
 

Namespace qualification of symbols

2013-06-19 Thread Phillip Lord



So, I was thinking that ' and ` were basically the same, unless a ~ was
involved somewhere. But I have discovered this.



(ns john)

(println '(paul))
(println `(paul))


;;=
(paul)
(john/paul)

With the ' paul is not namespace qualified, while with the ` paul is.


Turns out to be a bit of a pain, actually, although I have worked around
it. But mostly I am surprised. Is this expected?

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: 'foldcat' slower than 'mapv' even for 10,000 elements

2013-06-19 Thread Jim
I know I promised a representative example yesterday and didn't 
deliver...let's try it now even though I'm outside the comfort of my own 
house/desktop...


Right ,we're gonna need a single external dependency which I propose we 
dynamically load via pomegranate. like so:


(use '[cemerick.pomegranate :only (add-dependencies)])
(add-dependencies :coordinates '[[org.apache.lucene/lucene-snowball 
3.0.3]]
  :repositories (merge 
cemerick.pomegranate.aether/maven-central {clojars 
http://clojars.org/repo}))

(import '[org.tartarus.snowball.ext EnglishStemmer]) ;;english ony

(defn porter-stemmer  ;;NEED THIS TO COMPILE
Depending on lang, returns the appropriate porter-stemmer instance. 
Using Snowball underneath.

Supported languages include the following:
[danish, french, italian, spanish dutch, german, english, romanian, 
turkish, finnish, hungarian, russian, swedish, norwegian, portugese]
If the language you specified does not match anything, an instance of 
the english stemmer will be returned.

^org.tartarus.snowball.SnowballProgram
[^String lang]
(case lang
   english (EnglishStemmer.)  ;;there are actually more langs but 
removed them or simplicity

 (EnglishStemmer.)) )

(defn porter-stem A function that stems words using Porter's algorithm.
(^String [^String s lang-or-stemmer]
 (let [^org.tartarus.snowball.SnowballProgram stemmer
(cond- lang-or-stemmer
 (string? lang-or-stemmer) (porter-stemmer))] ;if a 
stemmer object was passed in, use it!

   (.getCurrent
  (doto stemmer
(.setCurrent s)
.stem
([ss] ;;a collection?
  (mapv #(porter-stem % english) ss)) )


(def words (- [eating drinking dancing]
 cycle
 (take 1)
 vec))

(defn mapv-res []
  (time (porter-stem words)))

(defn foldcat-res []
  (time  (into [] (r/foldcat (r/map #(porter-stem % english) words )

After letting the jvm warm up a bit I am getting:

Elapsed time: 68.498756 msecs for mapv
Elapsed time: 49.066978 msecs for foldcat (!!!)


HmmI think I see what was happening 2 days ago...when measuring 
'mapv' I'd like to reuse the same Object as everything happens serially 
(no danger). However when measuring foldcat I must create a new stemmer 
object for every single word and then throw it out because there is 
parallelism.


I tried foldcat with the same stemmer-object and everything went fine! 
I'm pretty sure the stemmer objects are not thread-safe...how am I able 
to use the same object from separate threads on different words?  I was 
expecting seriously broken behaviour but everythig went smoothly...



Jim





On 19/06/13 08:14, Alan Busby wrote:


On Wed, Jun 19, 2013 at 4:03 PM, Tassilo Horn t...@gnu.org 
mailto:t...@gnu.org wrote:


I might be wrong, but I think reducers are only faster in situations
where you bash many filters/maps/mapcats/etc on top of each other.


Or use fold on a large vector with a multi-core machine.

You might try fold-into-vec to see if there is any difference;

(defn fold-into-vec [coll]

Provided a reducer, concatenate into a vector. Note: same as (into [] 
coll), but parallel.


(r/fold (r/monoid into vector) conj coll))



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

2013-06-19 Thread Jim

On 19/06/13 11:15, Jim wrote:

After letting the jvm warm up a bit I am getting:

Elapsed time: 68.498756 msecs for mapv
Elapsed time: 49.066978 msecs for foldcat (!!!)


HmmI think I see what was happening 2 days ago...when measuring 
'mapv' I'd like to reuse the same Object as everything happens 
serially (no danger). However when measuring foldcat I must create a 
new stemmer object for every single word and then throw it out because 
there is parallelism. 


or could it be that I have 4 cores at home but only 2 here? i anything 
I'd expect faster execution with 4 cores not sloweron the other hand 
maybe with 4 cores there are more concatenations going on...


or could I just be confusing my timings from 2 days ago? maybe...

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: Namespace qualification of symbols

2013-06-19 Thread Jim

On 19/06/13 09:46, Phillip Lord wrote:

With the ' paul is not namespace qualified, while with the ` paul is.


Turns out to be a bit of a pain, actually, although I have worked around
it. But mostly I am surprised. Is this expected?


Yes, this is very much expected! :)

How else would you be able to write macros without ` ?
Vars needs to resolve to something eventually...

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: 'foldcat' slower than 'mapv' even for 10,000 elements

2013-06-19 Thread Herwig Hochleitner
I've got a quadcore machine here:

user=   (c/bench (porter-stem words))
Evaluation count : 2220 in 60 samples of 37 calls.
 Execution time mean : *27.571133 ms*
Execution time std-deviation : 317.554208 mus
   Execution time lower quantile : 26.797791 ms ( 2.5%)
   Execution time upper quantile : 27.939500 ms (97.5%)
   Overhead used : 10.264005 ns

Found 4 outliers in 60 samples (6.6667 %)
low-severe  4 (6.6667 %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

user=   (c/bench  (into [] (r/foldcat (r/map #(porter-stem % english)
words
Evaluation count : 5880 in 60 samples of 98 calls.
 Execution time mean : *10.222315 ms*
Execution time std-deviation : 107.594094 mus
   Execution time lower quantile : 10.027915 ms ( 2.5%)
   Execution time upper quantile : 10.448660 ms (97.5%)
   Overhead used : 10.264005 ns

Found 3 outliers in 60 samples (5. %)
 low-severe 1 (1.6667 %)
low-mild 2 (3. %)
 Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

Everything seems in order.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Data vs API

2013-06-19 Thread dmirylenka
Great question and great answers, thank you.

Regarding (3),
what if want to process various customer order implementations (say, sort 
them) in a polymorphic way depending just on their total-price?
Assuming I do not control the implementations..

Is it ok in this case to define *HasTotalPrice* protocol (or 
*total-price*multimethod) and code against that?
Or is it better to accept a data structure
* along with *total-price-fn* function as an additional parameter?
* with :*total-price-fn* as a part of the data structure?
* with *:total-price* value already computed?

Thanks for any hints..

On Thursday, May 3, 2012 8:30:33 AM UTC+12, stuart@gmail.com wrote:

 I've read in some recent posts that Clorujians prefer data to APIs.  I'm 
 not sure I understand what this means, in practice.  When I'm in the early 
 stages of developing an application, the data structures undergo a great 
 deal of change.  One of the ways, I isolate parts of the code from these 
 sorts of changes is by writing accessor functions.  Maybe this is OO 
 thinking but it seems to me a wise application of DRY.  

 Would these accessor functions be considered an API?  If so, why should I 
 prefer accessing the raw data structure?  If not, what is constitutes an 
 API?


 (1) You always have to choose a representation for your data.

 (2) Having chosen a data representation, if you make an accessor function 
 API, you now have two representations. This is the very opposite of DRY. If 
 you think that the representation implied by the accessor functions is 
 better/more stable than the data representation, then choose a data 
 representation like the one implied by your accessor functions.

 (3) If you have helper functions for dealing with a particular 
 representation, those helpers can and should be separate from the 
 representation itself. For example, a customer order is some combination of 
 maps, vectors, etc.  totalPrice is never a member function of some 
 accessor-riddled Order object -- it is instead a plain function that knows 
 how to navigate a data representation (or, via a la carte polymorphism, 
 many different representations).

 Cheers,
 Stu


 Stuart Halloway
 Clojure/core
 http://clojure.com
  


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




anyone interested in authoring a book on Clojure for machine-learning ?

2013-06-19 Thread Jim

Hi all,

I was approached by a publishing company  last week and they proposed to 
me to author this book-title. Unfortunately, as soon as I mentioned this 
to my supervisor she completely flipped out! She is very much against me 
writing a book at this point in time, ad thus I've informed the 
publishers that I cannot proceed...


To that end, I'd like to throw this opportunity on the table in case 
someone else finds it interesting + feasible (without risking a 4-year 
degree!)...


I know several people have a solid background in machine-learning and of 
course Clojure. If anyone fancies this opportunity please let me know 
and I'll provide the contact details of the publisher. I cannot post 
them publicly for obvious reasons (they'd be flooded in emails) and in 
fact I was only told to forward the details to people that I know 
personally. I don't really know anyone from this list personally (I feel 
like I know many people but I 've never actually met anyone in person!), 
but I trust there will be at least some interest...


cheers,

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: New CSS library - Garden

2013-06-19 Thread JeremyS
Hi Joel,

Thank for the interest ! You can also take a look at some code have done 
around css unit types there https://github.com/JeremS/units. It's got 
arithmetic for 
units and a namespace dedicated to colors. In it you'll find conversions 
between rgb en hsl (that I have taken from the color 
libraryhttps://github.com/jolby/colors
)
and the implementation of SASS color helpers. May be you could adapt my 
library to garden. From what I have seen Garden uses
protocols to compile different types into css and every unit (including 
colors) I define is a record. So you might be able to extend my library 
with Garden protocols and use it in garden without much effort. I'd be glad 
to see that !

About higher order function I have thought about that and went back, my 
first approach made for to complicated function (complected even). With the 
actual implementation I can just define stuff like:

(def grid {}) ; grid spec with column, gutter...

(def width (partial grid/witdh grid))
(def push (partial grid/push grid))


and then :

(def side-style [:#side (width 4) 
(push 1)])

for a side element spanning onto 4 columns and pushed off 1.


Regarding more advanced systems like Foundation I haven't spent much time 
trying to implement them with my DSL.
To do so I need to up my CSS game because I am not yet well versed into the 
art of responsive design and it will take me
a bit of time wrapping my head around the media queries involved. If I try 
to got responsive, I might probably study 
the Unsemantic http://unsemantic.com system from the creator of the 960 
one I think.

Good luck with your work and don't hesitate on browsing my github, right 
now most of the projects are oriented around CSS and there 
might be some ideas there who knows ! 

On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:

 Jeremy,

 Looks good. I've been tinkering with grid systems on and off for the past 
 month or so. Have you thought of trying your hand at porting something like 
 the Foundation or Gumby grid system?

 One thing I've discovered, and you might try this with your 960 
 implementation, is that using higher order functions can be very handy for 
 building them out. For example, a *make-grid* function which accepts a 
 map of configuration options and returns a function which takes a column 
 number and optional parameters for, say, push and pull. It's a nice way to 
 package things up.

 I'm close to wrapping up a small colors framework for Garden which will be 
 available in the next beta (hopefully it won't be in beta much longer). 
 When I take it out of beta it'll probably include a Clojure flavored 
 implementation of either the grid system that ships with Bootstrap or 
 Foundation (including the mobile parts).

 On the side I've been taking of advantage of Clojure to create a new 
 concept for a *layout* system. It's based on the font-size/line-height 
 ratio and allows for the construction of stylesheets such that the grid 
 system and typography are harmonious. IOW it's a fat pain in the ass, but I 
 don't think I could even fathom the idea of doing it in Sass.

 TL;DR you have Clojure at your disposal! Though we're SOL on some very 
 nice Sass libraries, we can potentially do more and at a higher level!

 Thanks for sharing! It's inspiring.

 On Jun 18, 2013, at 4:41 AM, JeremyS jschof...@gmail.com javascript: 
 wrote:

 Hi Joel,

 I have a quick and dirty implementation of a 960-ish grid 
 systemhttps://github.com/JeremS/cljss-gridusing a DSL similar to garden If 
 you want to take a look.



 On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

 It's funny you should bring that up! I've actually been working on 
 extracting the grid system from Bootstrap and modular scale from 
 Foundation. But it's mostly been tinkering.

 *  I am sorely tempted to give this a try.*

 Please do! If I come up with something I'll be sure to share a Gist.


 On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach 
 cli...@dreisbach.uswrote:

 One interesting thing you could do, given both Garden and
 ClojureScript, is package CSS frameworks like Twitter Bootstrap or
 Zurb Foundation as a Clojure library. I am sorely tempted to give this
 a try.

 On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks cjhold...@gmail.com 
 wrote:
  Murtaza,
 
  Thanks for having a look at the library. I'll try to answer you 
 questions as
  best as I can.
 
 
  How does Garden compare to other pre processors such as sass and less?
 
  There are some similarities with Garden and other CSS preprocessors. 
 I've
  tried to bring over the ones I found most useful when using them. 
 Nested
  selectors and declarations, parent selector references, and unit 
 arithmetic
  are all currently available to stylesheet authors.
 
  The big difference and, in my opinion, the big win is you can build 
 your
  stylesheets with regular Clojure. This gives you a lot of power and 
 freedom
  you won't find 

Re: Graph API

2013-06-19 Thread Aysylu Biktimirova
If you'd like to take a stab at integrating your proposed protocol into 
Loom, I'd be happy to merge the changes. Thanks!

On Tuesday, June 18, 2013 1:12:04 PM UTC-4, Stephen Kockentiedt wrote:

 That sounds great! I'll mail you my complete code in case you want to take 
 a look at it or want to use parts of it. And in case I can help in any 
 other way, feel free to ask.

 Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:

 Stephen, thanks for reaching out to me! I really like your ideas and 
 agree with the issues you pointed out in Loom's API. I'd like to 
 incorporate your ideas into Loom to improve its API and have 1 graph 
 library in Clojure. I'm actively working on it and would be happy to 
 combine our efforts.

 There's one implementation of the API, as far as I know, 
 https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
 integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
 release as a separate project. Since I'm the author and the only maintainer 
 of Titanium+Loom, I'd be happy to handle the transition.

 On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:

 My bad. I did only find the original repository of loom and thought it 
 was abandoned. I should have taken more care while looking at it. My 
 approach was apparently the same in abstracting multiple graph 
 implementations under one API. However, I see some problems with Loom's 
 API, namely:

 1. The specifications of the protocol functions are very sparse. E.g., 
 which nodes shall a directed graph return from neighbors? Successors, 
 predecessors or both?
 2. How do I know if the graph implementation works by mutating the given 
 object or returning a new one?
 3. Loom assumes that every graph is editable. That is definitely not the 
 case.
 4. I think a protocol should be as easy to implement as possible. The 
 additional functionality can be given by functions relying on the protocol 
 functions. E.g., in the user API of my code, there is a function 
 direct-predecessors which provides this functionality (albeit slow) for 
 graph implementations which did not implement the corresponding protocol 
 function:

 (defn direct-predecessors
   Returns a set or sequence of all nodes n2 for which
(has-edge? g n2 n) returns true. May not contain
duplicates.
   [g n]
   (if (satisfies? p/PPredecessorGraph g)
 (p/direct-predecessors g n)
 (filter #(p/has-edge? g % n) (p/nodes g

 E.g., implementations of Loom's API need to provide two implementations 
 of neighbors and need to implement add-nodes* instead of only add-node*. 
 This may not be much more work to do. However, the easier the API, the more 
 implementations there will be.

 Please, don't get me wrong. I think that Loom is a great project, has 
 the same goals and, in terms of functionality, is way ahead of my efforts.

 Said all that, I definitely don't want there to be two competing graph 
 APIs. That would be counterproductive. I see the following possible 
 solutions:

 1. I keep the code to myself and let loom be the sole graph API.
 2. We transfer the advantages of my proposal to Loom and change its API. 
 Do you know of any implementations of the API outside Loom itself? If there 
 are none, this should be possible without much trouble. Also, the README 
 states that the API is alpha-stage.
 3. I publish my code and each API can be implemented in terms of the 
 other one. I'm not sure that this is possible in a simple way. Maybe each 
 protocol could be extended to java.lang.Object, which calls the 
 protocols of the other API, but I don't know if that is feasible.

 Please tell me what you think. I will also send Aysylu an email so that 
 she can chime in on the conversation.


 Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:

 Loom was indeed working on this, and it's a very nice library.  One 
 thing that I particularly liked about Justin's design, was the ability to 
 run a graph algorithm without worrying about conforming to a particular 
 graph representation.  See for example the bread first search function, 
 here:

 https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110

 All the bfs function requires is a neighbors function and and a start 
 vertex.  Simple and easy to use.

 Justin had said that he won't be actively developing loom for the 
 forseeable future; I was hoping to develop it further, but I only got as 
 far as implementing a max flow algorithm before the rest of my life got 
 in the way of my plans.  I know that Aysylu was doing a fair amount of 
 work 
 on loom, so I'd guess that her repo is the most advanced one.

 Stephen:
 I think the set of protocols above is good, better than Loom's in fact; 
 notably, the decision to make direct-predecessors optional is the correct 
 one, and a lot of graph libraries get that wrong.  

 If you want to compare how loom did it:
 

Re: anyone interested in authoring a book on Clojure for machine-learning ?

2013-06-19 Thread Mikera
Not sure who approached you, but I've also been approached by a couple of 
companies in this space and they are essentially scams / not serious 
publishers. For example, they apparently offer only about 16% royalty to 
the author, and do essentially no vetting or quality control. The fact that 
they decided on a title and only then go looking for authors via cold 
calling and referrals ought to be a warning sign 

I would of course be delighted to see more Clojure books in this space - 
but I encourage potential authors to go via a proper publisher (or self 
publish)

On Wednesday, 19 June 2013 12:01:40 UTC+1, Jim foo.bar wrote:

 Hi all, 

 I was approached by a publishing company  last week and they proposed to 
 me to author this book-title. Unfortunately, as soon as I mentioned this 
 to my supervisor she completely flipped out! She is very much against me 
 writing a book at this point in time, ad thus I've informed the 
 publishers that I cannot proceed... 

 To that end, I'd like to throw this opportunity on the table in case 
 someone else finds it interesting + feasible (without risking a 4-year 
 degree!)... 

 I know several people have a solid background in machine-learning and of 
 course Clojure. If anyone fancies this opportunity please let me know 
 and I'll provide the contact details of the publisher. I cannot post 
 them publicly for obvious reasons (they'd be flooded in emails) and in 
 fact I was only told to forward the details to people that I know 
 personally. I don't really know anyone from this list personally (I feel 
 like I know many people but I 've never actually met anyone in person!), 
 but I trust there will be at least some interest... 

 cheers, 

 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: anyone interested in authoring a book on Clojure for machine-learning ?

2013-06-19 Thread Jim

On 19/06/13 13:56, Mikera wrote:
Not sure who approached you, but I've also been approached by a couple 
of companies in this space and they are essentially scams / not 
serious publishers. For example, they apparently offer only about 16% 
royalty to the author, and do essentially no vetting or quality 
control. The fact that they decided on a title and only then go 
looking for authors via cold calling and referrals ought to be a 
warning sign 


Not that I'm disagreeing with you but the particular publishers are 
legit, meaning they are indeed technical book publishers (not 
text-books); they 've got a proper website and many titles published 
already. Of course, you saying that they offer 16% royalty to the author 
makes me suspicious as that is exactly the percentage I was 
offered...therefore, I can only conclude that you've been approached by 
the same people... I cannot express any opinions about vetting or 
quality control as I didn't go forward with this for the reasons 
mentioned earlier.



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 generates unnecessary and slow type-checks

2013-06-19 Thread Stuart Sierra
Jason Wolfe wrote:
 We thought we were being very careful

Sorry, didn't mean to imply that you weren't. ;)

It was me who wasn't careful: when I started investigating
this, I used a dead-code loop similar to the Gist I posted,
which made it look like Clojure 1.2 was much faster than
1.5. I guessed (incorrectly) that you had observed the same
effect for the same reasons.

-S


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




Re: Clojure in production

2013-06-19 Thread Stuart Sierra
Hi Plínio,

At Relevance, we use Clojure on many consulting projects for clients 
ranging from small startups to Fortune-500 companies.

Datomic, a database, is written primarily in Clojure.

http://thinkrelevance.com/
http://datomic.com/
http://clojure.com/

Good luck with your talk.

Thanks,
-S


On Monday, June 10, 2013 5:47:25 PM UTC-4, Plinio Balduino wrote:

 Hi there 

 I'm writing a talk about Clojure in the real world and I would like to 
 know, if possible, which companies are using Clojure for production or 
 to make internal tools. 

 Thank you 

 Plínio Balduino 


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




why is catch defined with bare symbols?

2013-06-19 Thread Ben Wolfson
It strikes me as a wart, albeit one that won't be much encountered, that
there's no good way to discriminate between the user-defined function
catch and the exception-catching magic symbol catch here:

user (defn kick [ o] (apply println kick the o))
#'user/kick
user (defn catch [ o] (apply println catch the o))
#'user/catch
user (try (kick ball) (catch Exception e 1))
kick the ball
nil
user (let [e 1] (try (kick Exception e 1) (+ 1 2) (catch Exception e 1)))
kick the java.lang.Exception 1 1
3
user (try (catch ball) (catch Exception e 1))
CompilerException java.lang.IllegalArgumentException: Unable to resolve
classname: ball, compiling:(NO_SOURCE_PATH:1)
user (let [e 1] (try (catch Exception e 1) (+ 1 2) (catch Exception e 1)))
CompilerException java.lang.RuntimeException: Only catch or finally clause
can follow catch in try expression, compiling:(NO_SOURCE_PATH:1)
user

There is *a* way (b):

user (try (user/catch ball) (catch Exception e 1))
catch the ball
nil

But it's not a very *good* way (c):

user (let [catch (fn [ o] (println actually, don't catch))] (try
(user/catch ball) (catch Exception e 1)))
catch the ball
nil

(b) works because try just looks for symbols whose first element is the
symbol catch. But the workaround fails for (c) because the let-bound
symbol isn't the same as the var named user/catch, so you end up with the
wrong thing.

If catch (and finally, I suppose) were defined in clojure.core, then the
parsing code for try could check, not that the first element of a form is
the symbol 'catch, but that it resolves to the var #'clojure.core/catch. (I
assume it could do that, anyway! It's implemented in Java in the compiler
and I'm not sure what information is available at that point.) Since
symbols from clojure.core are imported by default, in most cases it
wouldn't make a difference. But in cases like (a), (b), and (c), it would
allow for sane disambiguation.

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

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

2013-06-19 Thread A

Thought I'd mention a really nice Graph visualization library that I like. 
It would be great to include this into any new Graph library project.

https://github.com/pallix/lacij

From the readme:

Lacij is a graph visualization library written in Clojure. It allows the 
*display 
and the dynamic modification of graphs as SVG documents* that can be viewed 
with a *Web browser* or with a *Swing component*. Undo/redo is supported 
for the dynamic modification. Automatic layout is provided for the 
visualization.

I like graphviz too, but this might be a better fit.

Cheers,
Avram


On Wednesday, June 19, 2013 5:57:02 AM UTC-7, Aysylu Biktimirova wrote:

 If you'd like to take a stab at integrating your proposed protocol into 
 Loom, I'd be happy to merge the changes. Thanks!

 On Tuesday, June 18, 2013 1:12:04 PM UTC-4, Stephen Kockentiedt wrote:

 That sounds great! I'll mail you my complete code in case you want to 
 take a look at it or want to use parts of it. And in case I can help in any 
 other way, feel free to ask.

 Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:

 Stephen, thanks for reaching out to me! I really like your ideas and 
 agree with the issues you pointed out in Loom's API. I'd like to 
 incorporate your ideas into Loom to improve its API and have 1 graph 
 library in Clojure. I'm actively working on it and would be happy to 
 combine our efforts.

 There's one implementation of the API, as far as I know, 
 https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
 integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
 release as a separate project. Since I'm the author and the only maintainer 
 of Titanium+Loom, I'd be happy to handle the transition.

 On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:

 My bad. I did only find the original repository of loom and thought it 
 was abandoned. I should have taken more care while looking at it. My 
 approach was apparently the same in abstracting multiple graph 
 implementations under one API. However, I see some problems with Loom's 
 API, namely:

 1. The specifications of the protocol functions are very sparse. E.g., 
 which nodes shall a directed graph return from neighbors? Successors, 
 predecessors or both?
 2. How do I know if the graph implementation works by mutating the 
 given object or returning a new one?
 3. Loom assumes that every graph is editable. That is definitely not 
 the case.
 4. I think a protocol should be as easy to implement as possible. The 
 additional functionality can be given by functions relying on the protocol 
 functions. E.g., in the user API of my code, there is a function 
 direct-predecessors which provides this functionality (albeit slow) 
 for graph implementations which did not implement the corresponding 
 protocol function:

 (defn direct-predecessors
   Returns a set or sequence of all nodes n2 for which
(has-edge? g n2 n) returns true. May not contain
duplicates.
   [g n]
   (if (satisfies? p/PPredecessorGraph g)
 (p/direct-predecessors g n)
 (filter #(p/has-edge? g % n) (p/nodes g

 E.g., implementations of Loom's API need to provide two implementations 
 of neighbors and need to implement add-nodes* instead of only add-node*. 
 This may not be much more work to do. However, the easier the API, the 
 more 
 implementations there will be.

 Please, don't get me wrong. I think that Loom is a great project, has 
 the same goals and, in terms of functionality, is way ahead of my efforts.

 Said all that, I definitely don't want there to be two competing graph 
 APIs. That would be counterproductive. I see the following possible 
 solutions:

 1. I keep the code to myself and let loom be the sole graph API.
 2. We transfer the advantages of my proposal to Loom and change its 
 API. Do you know of any implementations of the API outside Loom itself? If 
 there are none, this should be possible without much trouble. Also, the 
 README states that the API is alpha-stage.
 3. I publish my code and each API can be implemented in terms of the 
 other one. I'm not sure that this is possible in a simple way. Maybe each 
 protocol could be extended to java.lang.Object, which calls the 
 protocols of the other API, but I don't know if that is feasible.

 Please tell me what you think. I will also send Aysylu an email so 
 that she can chime in on the conversation.


 Am Dienstag, 18. Juni 2013 07:02:52 UTC+2 schrieb Rob Lachlan:

 Loom was indeed working on this, and it's a very nice library.  One 
 thing that I particularly liked about Justin's design, was the ability to 
 run a graph algorithm without worrying about conforming to a particular 
 graph representation.  See for example the bread first search function, 
 here:

 https://github.com/jkk/loom/blob/master/src/loom/alg_generic.clj#L110

 All the bfs function requires is a neighbors function and and a start 
 vertex.  Simple and easy to use.

 

try* macro to catch multiple exception classes with one body. feedback is needed.

2013-06-19 Thread Max Gonzih
Hi, I implemented small macro to catch multiple exception classes with one 
body.

https://gist.github.com/Gonzih/5814945

What do you think? Are there better ways to achieve similar results?

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: Namespace qualification of symbols

2013-06-19 Thread Leon Barrett
Yes, it's expected, and if you need unqualified names you need to carefully
unquote and requote, e.g.

(defmacro def-a-fn [body]
  `(defn ~'a-fn  ;; you can only define unqualified names, I think
 [] ~@body))


On Wed, Jun 19, 2013 at 3:32 AM, Jim jimpil1...@gmail.com wrote:

 On 19/06/13 09:46, Phillip Lord wrote:

 With the ' paul is not namespace qualified, while with the ` paul is.


 Turns out to be a bit of a pain, actually, although I have worked around
 it. But mostly I am surprised. Is this expected?


 Yes, this is very much expected! :)

 How else would you be able to write macros without ` ?
 Vars needs to resolve to something eventually...

 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
 --- You received this message because you are subscribed to a topic in the
 Google Groups Clojure group.
 To unsubscribe from this topic, visit https://groups.google.com/d/**
 topic/clojure/a4Dp8gdHev8/**unsubscribehttps://groups.google.com/d/topic/clojure/a4Dp8gdHev8/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://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.




Software project estimation

2013-06-19 Thread Alan Thompson
Hi All,

I saw a nice summation of software project estimation and thought some of
you might like to view it:
http://agile.dzone.com/articles/estimating-unknown-dates-or

Enjoy!
Alan Thompson

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.




extending a protocol to arrays and handle nesting too

2013-06-19 Thread Jim - FooBar();

Hi again,

quick question:


Is it at all possible to extend a protocol to a particular primitive 
array type but also handle nesting of arrays? A double[] is not the same 
class as double[][] which in turn is not the same Class as double[][][] 
etc etc and there is no interface tying them together So this means 
I can't do the regular trick that I can do with any other Collection type.


example:

(defprotocol Normalisable
(normalise [this transformer]))

(extend-protocol Normalisable
Number
(normalise [this transform]
  (transform this))
String
(normalise [this stem]
  (stem this))

java.util.List ;;if this fires, we're dealing with a Java list-like 
collection - return a vector

(normalise [this transform]
(if (instance? java.util.Collection (first this)) ;;handle nesting at 
the top interface and pray that an extension-point for that type exists

(mapv #(normalise % transform) this)
 (let [top(delay (apply max this))
   bottom (delay (apply min this))]
   (mapv (fn [x] (normalise x #(transform % [top bottom]))) this))) )


and so forth for Collections... for arrays it's the same story (but with 
amap) but it will only work for 1d arrays. Extending to object-arrays, 
thinking that the outer array is an Object[], fails miserably. How on 
earth am I supposed to  handle nesting in a general way?


thanks in advance...

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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

2013-06-19 Thread alexi
Hi Stream,

I have resolved the problem you are referring to. See comment in the issue 
you have opened

https://github.com/apolenur/vert.x-mod-lang-clojure/issues/1

Regards, Alexi

On Monday, 17 June 2013 23:15:37 UTC-4, Stream wrote:



 在 2013年5月9日星期四UTC+8下午2时00分54秒,Stream写道:

 Hi all 

 i wanna change the classloader of Clojure RT. in 1.5.1 
 so , i try to 
 clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
 clojure.lang.Compiler.LOADER, cl) ); 

 but throws exception that cojure.lang.Compiler.LOADER is null 

 Caused by: java.lang.NullPointerException 
 at clojure.lang.RT.baseLoader(RT.java:2043) 
 at clojure.lang.RT.load(RT.java:417) 
 at clojure.lang.RT.load(RT.java:411) 
 at clojure.lang.RT.doInit(RT.java:447) 
 at clojure.lang.RT.clinit(RT.java:329) 
 ... 9 more 


 However this is work in the 1.4.0 

 someone could tell me what had happened in 1.5.1 
 thanks


 --

 Sorry , i have disappear a month for my own things..

 the problem is still hung. i don't how to resolve it , except back version 
 of clojure to 1.4.0

 The intention is that vertx project http://vertx.io/ use clojure as one 
 of scriptlang to execute some logical

 so, i have own classloader which is cl, could load any other lib of jar 
 dynamically.

 as @atkaaz desc, it seems  LOADER has set NULL. and reason @sean corfield 
 has given.

 i hope someone could give me a idea 

 thanks again.




  


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Potemkin 0.3.0

2013-06-19 Thread Zach Tellman
Potemkin [1] is a collection of facades and utilities that I've found 
helpful when writing larger-scale libraries or applications.  I've never 
formally announced it before, but I think it's gotten to the point where 
others can benefit from it.

A few highlights:

* 'def-map-type', which allows for the definition of custom map-like 
objects with 10x less code
* 'unify-gensyms', which allows for more concise nested syntax-quotes
* 'import-vars', which allows for code sprinkled across multiple namespaces 
to be exposed via a single namespace

It's been pointed out before that ideally a library should have no 
dependencies but Clojure itself, or we risk transitive dependency conflicts 
when everyone uses different versions of a utility library.  In deference 
to this, Potemkin is licensed such that any piece of code can be simply 
pasted into your library, as long as there's a comment describing the 
origin.

If anyone has questions, I'm happy to answer them.  If anyone has moral or 
aesthetic objections to 'import-vars', you're not alone, but please 
remember you're under no obligation to use it.

Zach

[1] https://github.com/ztellman/potemkin

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Potemkin 0.3.0

2013-06-19 Thread Zack Maril
We've been using Potemkin inside Titanium, Ogre, and Archimedes. It works 
well for importing functions, but I'm about to do a rewrite of Titanium and 
Ogre because of complications arising from being clever with importing 
dynamic vars. I would caution against trying to import dynamic vars (or 
functions that rely on dynamic vars) between libraries. 
-Zack

On Wednesday, June 19, 2013 3:12:41 PM UTC-4, Zach Tellman wrote:

 Potemkin [1] is a collection of facades and utilities that I've found 
 helpful when writing larger-scale libraries or applications.  I've never 
 formally announced it before, but I think it's gotten to the point where 
 others can benefit from it.

 A few highlights:

 * 'def-map-type', which allows for the definition of custom map-like 
 objects with 10x less code
 * 'unify-gensyms', which allows for more concise nested syntax-quotes
 * 'import-vars', which allows for code sprinkled across multiple 
 namespaces to be exposed via a single namespace

 It's been pointed out before that ideally a library should have no 
 dependencies but Clojure itself, or we risk transitive dependency conflicts 
 when everyone uses different versions of a utility library.  In deference 
 to this, Potemkin is licensed such that any piece of code can be simply 
 pasted into your library, as long as there's a comment describing the 
 origin.

 If anyone has questions, I'm happy to answer them.  If anyone has moral or 
 aesthetic objections to 'import-vars', you're not alone, but please 
 remember you're under no obligation to use it.

 Zach

 [1] https://github.com/ztellman/potemkin


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.




Loosing a space from an XML document

2013-06-19 Thread Stefan Kamphausen
Hi,


Recently I found myself searching for a white space which got lost 
somewhere between reading an XML file and presenting some results from that 
via a little webapp.  

I think, I could track it down to the following example:

user (clojure.pprint/pprint 
   (clojure.zip/xml-zip
(clojure.xml/parse 
 (java.io.ByteArrayInputStream. 
  (.getBytes
   root
  ok
spanHello /span spanWorld/span
  /ok
  ok
spanHello /span dear spanWorld/span
  /ok
  wheredidmyspacego
spanHello/span spanWorld/span
  /wheredidmyspacego
/root)

[{:tag :root,
  :attrs nil,
  :content
  [{:tag :ok,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content [Hello ]}
 {:tag :span, :attrs nil, :content [World]}]}
   {:tag :ok,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content [Hello ]}
  dear 
 {:tag :span, :attrs nil, :content [World]}]}
   {:tag :wheredidmyspacego,
:attrs nil,
:content
[{:tag :span, :attrs nil, :content [Hello]}
 {:tag :span, :attrs nil, :content [World]}]}]}
 nil]

Take a look at the last tag wheredidmyspacego.  The whitespace between 
the span tags gets lost whereas the  dear  in the second example is 
preserved including surrounding spaces.

Is this on purpose and/or expected behavior?


Regards,
Stefan

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Performance optimizations dealing with java collections

2013-06-19 Thread Tim Jones
That's it!  Thanks so much for the help!  In what cases is a function 
turned into a RestFn?  variadic clojure or vararg java?  I was confused 
about how clojure is turned into java, but things are a little clearer now.

(make-array) uses java.lang.reflect.Array.newInstance, which is bad as 
well.  I'm going to try and push this interpolation down into the java API.

On Tuesday, June 18, 2013 3:00:23 PM UTC-7, John Hume wrote:

 Offhand it looks like the only RestFn you call from filter-link is 
 clojure.core/format. Have you tried replacing that with something like this?

 (String/format (.get link 1) (doto (make-array String 1) (aset 0 (.get 
 link 2)))

 I'm not suggesting that's idiomatic, but if it addresses the issue then 
 you can focus on the difference and look for a happy medium.


 On Tue, Jun 18, 2013 at 4:10 PM, Tim Jones timoth...@hp.com javascript:
  wrote:


 (defn- filter-link 
   Format lang and cc into the link returned from the product.
   [^List link]
   [(.get link 0) (.get link 1) (.get link 2) (.get link 3)  
(- (.get link 4) 
(URLDecoder/decode UTF-8) 
(format (.get link 1) (.get link 2)))])

 (defn link-info
   Retrieve all link info from a product as a lazy-seq of vectors of 
 String.  The function
handles parameter substitution within the URL
   [^Product p]
   (map filter-link
(.getAllLinkInfo p @lib {h_lang %1$s h_cc %2$s})))



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




Factual is hiring Clojure developers

2013-06-19 Thread Zach Tellman
At Factual, we build and constantly refine a canonical index of real world 
entities: businesses, locations, and products [1].  We also provide ways 
for other data to be resolved against our index [2] [3], allowing our 
service to act as a join table for real-world entities, breaking down 
barriers between otherwise siloed data.  

This involves a wide variety of challenges in both data analysis and 
systems engineering, many of which we solve with Clojure [4].  Working at 
Factual, you have the opportunity to solve difficult problems using 
large-scale data, and to solve them well.  You can work alongside a number 
of smart, enthusiastic engineers to build, refine, and validate our data 
pipelines until the output is, well, factual.

Factual's headquarters are in LA, and we also have offices in the SF Bay 
Area.  Remote employment is possible, but usually only when the candidate 
has significant experience in a relevant area, and is considered on a 
case-by-case basis.  Anyone who's interested in learning more should feel 
free to contact me at z...@factual.com.

[1] http://www.factual.com/
[2] http://www.factual.com/data-apis/places/resolve
[3] http://www.factual.com/data-apis/places/crosswalk
[4] http://www.factual.com/jobs/clojure

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




Re: Namespace qualification of symbols

2013-06-19 Thread Colin Fleming
Thank you for this, you just fixed a bug for me :-)

I was trying to do some tricky type hinting with definline using amolloy's
great answer http://stackoverflow.com/a/11920022 on StackOverflow. Notice
that he uses `BufferedImage and not 'BufferedImage. I stupidly figured that
this was just a typo due to force of habit or similar and switched to using
quote, and discovered that I had problems when BufferedImage wasn't
imported when the inlined version of the function was called. Turns out
that ` expands an imported class name to the fully qualified name, whereas
' does not.

(import java.awt.image.BufferedImage)
= #=java.awt.image.BufferedImage
`BufferedImage
= java.awt.image.BufferedImage
'BufferedImage
= BufferedImage

Mea culpa. I'm not sure I would ever have made this connection, very timely
- thank you.

Cheers,
Colin


On 19 June 2013 20:46, Phillip Lord phillip.l...@newcastle.ac.uk wrote:




 So, I was thinking that ' and ` were basically the same, unless a ~ was
 involved somewhere. But I have discovered this.



 (ns john)

 (println '(paul))
 (println `(paul))


 ;;=
 (paul)
 (john/paul)

 With the ' paul is not namespace qualified, while with the ` paul is.


 Turns out to be a bit of a pain, actually, although I have worked around
 it. But mostly I am surprised. Is this expected?

 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.




-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Loosing a space from an XML document

2013-06-19 Thread Rob Day
On 19 June 2013 20:32, Stefan Kamphausen ska2...@gmail.com wrote:
 Take a look at the last tag wheredidmyspacego.  The whitespace between the
 span tags gets lost whereas the  dear  in the second example is preserved
 including surrounding spaces.

 Is this on purpose and/or expected behavior?

Stefan,

I think this is expected behaviour for XML as a whole: whitespace on
its own isn't preserved. If you look at your XML, it actually has lots
of whitespace other than the 'wheredidmyspacego' element - there's a
newline and fifteen spaces between root and ok which (quite
rightly) you don't expect to show up in the output. If whitespace on
its own were preserved, you wouldn't be able to use it to lay out your
XML like this.

See also http://www.usingxml.com/Basics/XmlSpace:

The document contains some white space that delimits various aspects
of the XML syntax. When the white space is part of the XML syntax, it
is discarded by XML parsers and not passed on to processing
applications. XML allows for unbounded white space wherever white
space is permitted in the XML syntax. This is useful for pretty
printing an XML document.

Rob

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: extending a protocol to arrays and handle nesting too

2013-06-19 Thread Cedric Greevey
I doubt you can extend it to all n-dimensional arrays of foo.

What you can do, though, is (defmacro add-support-for-dimension [n]
`(extend-protocol ...)) and document that users of your library should
invoke this macro once for each number of dimensions that will need
supporting. If that set's open-ended, they can construct and eval calls to
the macro at run time, though that's a bit icky, every time a new dimension
is first encountered.

If it's true that if you have a protocol extended to a class C and its
subclass S, and give it an S, it will always use the S specialization
rather than the C version, and more generally will use the most specific
extension that applies to the run-time type of an object, then you can
extend the protocol to Object and have the Object version test for an
array, handle that case generically, and throw an exception otherwise.

You could also petition for clojure to be amended to add dummy types for
x-dimensional arrays, arrays of foo, and x-dimensional arrays of foo
generally, so one could put something in extend-protocol to extend it to
all arrays of (ultimately) doubles or all three-dimensional arrays; but
clojure itself changes relatively slowly, so you'd likely have to wait a
year or two, if it ever did get done.



On Wed, Jun 19, 2013 at 1:59 PM, Jim - FooBar(); jimpil1...@gmail.comwrote:

 Hi again,

 quick question:


 Is it at all possible to extend a protocol to a particular primitive array
 type but also handle nesting of arrays? A double[] is not the same class as
 double[][] which in turn is not the same Class as double[][][] etc etc and
 there is no interface tying them together So this means I can't do the
 regular trick that I can do with any other Collection type.

 example:

 (defprotocol Normalisable
 (normalise [this transformer]))

 (extend-protocol Normalisable
 Number
 (normalise [this transform]
   (transform this))
 String
 (normalise [this stem]
   (stem this))

 java.util.List ;;if this fires, we're dealing with a Java list-like
 collection - return a vector
 (normalise [this transform]
 (if (instance? java.util.Collection (first this)) ;;handle nesting at the
 top interface and pray that an extension-point for that type exists
 (mapv #(normalise % transform) this)
  (let [top(delay (apply max this))
bottom (delay (apply min this))]
(mapv (fn [x] (normalise x #(transform % [top bottom]))) this))) )


 and so forth for Collections... for arrays it's the same story (but with
 amap) but it will only work for 1d arrays. Extending to object-arrays,
 thinking that the outer array is an Object[], fails miserably. How on earth
 am I supposed to  handle nesting in a general way?

 thanks in advance...

 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=enhttp://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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




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




Re: ANN: Potemkin 0.3.0

2013-06-19 Thread Matthew Chadwick


 If anyone has moral or aesthetic objections to 'import-vars', you're not 
 alone, but please remember you're under no obligation to use it.


I used lein-clique to make a graph of Lamina's 
dependencieshttps://github.com/Hendekagon/lein-clique/wiki/images/lamina-in-degree-huge.png(huge
 PNG), but the use of import-vars caused several mirrored subgraphs 
which I don't really know how to filter 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 in production

2013-06-19 Thread Wei Hsu

Hi Plinio, I used Clojure at Airtime last year to do load testing and 
deploy infrastructure. More recently, I'm using Clojure to build 
Bitcoin-related projects backed by bitcoinj, including this bitcoin 
scratcher game http://bitcoinscratch.com for fun.

On Monday, June 10, 2013 2:47:25 PM UTC-7, Plinio Balduino wrote:

 Hi there 

 I'm writing a talk about Clojure in the real world and I would like to 
 know, if possible, which companies are using Clojure for production or 
 to make internal tools. 

 Thank you 

 Plínio Balduino 


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Potemkin 0.3.0

2013-06-19 Thread Jason Wolfe
We're starting to use potemkin at Prismatic, and the part we've found most 
useful which Zach didn't mention in his post are the smart types. 
 Especially definterface+, which is like a love child of defprotocol and 
definterface:
 - Same syntax as defprotocol, and defines functions in your namespace that 
wrap the interface functions (without extend-protocol support, obviously)
 - Allows for primitive arguments and return values (like 
clojure.core/definterface), which are propagated to the wrapper functions 
for maximal performance
 - Doesn't re-evaluate if the body has not changed, which can make repl 
development less painful (especially when used with its defrecord+ 
counterpart).



On Wednesday, June 19, 2013 12:12:41 PM UTC-7, Zach Tellman wrote:

 Potemkin [1] is a collection of facades and utilities that I've found 
 helpful when writing larger-scale libraries or applications.  I've never 
 formally announced it before, but I think it's gotten to the point where 
 others can benefit from it.

 A few highlights:

 * 'def-map-type', which allows for the definition of custom map-like 
 objects with 10x less code
 * 'unify-gensyms', which allows for more concise nested syntax-quotes
 * 'import-vars', which allows for code sprinkled across multiple 
 namespaces to be exposed via a single namespace

 It's been pointed out before that ideally a library should have no 
 dependencies but Clojure itself, or we risk transitive dependency conflicts 
 when everyone uses different versions of a utility library.  In deference 
 to this, Potemkin is licensed such that any piece of code can be simply 
 pasted into your library, as long as there's a comment describing the 
 origin.

 If anyone has questions, I'm happy to answer them.  If anyone has moral or 
 aesthetic objections to 'import-vars', you're not alone, but please 
 remember you're under no obligation to use it.

 Zach

 [1] https://github.com/ztellman/potemkin


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: try* macro to catch multiple exception classes with one body. feedback is needed.

2013-06-19 Thread Meikel Brandmeyer (kotarak)
Hi,

Am Mittwoch, 19. Juni 2013 17:00:17 UTC+2 schrieb Max Gonzih:

 Hi, I implemented small macro to catch multiple exception classes with one 
 body.

 https://gist.github.com/Gonzih/5814945

 What do you think? Are there better ways to achieve similar results?


I would just extend try a simply as possible: simply add the catch-all, but 
keep catch and finally as is. Here my try:

(defmacro try*
  [ body]
  (let [catch-all?   #(and (seq? %) (= (first %) 'catch-all))
expand-catch (fn [[_catch-all exceptions  catch-tail]]
   (map #(list* 'catch % catch-tail) exceptions))
transform(fn [form]
   (if (catch-all? form)
 (expand-catch form)
 [form]))]
(cons `try (mapcat transform body

(try*
  (println :a)
  (println :b)
  (catch-all [A B C] e (println (type e)))
  (catch D _ (println Got D!))
  (finally (println Finally!)))

expands to

(try
  (println :a)
  (println :b)
  (catch A e (println (type e)))
  (catch B e (println (type e)))
  (catch C e (println (type e)))
  (catch D _ (println Got D!))
  (finally (println Finally!)))

Kind regards
Meikel

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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.