Re: Clojure namespace conventions

2011-02-24 Thread Laurent PETIT
2011/2/25 Phil Hagelberg 

> On Feb 24, 2:48 am, Paul Richards  wrote:
> > My goodness..  Seems like a can of worms.  :p
> >
> > I think I'll pick something at least two levels deep like
> > "pauldoo.someproject", complete with ".core" and ".tools" as sub
> > namespaces..
>
> IMO adding ".core" indicates it's a "filler" segment that's only there
> to get around the fact that you shouldn't have single-segment
> namespaces. If you've already got two levels, there's no need for
> a .core segment.
>

One element to take into consideration : if you want your library to
sometimes play well with e.g. OSGi, it would be better to have all of it
into its own java package, since OSGi places "visibility directives" at the
package level.

Indeed, imagine that in the future you have created 2 useful libraries :
pauldoo.project1, and pauldoo.project2.

If both are independently released in their artifact (which would also
happen to be OSGi bundle), there are 2 possibilities :

if pauldoo.project1 is a namespace, and pauldoo.project2 is a namespace,
then both artifacts will have content in the package pauldoo, and thus both
artifacts will be seen by OSGi as (potentially) "exporting" the package
pauldoo. I'm not an OSGi expert, but this may or may not be embarrassing.

To the contrary, if you take care of having each library to not share
content in a same package, eg. pauldoo.project1.core et al, then their
(potential) export directive will not conflict with each other.

Cheers,

-- 
Laurent

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

Re: ANN: ElephantDB, a distributed database written in Clojure

2011-02-24 Thread nathanmarz
Clojure's not even close to being a bottleneck in this database. The
performance is limited by the underlying storage engine which is
currently Berkeley DB Java Edition.


On Feb 24, 4:21 pm, rogerdpack  wrote:
> How was clojure speed-wise for you? Was it blazingly fast? Just good
> enough?
> -r

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


Re: Transforming map entries

2011-02-24 Thread Alex Miller
I have a couple utility functions I use a lot for creating maps from
sequences and transforming one map to another.  These are (poorly)
named mapmap and mapmapmap.  (Yes I know the names are awful but I
have lived with them long enough that they've stuck.)

mapmap takes a key production function (optional - uses identity by
default), a value production function, and a source sequence.
  (def c (range 5))
  (mapmap #(+ 1 %) #(* 2 %) c)
  -> {5 8, 4 6, 3 4, 2 2, 1 0}

More here:
http://tech.puredanger.com/2010/09/24/meet-my-little-friend-mapmap/

mapmapmap is similar but takes a map, not a sequence.  It applies the
key function to transform the keys and the value function to transform
the values.  So your request would be:

  (mapmapmap #(if (string? %) (upper-case %) %) mymap)

Here's a gist with the definition of both:
https://gist.github.com/843292

Hope you find it useful...
Alex


On Feb 21, 9:08 pm, yair  wrote:
> I'm hoping this is a dumb question and I've missed something obvious.
> I have a map with various key-value pairs and I want to transform some
> of the values, e.g.
>
> (def mymap {:first "john" :last "smith" :age 25}) and say I want to
> change the strings to be upper case.
> Right now all I can think of doing is using reduce and passing in an
> empty map and the re-associating each key with the (possibly)
> transformed value.  Is there something like the map function that
> takes two parameters, one a function that receives a pair and returns
> a new pair, and the other a map, and returns a map that's
> reconstituted from those pairs?
>
> 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


Re: java.lang.Exception: transaction rolled back: java.lang.InterruptedException

2011-02-24 Thread Shantanu Kumar
If it is about Thread/sleep, you can perhaps use something like this:

(defn sleep
  [n]
  (try (Thread/sleep n)
(catch InterruptedException e
  (.interrupt (Thread/currentThread)

There might be other situations where the underlying API throws
InterruptedException - deal with them accordingly.

http://www.ibm.com/developerworks/java/library/j-jtp05236.html

HTH

Regards,
Shantanu

On Feb 25, 4:12 am, clj123  wrote:
> I've also noticed that I can cause this InterruptedException to be
> thrown if I add
>
> (. Thread (sleep 1000)) instead of saving to database.
>
> It looks like when a thread is waiting for a long time this exception
> is being thrown. By the way I'm running only one thread in my code.
>
> Here's the rest of my stack trace:
>
> java.lang.InterruptedException: sleep interrupted
>         at java.lang.Thread.sleep(Native Method)
>         at my-code$my-method$fn__2822.invoke(my-code.clj:203)
>         at my-code$my-method.invoke(my-code.clj:201)
>         at clojure.lang.Compiler.eval(Compiler.java:5424)
>         at clojure.lang.Compiler.eval(Compiler.java:5391)
>         at clojure.core$eval.invoke(core.clj:2382)
>         at clojure.main$repl$read_eval_print__5624.invoke(main.clj:183)
>         at clojure.main$repl$fn__5629.invoke(main.clj:204)
>         at clojure.main$repl.doInvoke(main.clj:204)
>         at clojure.lang.RestFn.invoke(RestFn.java:702)
>         at clojure.tools.nrepl$handle_request.invoke(nrepl.clj:272)
>         at clojure.lang.Var.invoke(Var.java:373)
>         at clojure.tools.nrepl$message_dispatch
> $fn__199$fn__202.invoke(nrepl.clj:336)
>         at clojure.lang.AFn.call(AFn.java:18)
>         at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>         at java.util.concurrent.FutureTask.run(Unknown Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

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


easier exit

2011-02-24 Thread rogerdpack
Hello all. A bit new to clojure here.  Anyway I found it a bit
difficult to exit from a REPL.
Would a patch to make it give instructions (like Python's

C:\>c:\installs\Python26\python.exe
>>> exit
Use exit() or Ctrl-Z plus Return to exit
>>>

)

like that have a chance to be accepted?

Also is there any way to contribute patches to the clojure website
itself? (maybe put it up on github too?)
Cheers!
-r

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


Re: ANN: ElephantDB, a distributed database written in Clojure

2011-02-24 Thread rogerdpack
How was clojure speed-wise for you? Was it blazingly fast? Just good
enough?
-r

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


Re: logos on clojars .. workflow for using things that r present only on github but not on clojars..

2011-02-24 Thread David Nolen
On Thu, Feb 24, 2011 at 6:38 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Thanks David for such a quick response.
> that would be nice David.. I think we r in for a treat with logos being a
> better prolog in clojure.. :)
>
>> 1) pattern matcher
>>
> like matchure?? what exactly would this be?
>

Conceptually similar to matchure but it would create logic vars and perform
unification as needed.


> 2) tabling
>>
> I don't know what this means.. r u hinting at memoization?
>

Memoization generalized for logic programs. You get a few of the benefits of
Datalog w/ tabling.


> 3) convenient syntax for dealing with facts defined as sets of Clojure data
>> structures.
>>
> in fact convenient syntax for various basic data structures is one of the
> key reasons I love clojure so much .. :)
>

Definitely.


> eagerly waiting for your stuff on clojars. I was considering porting some
> code I had written with Jim Duey mini-kanren implementation. Would I be
> right in assuming Logos is a superset of his stuff already .. Would I have
> to watch out for something in particular when do this porting?
> Sunil
>

The differences are minor.

* Sequences that end with logic vars are constructed like so: (lcons 1 (lvar
'x))
* You need to replace fresh with exist.
* Interleaving search is the default instead of the depth-first search of
Prolog.

David

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

Re: Clojure namespace conventions

2011-02-24 Thread Phil Hagelberg
On Feb 24, 2:48 am, Paul Richards  wrote:
> My goodness..  Seems like a can of worms.  :p
>
> I think I'll pick something at least two levels deep like
> "pauldoo.someproject", complete with ".core" and ".tools" as sub
> namespaces..

IMO adding ".core" indicates it's a "filler" segment that's only there
to get around the fact that you shouldn't have single-segment
namespaces. If you've already got two levels, there's no need for
a .core segment.

-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


Re: logos on clojars .. workflow for using things that r present only on github but not on clojars..

2011-02-24 Thread Phil Hagelberg
On Feb 24, 2:52 pm, Sunil S Nandihalli 
wrote:
>  I was wondering if there is a reason as to why logos was not put on
> clojars.. If it was intended to be that way by the author.. what is a good
> work flow to use some that is available only on github but not on clojars..
>  A description of the workflow with cake/leiningen would be perfect.

You can set up a private repository using Nexus or Archiva, and then
use the lein deploy task to put logos out there. Then add your private
repo under :repositories in project.clj of the project with which you
want to use logos.

This requires Leiningen 1.5 from git and is not thoroughly documented
yet. Another alternative would be to deploy it as org.clojars.YOURNAME/
logos on clojars.

-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


Re: logos on clojars .. workflow for using things that r present only on github but not on clojars..

2011-02-24 Thread Sunil S Nandihalli
Thanks David for such a quick response.
that would be nice David.. I think we r in for a treat with logos being a
better prolog in clojure.. :)

> 1) pattern matcher
>
like matchure?? what exactly would this be?

> 2) tabling
>
I don't know what this means.. r u hinting at memoization?

> 3) convenient syntax for dealing with facts defined as sets of Clojure data
> structures.
>
in fact convenient syntax for various basic data structures is one of the
key reasons I love clojure so much .. :)

