Re: Enlive questions

[Christophe Grand]

David Nolen a écrit :
 Sorry to bombard but I couldn't get attr? or attr= to work inside the 
 selector:

 (deftemplate my-app4 app.html
   [widgets]
   [:div '(attr? :tiptree:replace)] (content bar))
 (apply str (my-app4 {}))

 (deftemplate my-app4 app.html
   [widgets]
   [[:div '(attr? :tiptree:replace)]] (content bar))
 (apply str (my-app4 {}))

 Neither forms worked for me. I messed around with the enlive code 
 itself for quite a bit trying to understand what was going on under 
 the hood but to no avail.

I'll lift the need to quote predicates. I'm worried about 
:tiptree:replace, are you using namespaces?
[:div '(attr? :foo :bar)] is equivalent to div *[foo][bar]
[[:div '(attr? :foo :bar)]] is equivalent to div[foo][bar]


-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)



--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Enlive questions

[Christophe Grand]

David Nolen a écrit :
 One early thought, would you like me to extend the number of examples? 
 I'm really getting into the nitty gritty of what's possible with 
 Enlive and it would be nice to have a relatively informative list of 
 possibilities distributed with the library vs. the single example 
 that's in there right now ;)

With pleasure!

-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (en)



--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[dysinger]

+1 I said the same thing on IRC

On Apr 14, 11:27 am, Mark Reid mark.r...@gmail.com wrote:
 Hi,

 I'm not sure if this is relevant to this discussion but, as a
 newcomer, I was puzzled by the organisation of the clojure-contrib
 source.

 Why, for example, are ClojureCLR and clojurescript at the top of the
 trunk? Shouldn't these be in separate projects?

 Regards,

 Mark.
 --http://mark.reid.name/

 On Apr 14, 10:19 pm, Rich Hickey richhic...@gmail.com wrote:

  I've been thinking recently about contribs with dependencies.

  I think it's very important to have layers - e.g. core depends only on
  JDK 1.5, contrib only on core. Lately there have been some ideas
  centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
  etc.

  I'd like to start a discussion about how best to support the
  contributions of libraries that depend on things not in the JDK.

  Obviously, without care and rules it could get crazy quickly, and I
  want to avoid the kitchen-sink effect. It is very important that
  things remain [truly, not just apparently] simple.

  Looking for suggestions,

  Rich


--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

already-discussed vimclojure startup problem - what to do?

[Sigrid]

Hi,

I'm just starting with clojure and want to use vimclojure for
development. I have an error on startup that has been discussed here
in March:

Error detected while processing function
vimclojure#ExecuteNailWithInput:
line   23:
E605: Exception not caught: Couldn't execute Nail! Users/hunli/.vim/ng
de.kotka.vimclojure.nails.NamespaceOfFile /var/folders/Wi/
WiMZBjsvFC8Qt3WXZ35h7k+++TM/-Tmp-/v788213/0
Error detected while processing /Users/hunli/.vim/ftplugin/
clojure.vim:
line  131:
E171: Missing :endif
Error detected while processing function SNR8_LoadFTPlugin:
line   17:
E170: Missing :endfor

After reading the old thread, I am not sure what to do about this. I
have vim 7.2. on Mac OS Leopard and I understand that some people do
not have a problem there (so I needn't install another vim). If there
is something to do about the namespace, could someone please help with
a resume of what to do?
Btw in my clojure file no namespace is set, it's just

(defn hello [name] (str Hello,  name))

so it should be in the user namespace?

Thanks a lot for any help
Sigrid


--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Possible contrib contribution: clojure.contrib.timing

[Chris]

While playing around with clojure I've found the (time ...) macro
isn't as powerful as I'd like.  To fix this I made a timing library to
help me figure out where all my runtime is going.  If other people
find it useful I'd like to get it into contrib.

Simple overview of clojure.contrib.timing:

clojure.contrib.timing/with-timing
([expr {:name :timing-map}])
  Executes 'expr', returns result of expr, and records its time to
execute.  Each time to execute is saved for processing later.  This
allows you to get mean/median/mode/cumulative runtimes for the
expression.
- expr: The expression to evaluate
- name: value to name expression, defaults to (str expr).
  timing-map: Reference to a map of recorded timings.  Defaults to
the shared global *timings.

clojure.contrib.timing/analyze-timing
  Returns a hashmap of 'name' : '(analysis-func timing-list)'.  All
times are converted to milli seconds.  If timing-map is not given it
defaults to the shared global *timings*.
  ([analysis-func timing-map]

There are some other helper funcs/macros, but the above two are the
most important.  Future work here could give us a nice performance
timing library written in clojure, and powerful enough to allow
clojure programs to know how fast they are and tune themselves (think
serialized vs. parallelism, hostnames to connect to, etc...).

The timing-map is a ref to a map.  Each value is a list of every
runtime of the expression.  Every time the expression runs it's time-
to-run is cons-ed to the front of that expression's timing list.

Storing of the runtime into the ref is a side-effect of (with-
timing ...).  I was torn on this point, but I think it's the right
thing to do for now; performance is a side effect of code execution,
so it isn't that horrible for it to be stored as a side-effect.  This
is how the original (time ...) macro works; it reports the runtime to
stdout instead of returning it.

I'm not sure what the protocol here is for getting this thing out for
review and possible inclusion.  Is anyone interested?  How do I get my
changes out there for people to review?

Thanks!
 Chris

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: What is the difference between :type and :tag metadata?

[Rich Hickey]

On Apr 14, 11:11 am, Stuart Sierra the.stuart.sie...@gmail.com
wrote:
 On Apr 13, 9:12 pm, Rich Hickey richhic...@gmail.com wrote:

  :tagis applied to source forms to communicatetypehints to the
  compiler. :typecan be used, by convention, to add 'typenames' to
  runtime data structures that support metadata. Thetypefunction will
  return the :typemetadata if present, else the class, making it a
  handy dispatch function. Neither :tagnor :typeare used directly by
  isa?

 What about using maps as structured records, with a special key for
 the class.  Some people use :tagas the class key, some
 use :type.  Should this be stored in metadata, rather than in the map
 itself?


That's an open question. There are many reasons it is better as a
normal key. The arguments for being metadata are:

It allows for things other than maps to have 'types'
It doesn't impact equality
It doesn't appear as a 'field' to other code

Advantages to having it be a map key/attribute:

That's really what type/class is, another attribute, thus only things
that have attributes (maps) should have it.
It will impact equality*
It will appear as a 'field' to other code, in particular things like
Datalog

* - a key issue here is that only exact type equality is supported.

I'm leaning towards the latter camp as I see more use cases.

Rich
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: What is the difference between :type and :tag metadata?

[Konrad Hinsen]

On Apr 15, 2009, at 13:31, Rich Hickey wrote:

 That's an open question. There are many reasons it is better as a
 normal key. The arguments for being metadata are:

 It allows for things other than maps to have 'types'
 It doesn't impact equality
 It doesn't appear as a 'field' to other code

 Advantages to having it be a map key/attribute:

 That's really what type/class is, another attribute, thus only things
 that have attributes (maps) should have it.
 It will impact equality*
 It will appear as a 'field' to other code, in particular things like
 Datalog

 * - a key issue here is that only exact type equality is supported.

I found a couple of situations where a third choice is preferable:  
put type-related information both in the metadata and in the map  
itself. In all these situations, the main reason is the impact on  
equality, and usually the type information in the metadata is not the  
same as the type information in the map itself.

As an example, take algebraic data types as defined in  
clojure.contrib.types. A simple binary tree structure can be defined  
with

(defadt ::tree
   empty-tree
   (leaf value)
   (node left-tree right-tree))

Values of this type are represented as maps in which the value  
associated with :clojure.contrib.types/tag is the constructor (`empty- 
tree, `leaf, or `node), with the :type in the metadata being ::tree.  
This double labelling makes sure that all tree values are recognized  
as being of the same type in dispatching, but also that equality  
tests take into account the constructor in addition to its arguments.

Note that there is no need here to have the type ::tree as part of  
the value, as it is impossible to create two different types with  
identical constructor names in the same namespace (the constructor  
names are interned via def) and both the type tag and the constructor  
names are namespace qualified. The only way to make a data item equal  
to a ::tree value would be to construct explicitly a map containing  
the namespace-qualified key :clojure.contrib.types/tag, which I would  
call a malicious attempt to break something.

In this example, the type information for equality is more specific  
than the type information for dispatching, but there are also  
situations in which the opposite is required. Both are simple to  
implement in Clojure.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: already-discussed vimclojure startup problem - what to do?

[Meikel Brandmeyer]

Hi,

Am 15.04.2009 um 11:37 schrieb Sigrid:


I'm just starting with clojure and want to use vimclojure for
development. I have an error on startup that has been discussed here
in March:

Error detected while processing function
vimclojure#ExecuteNailWithInput:
line   23:
E605: Exception not caught: Couldn't execute Nail! Users/hunli/.vim/ng
de.kotka.vimclojure.nails.NamespaceOfFile /var/folders/Wi/
WiMZBjsvFC8Qt3WXZ35h7k+++TM/-Tmp-/v788213/0
Error detected while processing /Users/hunli/.vim/ftplugin/
clojure.vim:
line  131:
E171: Missing :endif
Error detected while processing function SNR8_LoadFTPlugin:
line   17:
E170: Missing :endfor

After reading the old thread, I am not sure what to do about this. I
have vim 7.2. on Mac OS Leopard and I understand that some people do
not have a problem there (so I needn't install another vim). If there
is something to do about the namespace, could someone please help with
a resume of what to do?


People reported problems with the stock vim delivered with OS X.
I strongly recommend to use MacVim[1]. That works without problems
for me.

Otherwise you might want to try to run the command manually to check
that the server runs properly. Just try:
ng de.kotka.vimclojure.nails.NamespaceOfFile  source.clj

Check if this answers with some Exception or whether it returns user.


Btw in my clojure file no namespace is set, it's just

(defn hello [name] (str Hello,  name))

so it should be in the user namespace?


Yes. Files without ns or in-ns form are considered to be in the
user namespace.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: What is the difference between :type and :tag metadata?

[Meikel Brandmeyer]

Hi,

Am 15.04.2009 um 14:04 schrieb Konrad Hinsen:


As an example, take algebraic data types as defined in
clojure.contrib.types. A simple binary tree structure can be defined
with

(defadt ::tree
  empty-tree
  (leaf value)
  (node left-tree right-tree))

Values of this type are represented as maps in which the value
associated with :clojure.contrib.types/tag is the constructor (`empty-
tree, `leaf, or `node), with the :type in the metadata being ::tree.
This double labelling makes sure that all tree values are recognized
as being of the same type in dispatching, but also that equality
tests take into account the constructor in addition to its arguments.


Maybe I'm missing something, but we can't you just derive
::leaf, ::empty-tree and ::node from ::tree? You can use ::tree in
dispatch values, but the map still contains the constructor...

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

already-discussed vimclojure startup problem - what to do?

[Sigrid]

Hi,

I'm just starting with clojure and want to use vimclojure for
development. I have an error on startup that has been discussed here
in March:

Error detected while processing function
vimclojure#ExecuteNailWithInput:
line   23:
E605: Exception not caught: Couldn't execute Nail! Users/hunli/.vim/ng
de.kotka.vimclojure.nails.NamespaceOfFile /var/folders/Wi/
WiMZBjsvFC8Qt3WXZ35h7k+++TM/-Tmp-/v788213/0
Error detected while processing /Users/hunli/.vim/ftplugin/
clojure.vim:
line  131:
E171: Missing :endif
Error detected while processing function SNR8_LoadFTPlugin:
line   17:
E170: Missing :endfor

After reading the old thread, I am not sure what to do about this. I
have vim 7.2. on Mac OS Leopard and I understand that some people do
not have a problem there (so I needn't install another vim). If there
is something to do about the namespace, could someone please help with
a resume of what to do?
Btw in my clojure file no namespace is set, it's just

(defn hello [name] (str Hello,  name))

so it should be in the user namespace?

Thanks a lot for any help
Sigrid

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: What is the difference between :type and :tag metadata?

[Konrad Hinsen]

On Apr 15, 2009, at 14:28, Meikel Brandmeyer wrote:

 As an example, take algebraic data types as defined in
 clojure.contrib.types. A simple binary tree structure can be defined
 with

 (defadt ::tree
   empty-tree
   (leaf value)
   (node left-tree right-tree))

 Values of this type are represented as maps in which the value
 associated with :clojure.contrib.types/tag is the constructor  
 (`empty-
 tree, `leaf, or `node), with the :type in the metadata being ::tree.
 This double labelling makes sure that all tree values are recognized
 as being of the same type in dispatching, but also that equality
 tests take into account the constructor in addition to its arguments.

 Maybe I'm missing something, but we can't you just derive
 ::leaf, ::empty-tree and ::node from ::tree? You can use ::tree in
 dispatch values, but the map still contains the constructor...

I could give each constructor a separate type and derive them all  
from the base type. That would blow up the hierarchy with lots of  
types that are not really needed for dispatching, but in this  
situation it is an implementation option.

In the opposite scenario, where types ::b and ::c derive from ::a but  
all varieties of ::a should test as equal, this option is no longer  
there: you have to put ::a in the data and ::b or ::c in the  
metadata. I thus prefer to consider dispatching and equality testing  
entirely independent, which lead me to choose the arrangement I  
described for algebraic data types.

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: ATTN contrib authors: Automatic documentation for clojure.contib

[Sean Devlin]

Check out the thread below in the Compojure group.  Specifically, look
for the comment by Brain Carper

http://groups.google.com/group/compojure/browse_thread/thread/67d92ceb4128a375?hl=en

Brian's code:

http://briancarper.net/clojure/compojure-doc.clj

This might be an alternate approach to the problem.

On Apr 14, 5:59 pm, Tom Faulhaber tomfaulha...@gmail.com wrote:
 Jason,

 Thanks for the offer. I may take you up on it as I get this into
 production such as it is.

 Sean,

 Nothing that I found in contrib (but who knows, there's no
 documentation :-)). Rich posted some code (which I'm using in a
 modified version in the center of things) for doing the API paage for
 clojure.org here:http://paste.lisp.org/display/77339

 When I get my code looking anything other than nasty (and anyone who's
 looked at pprint knows that's a low bar!), I'll at least put it up on
 github. Eventually I may add it to contrib, too, if the community
 feels it should go (but let's solve the problem ahead of us).

 Laurent,

 You seem to be going in the opposite direction from Konrad and I would
 worry about the duplication. I would be more inclined to think about a
 single markup format for :doc strings that could be converted for the
 various uses. But that's really a language change at some level, so
 I'd rather defer that until we see how this stuff is used.

 But to be honest, I haven't read your comments that closely because
 today has been a long day. Maybe later tonight...

 Thanks for all the feedback, guys!

 Tom
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Possible contrib contribution: clojure.contrib.timing

[Sean Devlin]

Start by putting your code on github or something similar :)

On Apr 14, 8:01 pm, Chris ccons...@gmail.com wrote:
 While playing around with clojure I've found the (time ...) macro
 isn't as powerful as I'd like.  To fix this I made a timing library to
 help me figure out where all my runtime is going.  If other people
 find it useful I'd like to get it into contrib.

 Simple overview of clojure.contrib.timing:

 clojure.contrib.timing/with-timing
 ([expr {:name :timing-map}])
   Executes 'expr', returns result of expr, and records its time to
 execute.  Each time to execute is saved for processing later.  This
 allows you to get mean/median/mode/cumulative runtimes for the
 expression.
     - expr: The expression to evaluate
     - name: value to name expression, defaults to (str expr).
       timing-map: Reference to a map of recorded timings.  Defaults to
 the shared global *timings.

 clojure.contrib.timing/analyze-timing
   Returns a hashmap of 'name' : '(analysis-func timing-list)'.  All
 times are converted to milli seconds.  If timing-map is not given it
 defaults to the shared global *timings*.
   ([analysis-func timing-map]

 There are some other helper funcs/macros, but the above two are the
 most important.  Future work here could give us a nice performance
 timing library written in clojure, and powerful enough to allow
 clojure programs to know how fast they are and tune themselves (think
 serialized vs. parallelism, hostnames to connect to, etc...).

 The timing-map is a ref to a map.  Each value is a list of every
 runtime of the expression.  Every time the expression runs it's time-
 to-run is cons-ed to the front of that expression's timing list.

 Storing of the runtime into the ref is a side-effect of (with-
 timing ...).  I was torn on this point, but I think it's the right
 thing to do for now; performance is a side effect of code execution,
 so it isn't that horrible for it to be stored as a side-effect.  This
 is how the original (time ...) macro works; it reports the runtime to
 stdout instead of returning it.

 I'm not sure what the protocol here is for getting this thing out for
 review and possible inclusion.  Is anyone interested?  How do I get my
 changes out there for people to review?

 Thanks!
  Chris
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Clojure blog - Destructuring binding in def

[NarayanS]

Recently I had written some codes which my colleagues suggested should
be put in a blog. So i have created a new blog for adding my two cents
to the wonderful world of clojure.

http://clojure101.blogspot.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
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
-~--~~~~--~~--~--~---

Re: How to abort a long running operation at the SLIME REPL?

[Chouser]

On Mar 17, 11:56 pm, gdscott gavindsc...@gmail.com wrote:

 One final note -- start-handling-break resets the break-threads map to
 {} every time it is called, meaning that add-break-thread! effectively
 sets the thread its called on as the *only* thread to have a break.
 Is that a bug?

Yep, thanks for the report.

Fixed in contrib 669

--Chouser
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[e]

i'd like to see a migration process where by contribs that turn out to be
core make it to the core.  Think about newbies that are used to installing
one thing (a language) and getting quite a bit of obviously useful stuff.
The more central (the more other contribs dependent on it) the higher the
priority on reviewing it and getting it into the core.

On Tue, Apr 14, 2009 at 2:02 PM, Howard Lewis Ship hls...@gmail.com wrote:


 I'd say to refactor clojure-contrib into a number of seperate modules;
 individual modules (each with its own pom) could have their own
 dependencies. Thus if you choose clojure-contrib-freechart, you get
 that JAR (or compiled Clojure sources) plus the jfreechart dependency.

 In this way you are using the good part of Maven: transitive
 dependency management.

 On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey richhic...@gmail.com wrote:
 
  I've been thinking recently about contribs with dependencies.
 
  I think it's very important to have layers - e.g. core depends only on
  JDK 1.5, contrib only on core. Lately there have been some ideas
  centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
  etc.
 
  I'd like to start a discussion about how best to support the
  contributions of libraries that depend on things not in the JDK.
 
  Obviously, without care and rules it could get crazy quickly, and I
  want to avoid the kitchen-sink effect. It is very important that
  things remain [truly, not just apparently] simple.
 
  Looking for suggestions,
 
  Rich
 
  
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry
 Director of Open Source Technology at Formos

 


--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Clojure blog - Destructuring binding in def

[NarayanS]

Sorry the subject of my previous post was not what was in the message
body:

Here is the link to the destructuring binding in def which i find
useful sometimes when debugging a function in repl:

http://clojure101.blogspot.com/2009/04/destructuring-binding-support-in-def.html

On Apr 15, 11:05 am, NarayanS snaray...@gmail.com wrote:
 Recently I had written some codes which my colleagues suggested should
 be put in a blog. So i have created a new blog for adding my two cents
 to the wonderful world of clojure.

 http://clojure101.blogspot.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
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
-~--~~~~--~~--~--~---

Monads tutorial

[jim]

I've just posted a tutorial on using monads in Clojure at

http://intensivesystems.net/tutorials/monads_101.html

It's one big chunk of text since I haven't had time to break it up
yet. It's also kind of rough, so if you see any typos, misspellings,
errors, etc., post 'em here.  Comments as well.

Thanks,
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
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
-~--~~~~--~~--~--~---

VimClojure 2.1.0 released

[Meikel Brandmeyer]

Dear vimming Clojurians,

I proudly present release 2.1.0 of VimClojure. It needs Clojure rev =  
1349 and Contrib rev = 650


New features include:
* improved completion (context sensitive, imported classes, aliases,  
static class members)

* goto source (by virtue of revision 1349 of clojure)
* show source (by virtue of c.c.repl-utils/source command)
* stacktrace short-cuts for the Repl (by virtue of c.c.stacktrace)
* dynamic syntax highlighting for use'd and alias'd namespaces
* pretty printing of macros expansions (by virtue of c.c.pprint)

Improvements:
* more robust in case of not running server (you at any moment start  
the server and do a :e to get the full functionality)
* improved error messages (the error of a failing nail is included in  
the message, for better solution finding)
* improved build system with optional Ivy dependency resolution  
(optionally Ivy may be used to retrieve a known working set of clojure  
and contrib)
* simplification of plugin installation procedure (the vim files may  
be installed via an ant task, no manual copy anymore)


Fixed many bugs, in particular:
* resizing windows when executing nails
* EvalToplevel evaluated more than one expression
* Line and File number information is now 100% correct when sending  
expressions


The release may be found at the usual places:
  http://www.vim.org/scripts/script.php?script_id=2501
  http://bitbucket.org/kotarak/vimclojure (the default branch)

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Got a Clojure user group?

[Amit Rathore]

Hi Rich,

Bay Area Clojure User Group
http://www.meetup.com/The-Bay-Area-Clojure-User-Group/

Thanks!

Regards,
Amit Rathore.

On Apr 9, 12:00 pm, Rich Hickey richhic...@gmail.com wrote:
 Got a Clojure user group, meetup etc?

 Reply to this message and let me know, I'll add them to the Clojure
 site.

 Please supply a primary URL for getting info for your group.

 Thanks!

 Rich
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[rzeze...@gmail.com]

My .02 cents...

I always viewed Contrib as an incubator of sorts for Core.  That it
was simply a testing ground for functionality that *MIGHT* make it
into Core if enough people find it useful, or Rich hands down his good
graces.

Requiring a few external libs here and there, and breaking Contrib up
into modules may sound simple to some, but I think your quickly
forgetting the additional cognitive load of such a decision.

If we go the simple route and just require the user to download the
libs, then it starts out all well and good, but will quickly turn into
dependency hell.  Anyone whose been using Linux long enough, or still
uses a distro like Slackware knows exactly what I'm talking about.
IMO, this is just *NOT* and option.

If we create some build or module system around Contrib, we alleviate
the dependency problem, but add complexity to the layout/build of
Contrib.  I'm not saying it's a lot, but there is some form of
complexity added for sure.  I'm just not sure if Contrib needs such
complexity?  Is it really in the essence of Contrib to store all
these Clojure libs?  Is that it's purpose?

IMO, Contrib is just a way for Rich to allow user contribution to
Clojure, without creating havoc on the development of Clojure proper.
Often times when someone post a useful function on this group and
asks to add it to Core, the response is a unanimous Add it to Contrib
and see where it goes from there.  This allows Clojure to grow
without Rich reading every single contribution because he can rely on
community around Contrib to make sound decisions.  I believe, if you
allow 3rd party libs to penetrate Contrib, then you must allow the
same libs to penetrate Clojure itself.  To flip it the other way, I
think the only deps Contrib should be allowed are the deps used by
Core.

I think Contirb should remain a breeding ground for Core (if that is
indeed its current purpose), and should remain as dead simple and
dependency free as possible!  I think Clojure libs which require 3rd
party deps should be left to their own devices for now.  The
unification of those can be solved by some build/dependency tool.

Maybe there should be a 3rd project called clojure-extensions?  This
could rely on core, clojure-contrib and any number of 3rd party deps.
I do admit, though, that might confuse beginners more than a
modularized Contrib.

Sorry if I missed the point of this thread, but I thought the question
should be asked.  What is the purpose of Contrib?

P.S.  I don't want to get off-track, but I also don't understand why
ClojureCLR or clojurescript are included in Contrib.  I also don't
understand why test files are not under their own top level dir?  I
think that is a good convention and allows for easier tooling.  OK,
I'll shut up now.

On Apr 15, 4:01 am, dysinger dysin...@gmail.com wrote:
 +1 I said the same thing on IRC

 On Apr 14, 11:27 am, Mark Reid mark.r...@gmail.com wrote:

  Hi,

  I'm not sure if this is relevant to this discussion but, as a
  newcomer, I was puzzled by the organisation of the clojure-contrib
  source.

  Why, for example, are ClojureCLR and clojurescript at the top of the
  trunk? Shouldn't these be in separate projects?

  Regards,

  Mark.
  --http://mark.reid.name/

  On Apr 14, 10:19 pm, Rich Hickey richhic...@gmail.com wrote:

   I've been thinking recently about contribs with dependencies.

   I think it's very important to have layers - e.g. core depends only on
   JDK 1.5, contrib only on core. Lately there have been some ideas
   centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
   etc.

   I'd like to start a discussion about how best to support the
   contributions of libraries that depend on things not in the JDK.

   Obviously, without care and rules it could get crazy quickly, and I
   want to avoid the kitchen-sink effect. It is very important that
   things remain [truly, not just apparently] simple.

   Looking for suggestions,

   Rich
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Comment from a friend

[jim]

 On another note, closure is misspelled.  If intentional, it should be more 
 like clothure since it is Lisp.  :)

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[rzeze...@gmail.com]

My .02 cents...

I always viewed Contrib as an incubator of sorts for Core.  That it
was simply a testing ground for functionality that *MIGHT* make it
into Core if enough people find it useful, or Rich hands down his good
graces.

Requiring a few external libs here and there, and breaking Contrib up
into modules may sound simple to some, but I think your quickly
forgetting the additional cognitive load of such a decision.

If we go the simple route and just require the user to download the
libs, then it starts out all well and good, but will quickly turn into
dependency hell.  Anyone whose been using Linux long enough, or still
uses a distro like Slackware knows exactly what I'm talking about.
IMO, this is just *NOT* and option.

If we create some build or module system around Contrib, we alleviate
the dependency problem, but add complexity to the layout/build of
Contrib.  I'm not saying it's a lot, but there is some form of
complexity added for sure.  I'm just not sure if Contrib needs such
complexity?  Is it really in the essence of Contrib to store all
these Clojure libs?  Is that it's purpose?

IMO, Contrib is just a way for Rich to allow user contribution to
Clojure, without creating havoc on the development of Clojure proper.
Often times when someone post a useful function on this group and
asks to add it to Core, the response is a unanimous Add it to Contrib
and see where it goes from there.  This allows Clojure to grow
without Rich reading every single contribution because he can rely on
community around Contrib to make sound decisions.  I believe, if you
allow 3rd party libs to penetrate Contrib, then you must allow the
same libs to penetrate Clojure itself.  To flip it the other way, I
think the only deps Contrib should be allowed are the deps used by
Core.

I think Contirb should remain a breeding ground for Core (if that is
indeed its current purpose), and should remain as dead simple and
dependency free as possible!  I think Clojure libs which require 3rd
party deps should be left to their own devices for now.  The
unification of those can be solved by some build/dependency tool.

Maybe there should be a 3rd project called clojure-extensions?  This
could rely on core, clojure-contrib and any number of 3rd party deps.
I do admit, though, that might confuse beginners more than a
modularized Contrib.

Sorry if I missed the point of this thread, but I thought the question
should be asked.  What is the purpose of Contrib?

P.S.  I don't want to get off-track, but I also don't understand why
ClojureCLR or clojurescript are included in Contrib.  I also don't
understand why test files are not under their own top level dir?  I
think that is a good convention and allows for easier tooling.  OK,
I'll shut up now.

On Apr 15, 4:01 am, dysinger dysin...@gmail.com wrote:
 +1 I said the same thing on IRC

 On Apr 14, 11:27 am, Mark Reid mark.r...@gmail.com wrote:

  Hi,

  I'm not sure if this is relevant to this discussion but, as a
  newcomer, I was puzzled by the organisation of the clojure-contrib
  source.

  Why, for example, are ClojureCLR and clojurescript at the top of the
  trunk? Shouldn't these be in separate projects?

  Regards,

  Mark.
  --http://mark.reid.name/

  On Apr 14, 10:19 pm, Rich Hickey richhic...@gmail.com wrote:

   I've been thinking recently about contribs with dependencies.

   I think it's very important to have layers - e.g. core depends only on
   JDK 1.5, contrib only on core. Lately there have been some ideas
   centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
   etc.

   I'd like to start a discussion about how best to support the
   contributions of libraries that depend on things not in the JDK.

   Obviously, without care and rules it could get crazy quickly, and I
   want to avoid the kitchen-sink effect. It is very important that
   things remain [truly, not just apparently] simple.

   Looking for suggestions,

   Rich
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Possible contrib contribution: clojure.contrib.timing

[Jason Wolfe]

I have some related contributions ... if clojure.contrib.timing is
created, maybe some of these would be useful too:

http://groups.google.com/group/clojure/browse_frm/thread/231cc06b4b13744c?hl=en#

-Jason


--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Possible contrib contribution: clojure.contrib.timing

[Chris]

Done: git://github.com/cconstantine/clojure.contrib.git

Please feel free to be brutal on the code review.  The last thing I
want is for clojure to get dirtied up with bad code.

Thanks,
 Chris

On Apr 15, 10:45 am, Sean Devlin francoisdev...@gmail.com wrote:
 Start by putting your code on github or something similar :)

 On Apr 14, 8:01 pm, Chris ccons...@gmail.com wrote:

  While playing around with clojure I've found the (time ...) macro
  isn't as powerful as I'd like.  To fix this I made a timing library to
  help me figure out where all my runtime is going.  If other people
  find it useful I'd like to get it into contrib.

  Simple overview of clojure.contrib.timing:

  clojure.contrib.timing/with-timing
  ([expr {:name :timing-map}])
    Executes 'expr', returns result of expr, and records its time to
  execute.  Each time to execute is saved for processing later.  This
  allows you to get mean/median/mode/cumulative runtimes for the
  expression.
      - expr: The expression to evaluate
      - name: value to name expression, defaults to (str expr).
        timing-map: Reference to a map of recorded timings.  Defaults to
  the shared global *timings.

  clojure.contrib.timing/analyze-timing
    Returns a hashmap of 'name' : '(analysis-func timing-list)'.  All
  times are converted to milli seconds.  If timing-map is not given it
  defaults to the shared global *timings*.
    ([analysis-func timing-map]

  There are some other helper funcs/macros, but the above two are the
  most important.  Future work here could give us a nice performance
  timing library written in clojure, and powerful enough to allow
  clojure programs to know how fast they are and tune themselves (think
  serialized vs. parallelism, hostnames to connect to, etc...).

  The timing-map is a ref to a map.  Each value is a list of every
  runtime of the expression.  Every time the expression runs it's time-
  to-run is cons-ed to the front of that expression's timing list.

  Storing of the runtime into the ref is a side-effect of (with-
  timing ...).  I was torn on this point, but I think it's the right
  thing to do for now; performance is a side effect of code execution,
  so it isn't that horrible for it to be stored as a side-effect.  This
  is how the original (time ...) macro works; it reports the runtime to
  stdout instead of returning it.

  I'm not sure what the protocol here is for getting this thing out for
  review and possible inclusion.  Is anyone interested?  How do I get my
  changes out there for people to review?

  Thanks!
   Chris
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Possible contrib contribution: clojure.contrib.timing

[Chris]

You work appears to be geared less toward measuring timing, and more
towards putting bounds on memory and time.  I like it :)

On Apr 15, 2:52 pm, Jason Wolfe jawo...@berkeley.edu wrote:
 I have some related contributions ... if clojure.contrib.timing is
 created, maybe some of these would be useful too:

 http://groups.google.com/group/clojure/browse_frm/thread/231cc06b4b13...

 -Jason
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: VimClojure 2.1.0 released

[Meikel Brandmeyer]

Dear vimming Clojurians,

a word of warning:

If you have a file containing syntax errors or which contains
a namespace but is not in the Classpath, you probably want

  let clj_want_gorilla = 0

in your .vimrc. This also applies if you use files which have
side-effects when they are loaded.

The dynamic parts of VimClojure (formerly known as Gorilla)
need the introspection facilities of Clojure, which only work
when the namespace is loaded correctly.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Has anyone on this group ever tried Forth?

[CuppoJava]

Thanks for all your replies. I was most interested in whether stack
languages provided any easier abstraction capabilities beyond that of
lisp/clojure. I read about the Factor implementation, and about how
continuations, coroutines, and generators were almost trivial to
implement and only required a few lines of code.

For now I think Clojure is still the best fit for getting a lot of
work done, due to its ease of debugging and connectivity with java.
But I will definitely check out Forth for my microcontroller projects
in the future.

-Patrick
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Contribs with dependencies

[Stuart Sierra]

On Apr 15, 2:10 pm, rzeze...@gmail.com rzeze...@gmail.com wrote:
 P.S.  I don't want to get off-track, but I also don't understand why
 ClojureCLR or clojurescript are included in Contrib.  I also don't
 understand why test files are not under their own top level dir?  I
 think that is a good convention and allows for easier tooling.

The answer to all these questions is that: contrib has grown
organically, without anyone imposing structure.  Rich Hickey has taken
a largely hands-off approach, allowing us to use contrib as a sandbox
to share useful clojure code.

I think it's valuable to have contrib as a sandbox.  But this
discussion shows it's also valuable to have Clojure libraries with
their own external dependencies.

Contrib right now is just an SVN repo, so it's pretty limited in terms
of what it can do.  If we want to handle multiple projects, with
different dependencies, we need a more sophisticated system.  We can
try to piggyback on an existing Java system like Maven or Ivy, or
start from scratch.  But someone(s) will then have to take
responsibility for maintaining that repository.

-Stuart Sierra
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Design advice/patterns for Clojure concurrency

[Robert Feldt]

Although I understand each of the concurrency primitives/systems
(stm, agents, atoms, dynvars) in isolation I find it harder to choose
wisely between them when designing/implementing specific algorithms
and programs.

Do you have any advice/tips for how to choose between Clojure's
different concurrency constructs?
How do you decide which construct to use for a particular algorithm/
program?

To me it often feels as if there is no clear-cut, best solution.
Rather several possibilities would all work ok and I'm not sure how to
trade-off performance with maintainability/understandability.

As an example I recently implemented an Evolutionary Computation
framework where a population of individuals are evaluated and then
operated on with different genetic operators. This is an
embarassingly parallel algorithm where most anything can go on in
parallel. But do we need to keep the individuals in a ref so we can
control the size of the population (maybe handy but not really needed
for EC performance), should operators be agents so that we can have as
many of them as there are cores etc. etc.

Any advice/links/pointers on designing with a more complex set of
concurrency primitives appreciated. I don't feel previous material/
books I've read (written in a mainly-pre-concurrency era (at least
compared to Clojure)) gives enough since concurrency were not really
an essential elements of the languages then in vogue.

Something like Design Patterns for Clojure concurrency would be
nice... ;)
(Googling I found this: http://www.cs.wustl.edu/~schmidt/POSA/POSA4/
Someone read it? Relevant?)
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Monads tutorial

[kkw]

Hi Jim,

Thanks for writing the tutorial!

Kev

On Apr 16, 2:01 am, jim jim.d...@gmail.com wrote:
 I've just posted a tutorial on using monads in Clojure at

 http://intensivesystems.net/tutorials/monads_101.html

 It's one big chunk of text since I haven't had time to break it up
 yet. It's also kind of rough, so if you see any typos, misspellings,
 errors, etc., post 'em here.  Comments as well.

 Thanks,
 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
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
-~--~~~~--~~--~--~---

Re: Design advice/patterns for Clojure concurrency

[billh04]

On Apr 15, 4:12 pm, Robert Feldt robert.fe...@gmail.com wrote:
 Although I understand each of the concurrency primitives/systems
 (stm, agents, atoms, dynvars) in isolation I find it harder to choose
 wisely between them when designing/implementing specific algorithms
 and programs.

 Do you have any advice/tips for how to choose between Clojure's
 different concurrency constructs?
 How do you decide which construct to use for a particular algorithm/
 program?

 To me it often feels as if there is no clear-cut, best solution.
 Rather several possibilities would all work ok and I'm not sure how to
 trade-off performance with maintainability/understandability.

 As an example I recently implemented an Evolutionary Computation
 framework where a population of individuals are evaluated and then
 operated on with different genetic operators. This is an
 embarassingly parallel algorithm where most anything can go on in
 parallel. But do we need to keep the individuals in a ref so we can
 control the size of the population (maybe handy but not really needed
 for EC performance), should operators be agents so that we can have as
 many of them as there are cores etc. etc.

 Any advice/links/pointers on designing with a more complex set of
 concurrency primitives appreciated. I don't feel previous material/
 books I've read (written in a mainly-pre-concurrency era (at least
 compared to Clojure)) gives enough since concurrency were not really
 an essential elements of the languages then in vogue.

 Something like Design Patterns for Clojure concurrency would be
 nice... ;)
 (Googling I found this:http://www.cs.wustl.edu/~schmidt/POSA/POSA4/
 Someone read it? Relevant?)

I haven't tried STM yet. I am writing a simple board game program that
uses atoms as the means of concurrency control. I have two compound
types achiTask and achiGame defined something like the following (note
the field directors):

=
(defn createAchiGame [gameId firstPlayer world gameMoveHistory
finished directors]
  {
   :tag ::achiGame,
   :gameId gameId,
   :firstPlayer firstPlayer,
   :world world,
   :gameMoveHistory gameMoveHistory
   :finished finished
   :directors directors})

(defn createAchiTask [ ]
  (let
  [firstPlayer -northPlayer-
   world (createNewWorld firstPlayer)
   gameMoveHistory (vector)
   finished false
   northDirector (createDirector -northPlayer- -computer-)
   southDirector (createDirector -southPlayer- -human-)
   directors {-northPlayer- northDirector, -southPlayer-
southDirector}
   achiGame (createAchiGame 0 firstPlayer world gameMoveHistory
finished directors)
   achiGameHandle (atom achiGame)
   achiTaskAgents ...
   achiFrame ...
   achiGamePanel #^JPanel ...
   newWindowButton ...
   achiTask (hash-map :tag ::achiTask,
  :achiGameHandle achiGameHandle,
  :achiTaskAgents achiTaskAgents,
  :achiFrame achiFrame,
  :achiGamePanel achiGamePanel
  :newWindowButton newWindowButton)
=

I think that the field directors really belongs in the achiTask type
and not in the achiGame type. But, by putting directors in achiGame,
I seem to avoid the need for having STM to control concurrency and
just use swapping the atom achiGameHandle when the achiGame changes or
the directors change.

I am considering whether this is a good idea or not. Offhand, I would
say it is not a good idea since it is warping the application design
in order to simplify the coding for concurrency. But, I am going to
stick with this approach and finish my board game and then see how I
can use STM to advantage. Like you, I am trying to understand how to
code to meet concurrency requirements using the tools Clojure
provides. At this point, I am concentrating on atom and seeing what
I can do with it.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---

Is Clojure production ready?

[Aaron Feng]

Hi,

I work for a large financial software company, and we are interested
in using Clojure for our new project.  Due to the concurrent nature of
the project, we are evaluating three possible languages: Erlang,
Scala, and Clojure.  This project will be a hosted solution, but
availability and performance is very important to us.  We want to
deploy the project within 6 to 12 months, but the project will
continue to build out the rest of the functionality for the next 2 to
4 years. We guesstimate that it will receive around 1M hits daily
initially, and it will continue to grow on a monthly basis.

Due to the nature of the project, I'm only allowed to give high level
overview of the project at this time.

We have a bias toward Scala and Clojure because they run on top of
JVM.  The richness of existing 3rd party and open source libraries are
also attractive for us.

The fundamental question for us is:  Is Clojure worth our investment
in the current state?  What are the possible risks?

Also, if anyone has any thoughts on hiring Clojure people, it would be
greatly appreciated.

Thanks,

Aaron

--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: Is Clojure production ready?

[mikel]

On Apr 15, 2:34 pm, Aaron Feng aaron.f...@gmail.com wrote:
 Hi,

 I work for a large financial software company, and we are interested
 in using Clojure for our new project.  Due to the concurrent nature of
 the project, we are evaluating three possible languages: Erlang,
 Scala, and Clojure.  This project will be a hosted solution, but
 availability and performance is very important to us.  We want to
 deploy the project within 6 to 12 months, but the project will
 continue to build out the rest of the functionality for the next 2 to
 4 years. We guesstimate that it will receive around 1M hits daily
 initially, and it will continue to grow on a monthly basis.

 Due to the nature of the project, I'm only allowed to give high level
 overview of the project at this time.

 We have a bias toward Scala and Clojure because they run on top of
 JVM.  The richness of existing 3rd party and open source libraries are
 also attractive for us.

 The fundamental question for us is:  Is Clojure worth our investment
 in the current state?  What are the possible risks?

 Also, if anyone has any thoughts on hiring Clojure people, it would be
 greatly appreciated.

If you can tolerate relatively high risk, pick Clojure or, if your
folks are allergic to Lisp, Scala. If you can't tolerate much risk,
pick Erlang; it's been around longer, has seen many production
deployments, and has been used in production environments where
reliability is of paramount importance.

I like Scala and have had good results with it in production use, but
I'd pick Clojure over Scala at this point. Clojure is simpler in
design, easier to understand in its entirety, and more readily
amenable to user patching in case that should be needed.

As for hiring people knowledgeable in the language, there aren't going
to be a lot of people very knowledgeable in any of these languages
right now. Erlang gurus may be easier to find than Scala or Clojure
gurus. You might be better served hunting for smart programmers who
like to learn languages, and who are interested in functional
programming.
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[Stu Hood]

I agree. I think the breaking into modules approach is the only scalable
solution.

Someone else mentioned that clojure-contrib is/shouldbe an incubating area
for core, which seems reasonable. There should be a little more pushback
when a project wants to make it into contrib, and it should already be
organized such that its dependencies would be well known if it wanted to
make it out of 'incubation' and into core.


On Tue, Apr 14, 2009 at 5:02 PM, Howard Lewis Ship hls...@gmail.com wrote:


 I'd say to refactor clojure-contrib into a number of seperate modules;
 individual modules (each with its own pom) could have their own
 dependencies. Thus if you choose clojure-contrib-freechart, you get
 that JAR (or compiled Clojure sources) plus the jfreechart dependency.

 In this way you are using the good part of Maven: transitive
 dependency management.

 On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey richhic...@gmail.com wrote:
 
  I've been thinking recently about contribs with dependencies.
 
  I think it's very important to have layers - e.g. core depends only on
  JDK 1.5, contrib only on core. Lately there have been some ideas
  centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
  etc.
 
  I'd like to start a discussion about how best to support the
  contributions of libraries that depend on things not in the JDK.
 
  Obviously, without care and rules it could get crazy quickly, and I
  want to avoid the kitchen-sink effect. It is very important that
  things remain [truly, not just apparently] simple.
 
  Looking for suggestions,
 
  Rich
 
  
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry
 Director of Open Source Technology at Formos

 


--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---

Re: [Discuss] Contribs with dependencies

[John Newman]

How 'bout something like Ruby Gems?
Having to svn and build the clojure-contrib sources is a hassle for some of
us.

On Thu, Apr 16, 2009 at 7:41 AM, Stu Hood stuh...@gmail.com wrote:

 I agree. I think the breaking into modules approach is the only scalable
 solution.

 Someone else mentioned that clojure-contrib is/shouldbe an incubating area
 for core, which seems reasonable. There should be a little more pushback
 when a project wants to make it into contrib, and it should already be
 organized such that its dependencies would be well known if it wanted to
 make it out of 'incubation' and into core.


 On Tue, Apr 14, 2009 at 5:02 PM, Howard Lewis Ship hls...@gmail.comwrote:


 I'd say to refactor clojure-contrib into a number of seperate modules;
 individual modules (each with its own pom) could have their own
 dependencies. Thus if you choose clojure-contrib-freechart, you get
 that JAR (or compiled Clojure sources) plus the jfreechart dependency.

 In this way you are using the good part of Maven: transitive
 dependency management.

 On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey richhic...@gmail.com
 wrote:
 
  I've been thinking recently about contribs with dependencies.
 
  I think it's very important to have layers - e.g. core depends only on
  JDK 1.5, contrib only on core. Lately there have been some ideas
  centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
  etc.
 
  I'd like to start a discussion about how best to support the
  contributions of libraries that depend on things not in the JDK.
 
  Obviously, without care and rules it could get crazy quickly, and I
  want to avoid the kitchen-sink effect. It is very important that
  things remain [truly, not just apparently] simple.
 
  Looking for suggestions,
 
  Rich
 
  
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry
 Director of Open Source Technology at Formos




 



-- 
John

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Possible contrib contribution: clojure.contrib.timing

[Baishampayan Ghose]

Chris wrote:
 Done: git://github.com/cconstantine/clojure.contrib.git
 
 Please feel free to be brutal on the code review.  The last thing I
 want is for clojure to get dirtied up with bad code.

Just a minor nit -

Shouldn't the function ``creating-timing-map'' be called 
``create-timing-map'' ?

Regards,
BG

-- 
Baishampayan Ghose b.gh...@ocricket.com
oCricket.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
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
-~--~~~~--~~--~--~---

Re: Monads tutorial

[Baishampayan Ghose]

jim wrote:
 I've just posted a tutorial on using monads in Clojure at
 
 http://intensivesystems.net/tutorials/monads_101.html
 
 It's one big chunk of text since I haven't had time to break it up
 yet. It's also kind of rough, so if you see any typos, misspellings,
 errors, etc., post 'em here.  Comments as well.

The code page http://intensivesystems.net/tutorials/code/monads_101.clj 
is giving a 404 :)

Regards,
BG

-- 
Baishampayan Ghose b.gh...@ocricket.com
oCricket.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
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
-~--~~~~--~~--~--~---