>
> David
>
eagerly waiting for your stuff on clojars. I was considering porting some
code I had written with Jim Duey mini-kanren implementation. Would I be
right in assuming Logos is a superset of his stuff already .. Would I have
to watch out for something in particular when do this porting?
Sunil

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

Re: transaction rolled back: java.lang.InterruptedException

2011-02-24 Thread clj123
I've tried saving a much smaller number of rows and I'm still getting
this exception.

I also tried processing the rows (without saving to database) and put
a Thread sleep. That also generated this exception.

On Feb 23, 12:55 pm, Saul Hazledine  wrote:
> On Feb 23, 9:42 pm, clj123  wrote:
>
> > I have been getting this exception:
> > java.lang.Exception: transaction rolled back:
> > java.lang.InterruptedException
> >         at clojure.contrib.sql.internal$throw_rollback.invoke(internal.clj:
> > 142)
>
> I can only take some wild guesses I'm afraid. The rollback occurs
> because clojure.contrib.sql tends to wrap operations in transactions.
> It appears that an InteruptedException occured during an operation and
> this called the rollback.
>
> Wild guesses:
> 1. The app is trying to write lots of data and a timeout has occured.
> 2. The database is busy and a timeout has occured.
>
> Saul

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


Re: Anyone using the sdb library?

2011-02-24 Thread Chas Emerick

On Feb 24, 2011, at 5:58 PM, .Bill Smith wrote:

> I don't know, but if you introduce breaking changes, you'd better name it 
> version 2.0.

;-)

It'd actually be nice to establish a stable groupId and artifactId for the 
project (rather than the constantly-shifting 
`org.clojars.github-username-here`), which in conjunction with breaking 
changes, would warrant dropping back to v0.x.y until those changes have proven 
themselves.

- Chas

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


Re: Anyone using the sdb library?

2011-02-24 Thread Mark Rathwell
I used it as a starting point for an sdb lib a while back, moved that
project to GAE though.  One note, it uses an outdated version of the AWS
java libraries, you should probably update that if you're in there.


On Thu, Feb 24, 2011 at 3:36 PM, Chas Emerick  wrote:

> Is anyone using the sdb (AWS SimpleDB) client library, originally written
> by Rich Hickey in 2009, and then tweaked in various ways by a couple of
> others since?
>
> Github repo network here: https://github.com/richhickey/sdb/network
>
> I ask because I have some ideas for some changes and enhancements to the
> library, some of which would be breaking (potentially from both an API and
> data format standpoint).  It seems like having a dialogue with anyone that
> is actively using it would be productive, if only to ensure that I'm not
> headed towards the weeds.  Beyond that, a collective attempt to coordinate
> the direction of the project would be good (rather than simply letting
> off-by-one forks of it proliferate on github).
>
> Cheers,
>
> - Chas
>
> --
> 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 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

Re: java.lang.Exception: transaction rolled back: java.lang.InterruptedException

2011-02-24 Thread clj123
I've also noticed that I can cause this InterruptedException to be
thrown if I add

(. Thread (sleep 1000)) instead of saving to database.

It looks like when a thread is waiting for a long time this exception
is being thrown. By the way I'm running only one thread in my code.

Here's the rest of my stack trace:

java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at my-code$my-method$fn__2822.invoke(my-code.clj:203)
at my-code$my-method.invoke(my-code.clj:201)
at clojure.lang.Compiler.eval(Compiler.java:5424)
at clojure.lang.Compiler.eval(Compiler.java:5391)
at clojure.core$eval.invoke(core.clj:2382)
at clojure.main$repl$read_eval_print__5624.invoke(main.clj:183)
at clojure.main$repl$fn__5629.invoke(main.clj:204)
at clojure.main$repl.doInvoke(main.clj:204)
at clojure.lang.RestFn.invoke(RestFn.java:702)
at clojure.tools.nrepl$handle_request.invoke(nrepl.clj:272)
at clojure.lang.Var.invoke(Var.java:373)
at clojure.tools.nrepl$message_dispatch
$fn__199$fn__202.invoke(nrepl.clj:336)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

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


Re: logos on clojars .. workflow for using things that r present only on github but not on clojars..

2011-02-24 Thread David Nolen
On Thu, Feb 24, 2011 at 5:52 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hello everybody,
>  I was wondering if there is a reason as to why logos was not put on
> clojars.. If it was intended to be that way by the author.. what is a good
> work flow to use some that is available only on github but not on clojars..
>  A description of the workflow with cake/leiningen would be perfect.
>
> Sunil.
>

Don't have anything to say about the best way to use it from git, but it's
not on Clojars yet because it doesn't have the feature set required to be
useful for everyday use. Before putting it out there for consumption, I'd
like it to have:

1) pattern matcher
2) tabling
3) convenient syntax for dealing with facts defined as sets of Clojure data
structures.

David

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

Re: Anyone using the sdb library?

2011-02-24 Thread .Bill Smith
I don't know, but if you introduce breaking changes, you'd better name it 
version 2.0.

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

logos on clojars .. workflow for using things that r present only on github but not on clojars..

2011-02-24 Thread Sunil S Nandihalli
Hello everybody,
 I was wondering if there is a reason as to why logos was not put on
clojars.. If it was intended to be that way by the author.. what is a good
work flow to use some that is available only on github but not on clojars..
 A description of the workflow with cake/leiningen would be perfect.

Sunil.

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

Re: java.lang.Exception: transaction rolled back: java.lang.InterruptedException

2011-02-24 Thread Michael Ossareh
On Thu, Feb 24, 2011 at 14:36, clj123  wrote:

> That didn't solve the problem. I've tried smaller row numbers and it
> still throws the same error:
>
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.RuntimeException: java.lang.InterruptedException
>at clojure.lang.LazySeq.sval(LazySeq.java:47)
>at clojure.lang.LazySeq.seq(LazySeq.java:56)
>at clojure.lang.Cons.next(Cons.java:39)
>at clojure.lang.RT.next(RT.java:560)
>at clojure.core$next.invoke(core.clj:61)



What is the DB saying in its logs?

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

Re: Release.Next Version Number

2011-02-24 Thread Brian Marick

On Feb 23, 2011, at 8:36 PM, Ken Wesson wrote:

> But "1.3" may overpromise and underdeliver backward compatibility.


It depends, I suppose, on whether people who are already using Clojure 1.2 will 
blindly upgrade to 1.3/2.0 without having read anything that will warn them 
what to expect. 

I like semantic versioning myself, but I think considerations are different for 
peripheral libraries like mine than they are for the foundational core of the 
whole shebang.

-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf)
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

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


Re: java.lang.Exception: transaction rolled back: java.lang.InterruptedException

2011-02-24 Thread clj123
That didn't solve the problem. I've tried smaller row numbers and it
still throws the same error:

java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.RuntimeException: java.lang.InterruptedException
at clojure.lang.LazySeq.sval(LazySeq.java:47)
at clojure.lang.LazySeq.seq(LazySeq.java:56)
at clojure.lang.Cons.next(Cons.java:39)
at clojure.lang.RT.next(RT.java:560)
at clojure.core$next.invoke(core.clj:61)

On Feb 23, 12:59 pm, Saul Hazledine  wrote:
> On Feb 23, 9:54 pm, clj123  wrote:
>
> > I'm getting the following exception trying to insert large batch data
> > in the database.
>
> I'd try to write less data at one time to the database. Start with,
> say, 20 rows at a time.
>
> Saul

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


Re: noob question: pallet, crane, which criteria to choose which one ?

2011-02-24 Thread Laurent PETIT
2011/2/24 Hugo Duncan 

> On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT 
> wrote:
>
>   * deliver to pre-production:
>>   * input = git commit hash, maven version of some "tooling" artifacts
>> which are java artifacts, invoked via an mvn java execute target once the
>> right git revision has been checked out
>>   * output = publish the "app state" (created locally from the derived git
>> content) to a directory in the server, run a shell script on the server
>> which finishes the install, and, if everything went well, tag the commit,
>> and push the tag to the reference repo from which the content had been
>> initially pulled from
>>
>
>  Would trying to use pallet or crane seem overkill ?
>>
>
> Laurent,
>
> Pallet would certainly be capable of automating the workflow you describe.
>  From what you describe a shell script invoked by an ssh command could
> probably do the job too.  In pallet it might look something like this
> (unchecked):
>
>  (def release-dir "/usr/local/myapp")
>
>  (defn push-preproduction*
> "Crate function to publish a specific commit"
> [request tag version artifacts]
> (exec-script/exec-checked-script
>request
>(format "Checkout version %s" version) ; message for logging, etc
>(cd src)
>(git checkout ~version)
>(mvn exec:java something ~@artifacts)
>(cp app-state ~release-dir)
>(finish-install)
>(git tag ~tag)
>(git push --tags)))
>
>  (def push-production
> "Crate function to extract data from the environment,
>  and publish it"
> [request]
> (push-preproduction*
>   request
>   (environment/get-for request [:userdata :tag])
>   (environment/get-for request [:userdata :version])
>   (environment/get-for request [:userdata :artifacts])
>
>  ;; define phases on a "Server" group, linking the
>  ;; publish phase to the push-production crate function
>  (def server (make-node "server" {}
>   :publish push-preproduction))
>
>  ;; Function to publish a specific version.  Uses the node definitions
>  ;; from config.clj
>  (def publish
> [request tag version & artifacts]
> (let [service (compute/compute-service-from-config-file :nl)]
>   (core/lift server
>  :phase publish
>  :compute service
>  :environment {:userdata {:tag tag
>   :version version
>   :artifacts artifacts}})
>
> Set up ~/.pallet/config.clj, specifying details of the existing machine,
> and that it should be in the "server" group
>
>  (defpallet
>:providers
> {:nl {:provider "node-list"
>   :node-list [["server" "server" "192.168.2.37"
>:ubuntu :os-version "10.04"]]
>   :environment {:user {:username "user" :no-sudo true)
>
> and invoked via
>
>  (publish "tag" "commitish" "artifact1" "artifact2")
>
>
Wow, I looked at the above scripts, and it seems that you've captured the
essence of the problem quite well!
Given the above starter-code, I think I'll probably give it a try, for sure
!


>
> Whether pallet is overkill or not, I think, is dependent on whether you
> think your requirements will grow.  Using this as an exercise to learn
> pallet would be time well spent if you think you will want to automate more
> in the future.
>
> But, I'm biased.
>
> --
> Hugo Duncan
>

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

Re: Release.Next Version Number

2011-02-24 Thread Armando Blancas
> Without commenting on the validity of the above at all, I seem to recall that 
> the
> application of the "1.0" version label prompted the same sort of concerns.

You're right. No point in commenting on this whole silly thread.

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


ANN: ElephantDB, a distributed database written in Clojure

2011-02-24 Thread nathanmarz
We (BackType) recently released our database ElephantDB as open
source. I thought that the Clojure community at large would find this
project interesting as it's written in Clojure.

ElephantDB is a specialized database for exporting key/value data from
Hadoop and serving it in a read-only fashion. It has seemless
integration with Cascalog through the elephantdb-cascalog project.
ElephantDB makes use of Hadoop, Thrift, and BerkeleyDB Java Edition.

Writing this database in Clojure was a great experience. The place
where Clojure really shined was for writing the unit tests. Clojure's
dynamic capabilities made it really easy to do things like mock out
remote servers or mock out pieces that weren't deterministic so that
they could be tested. There were a few key macros I wrote for testing
purposes that made it a lot easier to write and understand the tests.

If you'd like to know more about the project, check out our
introductory blog post and the GitHub repos.

http://tech.backtype.com/introducing-elephantdb-a-distributed-database
https://github.com/nathanmarz/elephantdb
https://github.com/nathanmarz/elephantdb-cascalog

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


Re: noob question: pallet, crane, which criteria to choose which one ?

2011-02-24 Thread Laurent PETIT
Hugo, thanks for the detailed answer, which I'll take the time to analyse
in-depth ASAP.
Indeed, I can envision a day, maybe coming sooner than later, where we'd
like to use cloud services for some clients. Especially those who could
predict activity "peaks" due to their business plans, marketings, etc.

That's why I'm balancing the idea of jumping in something like pallet now,
when we're still not in the rush, or postpone it until the real problem, in
its real shape, occurs.

Cheers,

-- 
Laurent

2011/2/24 Hugo Duncan 

> On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT 
> wrote:
>
>   * deliver to pre-production:
>>   * input = git commit hash, maven version of some "tooling" artifacts
>> which are java artifacts, invoked via an mvn java execute target once the
>> right git revision has been checked out
>>   * output = publish the "app state" (created locally from the derived git
>> content) to a directory in the server, run a shell script on the server
>> which finishes the install, and, if everything went well, tag the commit,
>> and push the tag to the reference repo from which the content had been
>> initially pulled from
>>
>
>  Would trying to use pallet or crane seem overkill ?
>>
>
> Laurent,
>
> Pallet would certainly be capable of automating the workflow you describe.
>  From what you describe a shell script invoked by an ssh command could
> probably do the job too.  In pallet it might look something like this
> (unchecked):
>
>  (def release-dir "/usr/local/myapp")
>
>  (defn push-preproduction*
> "Crate function to publish a specific commit"
> [request tag version artifacts]
> (exec-script/exec-checked-script
>request
>(format "Checkout version %s" version) ; message for logging, etc
>(cd src)
>(git checkout ~version)
>(mvn exec:java something ~@artifacts)
>(cp app-state ~release-dir)
>(finish-install)
>(git tag ~tag)
>(git push --tags)))
>
>  (def push-production
> "Crate function to extract data from the environment,
>  and publish it"
> [request]
> (push-preproduction*
>   request
>   (environment/get-for request [:userdata :tag])
>   (environment/get-for request [:userdata :version])
>   (environment/get-for request [:userdata :artifacts])
>
>  ;; define phases on a "Server" group, linking the
>  ;; publish phase to the push-production crate function
>  (def server (make-node "server" {}
>   :publish push-preproduction))
>
>  ;; Function to publish a specific version.  Uses the node definitions
>  ;; from config.clj
>  (def publish
> [request tag version & artifacts]
> (let [service (compute/compute-service-from-config-file :nl)]
>   (core/lift server
>  :phase publish
>  :compute service
>  :environment {:userdata {:tag tag
>   :version version
>   :artifacts artifacts}})
>
> Set up ~/.pallet/config.clj, specifying details of the existing machine,
> and that it should be in the "server" group
>
>  (defpallet
>:providers
> {:nl {:provider "node-list"
>   :node-list [["server" "server" "192.168.2.37"
>:ubuntu :os-version "10.04"]]
>   :environment {:user {:username "user" :no-sudo true)
>
> and invoked via
>
>  (publish "tag" "commitish" "artifact1" "artifact2")
>
>
> Whether pallet is overkill or not, I think, is dependent on whether you
> think your requirements will grow.  Using this as an exercise to learn
> pallet would be time well spent if you think you will want to automate more
> in the future.
>
> But, I'm biased.
>
> --
> Hugo Duncan
>

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

Re: noob question: pallet, crane, which criteria to choose which one ?

2011-02-24 Thread Hugo Duncan
On Thu, 24 Feb 2011 06:29:13 -0500, Laurent PETIT  
 wrote:



 * deliver to pre-production:
   * input = git commit hash, maven version of some "tooling" artifacts
which are java artifacts, invoked via an mvn java execute target once the
right git revision has been checked out
   * output = publish the "app state" (created locally from the derived  
git

content) to a directory in the server, run a shell script on the server
which finishes the install, and, if everything went well, tag the commit,
and push the tag to the reference repo from which the content had been
initially pulled from



Would trying to use pallet or crane seem overkill ?


Laurent,

Pallet would certainly be capable of automating the workflow you  
describe.  From what you describe a shell script invoked by an ssh command  
could probably do the job too.  In pallet it might look something like  
this (unchecked):


  (def release-dir "/usr/local/myapp")

  (defn push-preproduction*
 "Crate function to publish a specific commit"
 [request tag version artifacts]
 (exec-script/exec-checked-script
request
(format "Checkout version %s" version) ; message for logging, etc
(cd src)
(git checkout ~version)
(mvn exec:java something ~@artifacts)
(cp app-state ~release-dir)
(finish-install)
(git tag ~tag)
(git push --tags)))

  (def push-production
 "Crate function to extract data from the environment,
  and publish it"
 [request]
 (push-preproduction*
   request
   (environment/get-for request [:userdata :tag])
   (environment/get-for request [:userdata :version])
   (environment/get-for request [:userdata :artifacts])

  ;; define phases on a "Server" group, linking the
  ;; publish phase to the push-production crate function
  (def server (make-node "server" {}
   :publish push-preproduction))

  ;; Function to publish a specific version.  Uses the node definitions
  ;; from config.clj
  (def publish
 [request tag version & artifacts]
 (let [service (compute/compute-service-from-config-file :nl)]
   (core/lift server
  :phase publish
  :compute service
  :environment {:userdata {:tag tag
   :version version
   :artifacts artifacts}})

Set up ~/.pallet/config.clj, specifying details of the existing machine,  
and that it should be in the "server" group


  (defpallet
:providers
 {:nl {:provider "node-list"
   :node-list [["server" "server" "192.168.2.37"
:ubuntu :os-version "10.04"]]
   :environment {:user {:username "user" :no-sudo true)

and invoked via

  (publish "tag" "commitish" "artifact1" "artifact2")


Whether pallet is overkill or not, I think, is dependent on whether you  
think your requirements will grow.  Using this as an exercise to learn  
pallet would be time well spent if you think you will want to automate  
more in the future.


But, I'm biased.

--
Hugo Duncan

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


Re: Clojure namespace conventions

2011-02-24 Thread Chas Emerick
FWIW, I've settled on cemerick.project-name as my default.  I think the 
project-name.core convention cropped up because of hesitancy of some to use 
their name at the top level.

- Chas

On Feb 24, 2011, at 5:48 AM, Paul Richards wrote:

> My goodness..  Seems like a can of worms.  :p
> 
> I think I'll pick something at least two levels deep like
> "pauldoo.someproject", complete with ".core" and ".tools" as sub
> namespaces..
> 
> 
> 
> On 23 February 2011 20:35, Mark Rathwell  wrote:
>> 
>> This discussion has been had multiple times on this list, not sure how much
>> new information you will get.  See the following for a couple examples:
>> http://groups.google.com/group/clojure/browse_thread/thread/968e9066223c3a2b/fbce84869dbf4ce6?lnk=gst#
>> http://groups.google.com/group/clojure/browse_thread/thread/78a32eeaacd659e/89304aeec4d00f7d?lnk=gst#
>> 
>> 
>> 
>> On Wed, Feb 23, 2011 at 3:19 PM, Paul Richards 
>> wrote:
>>> 
>>> Hi,
>>> Is there a guide to the conventions for naming and structuring
>>> namespaces in a Clojure project?
>>> 
>>> I see for example that the ".core" namespace is fairly common in
>>> different projects.  Is this also where the "-main" entry point should
>>> live?
>>> 
>>> Also is it typical to have code living in "someproject" as well as
>>> "someproject.tools", or should the former be promoted to
>>> "someproject.core"?
>>> 
>>> 
>>> --
>>> Paul Richards
>>> @pauldoo
>>> 
>>> --
>>> 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 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
> 
> 
> 
> -- 
> Paul Richards
> @pauldoo
> 
> -- 
> 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 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


Re: Release.Next Version Number

2011-02-24 Thread Chas Emerick

On Feb 24, 2011, at 3:09 PM, David wrote:

> I fully recognize that we could call the next iteration of Clojure "2.0"
> and would be well within our rights. My point has been that calling it
> 2.0 may give people the impression that developing in the language is
> seamless and well-polished. When they find out that it's not, Clojure
> may experience some backlash.

Without commenting on the validity of the above at all, I seem to recall that 
the application of the "1.0" version label prompted the same sort of concerns.

- Chas

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


Re: ANN: Clojure Toolbox (Early Beta)

2011-02-24 Thread James Reeves
On 24 February 2011 16:37, Timothy Baldridge  wrote:
> I'd like to see some graphics libraries. Penumbra would be a great addition.

It's already there, under "Graphics" :)

- James

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


Re: ANN: Clojure Toolbox (Early Beta)

2011-02-24 Thread James Reeves
On 24 February 2011 09:46, Scott Jaderholm  wrote:
> Some that I like:
> slice
> scriptjure
> clojurejs
> cssgen
> gaka

Added. I wasn't quite sure how to classify slice, so I've put it under
"Template Languages" for the time being.

- James

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


Anyone using the sdb library?

2011-02-24 Thread Chas Emerick
Is anyone using the sdb (AWS SimpleDB) client library, originally written by 
Rich Hickey in 2009, and then tweaked in various ways by a couple of others 
since?

Github repo network here: https://github.com/richhickey/sdb/network

I ask because I have some ideas for some changes and enhancements to the 
library, some of which would be breaking (potentially from both an API and data 
format standpoint).  It seems like having a dialogue with anyone that is 
actively using it would be productive, if only to ensure that I'm not headed 
towards the weeds.  Beyond that, a collective attempt to coordinate the 
direction of the project would be good (rather than simply letting off-by-one 
forks of it proliferate on github).

Cheers,

- Chas

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


Re: Release.Next Version Number

2011-02-24 Thread Brenton
I think we can all agree that the world would be a better place if
every project strictly followed semantic versioning and if people
interpreted version numbers accordingly. It would be a triumph of
science over mysticism. But we know that people don't do this and that
is why we are having this conversation. For some languages, taking
into account what people are used to doing is an important concern
(Java, C++). But I don't think that is Clojure's philosophy. Come on
people, it's a Lisp. It would have never been a Lisp if Rich cared
what the gut reaction of the masses would be. The core philosophy of
Clojure is to do it right (even if that is not popular) and then
convince people as to why this is the right way to do things. Clojure
isn't a Trojan horse, it's a beacon of hope. Let's continue that
tradition and not do something based on gut reactions. Let's do it
right and call it the backward incompatible version 2.0 that it is.
Maybe it will inspire other projects to do the same.

Brenton

On Feb 22, 6:27 pm, Christopher Redinger 
wrote:
> As you can see on the Release.Next Planning page [1], there is an open 
> question about whether or not the next version of Clojure should be 1.3 or 
> 2.0. The issue at hand is that we are introducing backwards incompatible API 
> changes. Not looking to start a debate at this point, but just taking a 
> temperature reading from the community. If you care about what the next 
> version number of Clojure is - could you please cast a vote in the poll here:
>
> https://spreadsheets.google.com/a/thinkrelevance.com/viewform?hl=en&f...
>
> Thanks!
>
> [1]http://dev.clojure.org/display/design/Release.Next+Planning
>
> --
> Christopher Redingerhttp://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


Re: Release.Next Version Number

2011-02-24 Thread Dennis Crenshaw
Inc is probably a better way to say that, yeah.

I also agree with David that 2.0 has a popular connotation of
shiny-ness that came with the whole infamous Web 2.0 branding
phenomenon.

I am now at conflict internally, because I'd like to see Clojure
widely adopted, but I like the idea of the language having the agility
to do radical things to make itself better in a way that Java no
longer posses. So 1.3 still has its advantages. Clojure always has the
choice to stay the transition to semantic versioning until Rich feels
that it's at a place that semantic versioning makes sense.

I believe I've thought myself in a circle and need some hammock time on this.

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


removing primitive support 4 or less restriction?

2011-02-24 Thread Seth
I know that this has come up - but when will the  restriction of "fns
taking primitives support only 4 or fewer args" be removed?

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


Re: Release.Next Version Number

2011-02-24 Thread Kevin Downey
you mean inc

On Thu, Feb 24, 2011 at 8:45 AM, Dennis Crenshaw  wrote:
> What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable
> to make a standard out of it. To quote Peter Drucker, "What gets
> measured gets managed." Are there any solid examples of languages that
> would constitute a good canonical spectrum for ecosystem versions and
> why?
>
> It seems like if the ecosystem surrounding a language is another
> concern in the semantic versioning equation that can't be sufficiently
> be expressed by the existing scheme, there should be a another
> digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0
> or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may
> mean, ecosystem surrounding it.)
>
> My points may also be a moot point, since it seems to make this SemVer
> compatible we might have to call it SemVer 1.1.0, or 2.0 depending on
> how people thought the extra digit(s) would affect the compatibility
> with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?)
>
> All this being said, I like the idea of semantic versioning and I wish
> more languages/software at least attempted some sort of version number
> scheme transparency. #(+ 1 %) to semantic versioning.
>
> TL;DR Can an ecosystem be properly versioned? Can that version be
> cleanly expressed by the current SemVer scheme?
>
> --
> 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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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


Re: Release.Next Version Number

2011-02-24 Thread David
Part of my underlying concern is one of branding and not directly based
on concerns about measuring and/or quantifying the quality of an
ecosystem.

I fully recognize that we could call the next iteration of Clojure "2.0"
and would be well within our rights. My point has been that calling it
2.0 may give people the impression that developing in the language is
seamless and well-polished. When they find out that it's not, Clojure
may experience some backlash.

(What's more, if Clojure wants to continue adding backwards-incompatible
features at the same rate that it is now, it would not be advisable to
bump the major version just yet.)

That said, I don't have a real problem saying the language itself is
2.0-worthy.

David

On Thu, 2011-02-24 at 11:45 -0500, Dennis Crenshaw wrote:
> What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable
> to make a standard out of it. To quote Peter Drucker, "What gets
> measured gets managed." Are there any solid examples of languages that
> would constitute a good canonical spectrum for ecosystem versions and
> why?
> 
> It seems like if the ecosystem surrounding a language is another
> concern in the semantic versioning equation that can't be sufficiently
> be expressed by the existing scheme, there should be a another
> digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0
> or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may
> mean, ecosystem surrounding it.)
> 
> My points may also be a moot point, since it seems to make this SemVer
> compatible we might have to call it SemVer 1.1.0, or 2.0 depending on
> how people thought the extra digit(s) would affect the compatibility
> with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?)
> 
> All this being said, I like the idea of semantic versioning and I wish
> more languages/software at least attempted some sort of version number
> scheme transparency. #(+ 1 %) to semantic versioning.
> 
> TL;DR Can an ecosystem be properly versioned? Can that version be
> cleanly expressed by the current SemVer scheme?
> 


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


Re: Release.Next Version Number

2011-02-24 Thread Dennis Crenshaw
What makes an ecosystem '1.x' vs '2.x' etc. needs to be quantifiable
to make a standard out of it. To quote Peter Drucker, "What gets
measured gets managed." Are there any solid examples of languages that
would constitute a good canonical spectrum for ecosystem versions and
why?

It seems like if the ecosystem surrounding a language is another
concern in the semantic versioning equation that can't be sufficiently
be expressed by the existing scheme, there should be a another
digit(s) or a whole other semantic version system for it (e.g. 1.2.0.0
or perhaps 0.1.0_2.0.0 for Clojure 2.0 with a basic, whatever that may
mean, ecosystem surrounding it.)

My points may also be a moot point, since it seems to make this SemVer
compatible we might have to call it SemVer 1.1.0, or 2.0 depending on
how people thought the extra digit(s) would affect the compatibility
with the SemVer spec as it stands. (Is it SemVer 1.0.0 right now?)

All this being said, I like the idea of semantic versioning and I wish
more languages/software at least attempted some sort of version number
scheme transparency. #(+ 1 %) to semantic versioning.

TL;DR Can an ecosystem be properly versioned? Can that version be
cleanly expressed by the current SemVer scheme?

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


Re: Release.Next Version Number

2011-02-24 Thread David
On Thu, 2011-02-24 at 11:33 -0500, Steve Miner wrote:
> The choice boils down to whether or not you want to follow Semantic 
> Versioning [1].  Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have 
> equivalent policies.  Personally, I think it's a perfectly logical approach 
> to increment the major version number for any backwards incompatible change.
> 
> Python officially has a more relaxed interpretation [5].  My understanding is 
> that in practice the Python community was very concerned about backwards 
> compatibility among the late 2.x releases because 3.0 was going to introduce 
> big changes.
> 
> > Python versions are numbered A.B.C or A.B. A is the major version number – 
> > it is only incremented for really major changes in the language. B is the 
> > minor version number, incremented for less earth-shattering changes. C is 
> > the micro-level – it is incremented for each bugfix release.
> 
> The Wikipedia article on software versioning [6] covers some other concerns 
> such as marketing.  I guess that takes into account the idea that "2.0" 
> should be a major improvement.
> 
> As I said, I personally like the concept of semantic versioning.  If Rich 
> wants to do something else, I can live with an incompatible 1.3.  In any 
> case, it would be useful for the Clojure Core team to document the Clojure 
> version policy.
> 
> 
> 
> [1] http://semver.org
> 
> [2] http://apr.apache.org/versioning.html
> 
> [3] http://wiki.eclipse.org/index.php/Version_Numbering
> 
> [4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
> 
> [5] 
> http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work
> 
> [6] http://en.wikipedia.org/wiki/Software_versioning
> 

I agree. One thing we should keep in mind is that if we're going to
follow semantic versioning, we should not plan *any*
backwards-incompatible changes in the near future. In other words, after
2.0, we should be done changing the language for a while, or we'll risk
bumping major versions on every release.

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


Re: Release.Next Version Number

2011-02-24 Thread Shantanu Kumar
I have noticed some projects go to an x.5 release when they are half-
ready to move to (inc x).0 -- in this case which would be 1.5 instead
of 1.3 or 2.0 version. Just a thought.

Regards,
Shantanu

On Feb 24, 7:56 pm, semperos  wrote:
> Another vote for semantic versioning. I agree that the "claim to 2.0" comes
> with some expectations about environment and overall development experience,
> but I think that *backwards incompatible changes* deserve a major version
> bump, to keep heads straight and make it clear to newcomers where the lines
> are drawn.
>
> If we don't make the switch now, at which future set of breaking changes
> will we decide it's time to call it 2.0? We'd basically have to create our
> own criteria and have the "Clojure flavored" semantic versioning scheme,
> which I think would be more arbitrary and harder for folks to follow.

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


Re: ANN: Clojure Toolbox (Early Beta)

2011-02-24 Thread Timothy Baldridge
I'd like to see some graphics libraries. Penumbra would be a great addition.

Timothy

On Thu, Feb 24, 2011 at 9:22 AM, Fernando Pazin  wrote:
> Awesome work!
>
> On 23 fev, 20:17, James Reeves  wrote:
>> I've put together a small, static site inspired by The Ruby Toolbox
>> (ruby-toolbox.com), called (of course) The Clojure Toolbox.
>

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


Re: Release.Next Version Number

2011-02-24 Thread Steve Miner
The choice boils down to whether or not you want to follow Semantic Versioning 
[1].  Apache (APR) [2], Eclipse [3], and OSGi [4] all seem to have equivalent 
policies.  Personally, I think it's a perfectly logical approach to increment 
the major version number for any backwards incompatible change.

Python officially has a more relaxed interpretation [5].  My understanding is 
that in practice the Python community was very concerned about backwards 
compatibility among the late 2.x releases because 3.0 was going to introduce 
big changes.

> Python versions are numbered A.B.C or A.B. A is the major version number – it 
> is only incremented for really major changes in the language. B is the minor 
> version number, incremented for less earth-shattering changes. C is the 
> micro-level – it is incremented for each bugfix release.

The Wikipedia article on software versioning [6] covers some other concerns 
such as marketing.  I guess that takes into account the idea that "2.0" should 
be a major improvement.

As I said, I personally like the concept of semantic versioning.  If Rich wants 
to do something else, I can live with an incompatible 1.3.  In any case, it 
would be useful for the Clojure Core team to document the Clojure version 
policy.



[1] http://semver.org

[2] http://apr.apache.org/versioning.html

[3] http://wiki.eclipse.org/index.php/Version_Numbering

[4] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

[5] 
http://docs.python.org/faq/general.html#how-does-the-python-version-numbering-scheme-work

[6] http://en.wikipedia.org/wiki/Software_versioning

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


Re: ANN: Clojure Toolbox (Early Beta)

2011-02-24 Thread Fernando Pazin
Awesome work!

On 23 fev, 20:17, James Reeves  wrote:
> I've put together a small, static site inspired by The Ruby Toolbox
> (ruby-toolbox.com), called (of course) The Clojure Toolbox.
>
> It's currently just a series of categorized links to Clojure projects,
> but I'll be gradually adding more functionality to it over the coming
> weeks. If you've been to the Ruby Toolbox site you'll likely know what
> to expect (project descriptions, links to Clojars, GitHub watchers and
> forks, etc.)
>
> The URL to the site is:
>
> http://www.clojure-toolbox.com
>
> I'm sure I've covered only a very small proportion of Clojure
> libraries out there, so if you'd like to suggest a project that's not
> on there, please do so in this thread, or in an email to me. I'll try
> and update the site as quickly as possible.
>
> - James

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


Re: Release.Next Version Number

2011-02-24 Thread semperos
Another vote for semantic versioning. I agree that the "claim to 2.0" comes 
with some expectations about environment and overall development experience, 
but I think that *backwards incompatible changes* deserve a major version 
bump, to keep heads straight and make it clear to newcomers where the lines 
are drawn.

If we don't make the switch now, at which future set of breaking changes 
will we decide it's time to call it 2.0? We'd basically have to create our 
own criteria and have the "Clojure flavored" semantic versioning scheme, 
which I think would be more arbitrary and harder for folks to follow.

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

noob question: pallet, crane, which criteria to choose which one ?

2011-02-24 Thread Laurent PETIT
Hello,

I need to automatise some current "manual" delivery process.

We have a fixed server (not -yet- the kind of "created on-demand" servers,
just a plain old server already configured), but for which there still needs
to be some manual delivery process.

Example :

 * deliver to pre-production:
   * input = git commit hash, maven version of some "tooling" artifacts
which are java artifacts, invoked via an mvn java execute target once the
right git revision has been checked out
   * output = publish the "app state" (created locally from the derived git
content) to a directory in the server, run a shell script on the server
which finishes the install, and, if everything went well, tag the commit,
and push the tag to the reference repo from which the content had been
initially pulled from

Note that this is not specifically centered around traditional "java webapp
deployment".

Would trying to use pallet or crane seem overkill ?

Any open suggestion ?

Cheers,

-- 
Laurent

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

Re: Clojure namespace conventions

2011-02-24 Thread Paul Richards
My goodness..  Seems like a can of worms.  :p

I think I'll pick something at least two levels deep like
"pauldoo.someproject", complete with ".core" and ".tools" as sub
namespaces..



On 23 February 2011 20:35, Mark Rathwell  wrote:
>
> This discussion has been had multiple times on this list, not sure how much
> new information you will get.  See the following for a couple examples:
> http://groups.google.com/group/clojure/browse_thread/thread/968e9066223c3a2b/fbce84869dbf4ce6?lnk=gst#
> http://groups.google.com/group/clojure/browse_thread/thread/78a32eeaacd659e/89304aeec4d00f7d?lnk=gst#
>
>
>
> On Wed, Feb 23, 2011 at 3:19 PM, Paul Richards 
> wrote:
>>
>> Hi,
>> Is there a guide to the conventions for naming and structuring
>> namespaces in a Clojure project?
>>
>> I see for example that the ".core" namespace is fairly common in
>> different projects.  Is this also where the "-main" entry point should
>> live?
>>
>> Also is it typical to have code living in "someproject" as well as
>> "someproject.tools", or should the former be promoted to
>> "someproject.core"?
>>
>>
>> --
>> Paul Richards
>> @pauldoo
>>
>> --
>> 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 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



-- 
Paul Richards
@pauldoo

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


Re: ANN: Clojure Toolbox (Early Beta)

2011-02-24 Thread Scott Jaderholm
On Wed, Feb 23, 2011 at 6:17 PM, James Reeves wrote:

> I'm sure I've covered only a very small proportion of Clojure
> libraries out there, so if you'd like to suggest a project that's not
> on there, please do so in this thread, or in an email to me. I'll try
> and update the site as quickly as possible.
>

Some that I like:
slice
scriptjure
clojurejs
cssgen
gaka

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

Re: Release.Next Version Number

2011-02-24 Thread Laurent PETIT
2011/2/24 Brian Marick 

>
> On Feb 23, 2011, at 3:06 PM, David Jacobs wrote:
>
> > Thanks for the suggestions. I should say that I was only giving you my
> impression of using Clojure re: it's version number. I'm not saying any of
> the things I listed are not doable, just that they feel very ad-hoc and not
> quite ready for a "2.0".
>
>
> I agree. My gut tells me "2.0" implies promises about the ecosystem and
> ease-of-adoption. Clojure 2.0 would be overpromising. Better to underpromise
> and overdeliver, as they say.
>

Well, day after day, I'm leaning more towards semantics versioning. Because,
heh, given the dilemnas that everybody spotted in each solution, why not
just choose the pragmatic and "semantic-full" versioning scheme ?

Do people really relate the numbers in Windows 7 and MacOS 10, for example ?
C'mon ...

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