date:20090417


2009/4/16 Rich Hickey :
> What does 1.0 mean to you?

I just wanted to give some thoughts on what I think are the main
points coming from this discussion.  It seems like most agree that
"Clojure the language" is ready for a 1.0 release (and all that comes
with it).  The main issues are A) choice of VCS  and B) the state of
clojure-contrib.  Here's my thoughts on both:

A) VCS

Python has just changed from Subversion to Hg (there is a great PEP
article that details reasons for doing so here:
http://www.python.org/dev/peps/pep-0374/).  They did this because they
had a need to and at the moment Clojure doesn't have this need
(because there is only one person doing commits!).  While it seems
pointless changing technology for the sake of it, I also think - if
it's an inevitable change in the future - why not just do it now?
Rich - is changing VCS something you would consider at this stage?

B) clojure-contrib

For me, the purpose of clojure-contrib is a little confusing.  Is it
the Clojure standard library? well a lot of "standard" libraries are
not in clojure-contrib so I think the answer is no.  Is it a special
holder repos for code that might someday be moved up into the core
language?  Well, that's what I thought it was for but there is
currently stuff in there that will never be in the core language IMO.
I think we need to decide what clojure-contrib is before a 1.0 release
(or maybe it's already very clear and I have just missed something!).

In general, I think there should be only two "things" - the core
language and a set of libraries.  Whether the "libraries" are managed
CPAN-style or whether they are delivered as part of a standard library
(like with Python) I don't know at this point - but having a "special
third place" for libraries that may or may not go into core seems
unnecessary to me.

Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

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

Thanks all for the feedback. One impression I get is that it seems the
existing community is getting along ok on trunk, so perhaps we also
need to consider those not yet using Clojure, possibly even because of
a lack of 1.0.

I joked about book authors, but I'd like to make it clear that I think
it is very important that Stuart's book correspond to a release of
Clojure. It would be huge for newcomers coming to Clojure find a book
that says "Covers Clojure 1.0", and a compatible download for 1.0.x
with the latest fixes.

Stuart has worked hard on tracking the latest changes, as have I in
trying to get in those changes that would be breaking as soon as I
could before 1.0. I'm presuming it's not too late to get "Covers
Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
decision.

I'll also add that there is plenty more I'd like to do, and as soon as
I get into that trunk will again be changing rapidly. There simply has
to be a branch for fixes only.

As to the feedback:

A library management system seems like a tall order for a language
1.0. It is certainly an interesting and useful pursuit, but given the
variety of approaches and opinions therein, it seems a bit out in
front of us. Advantages of Maven vs Ivy vs whatever should be
separate. Git is not going to happen any time soon, great as it may
be, given the current lack of infrastructure (google code) and tools
support. Is there some respect in which this impacts the core? It
would seem dangerous to marry any single approach in the language
itself.

A deprecation policy is a good idea. Backward compatibility mode is
unlikely.

As for tests, there are tests in:

http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure

Anyone who wants more tests can contribute them.

Overall, I'm getting feature requests (more change!) and not a strong
drive for 1.0 stability. If you feel otherwise, please speak up.
Otherwise, my conclusion is that 1.0 may be more important for not-yet-
users wary of working from source.

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: The Path to 1.0

2009-04-17 Thread e

One possible approach that just occurred to me waking up this morning is to
just do it.  The very idea that now is a good time to ask the question is a
milestone.  1.0 marks the time that the question was asked as to what it
would take for there to be a 1l0!  That was a typo, I meant 1.0, but why use
a decimal point? call it 1|0, and then you can REALLY have your own
definition as to what the version meant.

Seriously, I agree that there would be power in having a book that
corresponds with 1.0 even to the extent that it were part of a title, like
"Clojure 1.0".
*
Ok, here's another perspective now:*

People talk about Erlang as being fairly unique in that distributed
computing was taken into consideration as part of the core language design
rather than being bootstrapped on top as an after thought.  Clojure has a
lot of nice design considerations along these lines, too.  If the 1.0 line
is drawn in the sand, and there are a lot of nice design ideas coming around
the corner, while baselining now (after moving a few things from the core
like file io) could make things feel more sane, if any of these changes
really are revolutionary, they might not have the same pizaz in a post 1.0
release.  They could with the right marketting, like "redesigned from the
ground up", or something, but it could be somewhat like Perl 6.0.  I hear
it's nice and maybe taking a look at, but when it first, finally came out,
the message I got (mostly from Perl people) was "don't bother".  That could
happen with a 2.0 or post 1.0, too.

On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey  wrote:

>
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book authors, but I'd like to make it clear that I think
> it is very important that Stuart's book correspond to a release of
> Clojure. It would be huge for newcomers coming to Clojure find a book
> that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> with the latest fixes.
>
> Stuart has worked hard on tracking the latest changes, as have I in
> trying to get in those changes that would be breaking as soon as I
> could before 1.0. I'm presuming it's not too late to get "Covers
> Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> decision.
>
> I'll also add that there is plenty more I'd like to do, and as soon as
> I get into that trunk will again be changing rapidly. There simply has
> to be a branch for fixes only.
>
> As to the feedback:
>
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us. Advantages of Maven vs Ivy vs whatever should be
> separate. Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach in the language
> itself.
>
> A deprecation policy is a good idea. Backward compatibility mode is
> unlikely.
>
> As for tests, there are tests in:
>
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure
>
> Anyone who wants more tests can contribute them.
>
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.
>
> 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: The Path to 1.0

2009-04-17 Thread Ozzi Lee


I feel the urge to drop a couple more pennies into this thread.

Trunk should NOT be used for day-to-day development and
experimentation. There should be a branch for that.

Trunk should NEVER be broken. Comprehensive tests need to run and pass
on the development branch before those changes are merged into trunk.

Subversion should NOT be used. Branching and merging are too
difficult. Distributed version contol makes this much easier.

Now, the issue of Rich's preferences comes in. Obviously, the current
development practices have worked pretty damn well so far. Perhaps
there is a way to allow the current SVN trunk to stand, and have
changes from there merged into another system for testing and
distribution. That would make SVN a private repository, for the most
part. Details would need to be worked out, but I think it's an avenue
worth exploring.
--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Luc Prefontaine

a) Stability ? Looks pretty fine to me up to now...

b) Getting 1.0 out ? Absolutely needed to increase the level of
acceptance of Clojure. Future releases will have to clearly documented
as to what they fix,
what changes have been done to the language itself and what it may
break in user code. But that's not a show stopper, it's been like that
for
years with most compilers/languages I worked with.  The time to
release another "official" build may be a bit longer to bundle the list
of changes.
It does not have to be fancy but maybe the comments added to each
SVN version should be expanded a bit to be more accessible to mere
mortals.
That could be the basis for release notes. Attaching bug reports to
release notes maybe harder, I do not see how you can achieve that with
Google code.

c) Clojure is unfinished ? Well that has been the state of most software
languages and tools for years. Will new enhancements require changes to
the core ?
Maybe, maybe not. Considering the available mechanisms built in
Clojure to extend itself, I do not see why we should worry now about
this, except if
Rich has another grandiose idea in the back of head that we are not
aware of : (Rich, maybe you should then consider creating another
dialect ? :
Considering the growing pains we faced with Java in the last 9
years, I think enhancing Clojure will be a breeze compared to the
maelstrom of JVM
bugs, compatibility issues and behaviour changes with had to deal
with.

d) Test suite ? Covering all cases is a long term task in any
programming language and just figuring out all these cases would
postponed 1.0 for months.
 Adding test cases along the way is the only practical alternative.
Maybe we should go with the requirement that a bug report should include
 a usable test case. That would at least reduce the work of the
person doing/integrating the fix in the code.

e) Is the current test framework fine ? Well until we think about
something else better, we should stick with it and just enrich that with
test cases.
Maybe we should adopt a test numbering that matches bug reports and
use that to update the existing test suites and track things.
No need for some heavy stuff, bare comments are enough. At least
that stuff will be documented somewhere.

f) Contrib library management ? That should be a top priority but Rich
is right getting this out in 1.0 is a tall order and people do not seem
to agree
   on what should be used. Personally, I think there are enough tools
out there and inventing another one is superfluous. I can understand
   why gems were created, I can understand the need for Lancet but
creating another Clojure-like maven ?
   Why not use something already there and put our energy on more
Clojure centric stuff ?

g) Changing the source code management tool ? Not a priority. How many
people to we expect to play on the core ? If we say that 500 people
 will make changes ok, we may have a problem with SVN and GIT might
be better at it. But I do not think we are there and I do not see that
 as a great idea (having hundreds of people working on the core).
Google code does the job so far, lets build on that.

Being afraid of committing to practises/tools is worst than moving
forward. We could wait for months/years juggling with what is the best
thing to commit to. Let's learn by mistakes a bit here... Each year
there will be a greater test framework/build tool/etc... but somehow we
have to make choices now...

Rich, maybe it's time to establish, following that 1.0 release, a set of
priorities ? I think we need some dictatorship here and
you are the best candidate from my point of view.
The idea is not to put more pressure/work on your shoulders but making
sure the delegation process is efficient to make Clojure move forward.
You seem to have other concepts to integrate in Clojure and that should
remain your main responsibility but for all the other stuff you
could establish the priorities and guidelines to follow. Then the
community could tackle these things in an orderly fashion.

Consensus can be a great thing but often it costs precious time...

Luc

On Fri, 2009-04-17 at 06:21 -0700, Rich Hickey wrote:

> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
> 
> I joked about book authors, but I'd like to make it clear that I think
> it is very important that Stuart's book correspond to a release of
> Clojure. It would be huge for newcomers coming to Clojure find a book
> that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> with the latest fixes.
> 
> Stuart has worked hard on tracking the latest changes, as have I in
> trying to get in those changes that would be breaking as soon as I
> could before 1.0. I'm presuming it's not too late to get "Covers
> Clojure 1.0" i

Re: The Path to 1.0

2009-04-17 Thread Jeff Heon


Strangely enough, for me version 1.0 would mean the version of Clojure
described in the book "Programming Clojure" by Stuart Halloway.

It would be a version that I could download directly even though newer
versions would appear afterward so the book and the Clojure version
are consistent with one another. Bug fixes to version 1.0 would be
nice too, but the main point is having the same behavior described in
version 1.0 and in the book.

Should it be necessary, the book could refer to features coming for
version 1.1.

--~--~-~--~~~---~--~~
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 bug of clojure.contrib.json.read

2009-04-17 Thread Robert Luo


the following code:

   (read-json-string (json-str {3 1}))

results NumberFormatException, I think maybe it does not expect
integer keys for a map.

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Paul Stadig

On Fri, Apr 17, 2009 at 9:21 AM, Rich Hickey  wrote:

> 
>
> As for tests, there are tests in:
>
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib/test_clojure
>
> Anyone who wants more tests can contribute them.
>

I think what would be useful, though, is to have a test suite with the
Clojure code. That way the suite is branched with the Clojure code. If a 1.0
branch is created in the Clojure code, then how does the test-clojure suite
relate to that? Would there be a 1.0 branch made of clojure-contrib, too?
Would there be any assurance that version X of the test-clojure suite can be
run against version X.Y of Clojure to verify there were no regressions?

And on clojure-contrib in general, I think maybe there needs to be a better
definition of what its scope is. Just because I have cool-whizz-bang Clojure
library does it mean that cool-whizz-bang should be made part of
clojure-contrib? clojure-contrib is for "user contributed code", but just
any code at all? As others have mentioned, clojure-contrib seems to include
some things that might warrant separate projects (like ClojureScript and
ClojureCLR). I don't see a problem with people creating Clojure libraries
and distributing them apart from clojure-contrib, but of course as soon as
the code starts to get distributed in different channels, you have the
dependency management issue. (ugh!)

Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.
>

I don't think that feature requests preclude a 1.0 release. I think all that
is warranted is partitioning the feature requests into releases. 1.0 will
include x, y, and z (and are labeled with Release-1.0 in the issue tracker).
2.0 will include a, b, and c (and are labeled so). As soon as x, y, and z
are completed, then you cut a 1.0 release. (*brushes off hands* "Now we
start on 2.0.") Of course you would have the flexibility (within reason) of
shifting features to earlier or later releases.

If a bug fix comes in, and it is determined that it should be backported
from trunk to the 1.0 branch, then label it so in the issues tracker, and
the 1.0 release captain can modify the test suite, and cut a 1.0.1 release.
There is already a list of "Primary Contributors" on the clojure.org site. I
nominate them as release captains :). I don't think that Rich needs to be
bothered with that sort of thing. I hesitate to say this, but if no one else
will do it, then I'll volunteer, since I got a pretty good idea of the inner
workings of Clojure with my Terracotta work.

All that said, Rich, don't feel rushed into making decisions about this. If
you're not comfortable, cutting a 1.0 release and starting the whole release
management process, then don't. It's getting close, but maybe it's not time
just yet. However, I don't think it's a matter of having to stop progress,
but just to create check points along the way, and to give people that
psychological ease of seeing 1.0.

Paul

--~--~-~--~~~---~--~~
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: Standard startup script?

2009-04-17 Thread Mark Volkmann


On Thu, Apr 16, 2009 at 4:10 PM, Marko Kocić  wrote:
>
> I have seen various scripts to start clojure in the net. Everyone
> seems to have its favourite, even contrib has one. Also, there are a
> lot of questions what is the "bestest" way to invoke clojure, how to
> start REPL, how to run script, compile file, should it be used with
> server or client VM.
>
> Do you think it would be benefitial to have such script included as
> part of standard clojure?

I think this would be beneficial, especially for beginners.

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Stuart Halloway


I would love to see 1.0, and the sooner the better. At Relevance we  
are doing real work in Clojure today.

As for wish list I would love to see improvements to the development  
process:

* move from svn to git
* move regression tests from contrib into clojure itself

But neither of these need necessarily to block 1.0 IMO.

When I release software that depends on Clojure I pin it to a commit  
number, not to a named release. For me the named release is more about  
public recognition than anything else.

Cheers,
Stu

P.S. Git is to svn as functional languages are to mutable languages.  
Git repositories are immutable data structures, and repos-local  
pointers such as HEAD are like atoms. It would be interesting to see  
Clojure's data structures have a canonicalized serialization and play  
around with content addressability.

> When we release software that depends on Clojure we don't care about  
> numbered releases at all -- we will run regression tests of our own  
> production app against the Clojure and contrib repositories and pin  
> our releases to a commit number, not a specif


>
> People (and not just book authors :) often ask - whither 1.0? [Ok,
> maybe they don't use 'whither']. The fact remains, some people want a
> 1.0 designation, and I'm not unwilling, providing we as a community
> can come to an understanding as to what that means, the process it
> implies, and the work it will require (and who will do it). Here are
> some of the relevant issues, IMO:
>
> - Stability/completeness/robustness
>
> This is mostly about - does it work? Is it relatively free of bugs? Is
> it free of gaping holes in core functionality? I think Clojure is in a
> pretty good place right now, but am obviously biased. This in no way
> implies there isn't room for improvement.
>
> - API stability
>
> With the semantic changes of fully lazy sequences behind us, I think
> the syntax and semantics of existing functions is largely stable.
>
> - Development process stability
>
> Currently all new work (fixes and enhancements) occurs in trunk.
> There's no way to get fixes without also getting enhancements. I think
> this is the major missing piece in offering stable numbered releases.
> While I've cut a branch for each of the prior two releases, no one has
> ever submitted a bugfix patch for either. If people are going to want
> to work with a particular release version for an extended period of
> time, someone (other than me) will have to produce patches of (only!)
> fixes from the trunk for the release branch, and occasionally produce
> point releases (1.0.x) from that branch. I'd like to continue to do
> the bulk of my work in trunk, without messing anyone up or forcing
> everyone to follow along.
>
> - Freedom from change
>
> Numbered releases are most definitely not about absence of change in
> general. There are more things I want to add and change, and there
> will be for some time. That will keep Clojure a living language. 1.0
> or any numbered release can't and won't constitute a promise of no
> further change. But there are different kinds of change,  changes that
> fix bugs and changes that add new capabilities or break existing code.
> People need to be able to choose the type of change they can tolerate,
> and when to incur it.
>
> - Perception
>
> Obviously, a 1.0 designation impacts perception. I am not interested
> in pursuing it just to influence perception, but rather to
> (collectively) acknowledge a milestone in usability and stability.
> However there may be other perceptions, good/bad or simply wrong (e.g.
> that Clojure is "finished").  Will the general perception engendered
> by 1.0 be met in the large, or a mismatch?
>
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
>
> Feedback welcome,
>
> 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: Standard startup script?

2009-04-17 Thread e

it was kind of annoying, at first, to have to type up the startup script
myself from the "getting started" wiki page (or cut-n-paste).  Seemed like
it should have come with the download, but once I dedicated some time to it,
it was ok.  Netbeans plugin, I think, was a good substitute when I just
wanted to dive in, but then I didn't really get what was going on, per se.
In the end, I now think it was good to walk through the getting started
page.  It's like clojure comes as a "kit car".  Then when you are driving
it, you have a better chance of having some idea how to pop the hood and
tinker.

On the other hand, I don't think this would appeal to potential python
converts who can install python, and five seconds later, and two lines of
code learn how to write a script to untar/unzip a file.  In that particular
case I think it was awesome that there was such an easy work-around to
windows not coming with a way to untar/unzip out of the box.  Easier to
install python and do it than any other solution, I found.  No admin rights
needed, no separate jvm/jdk/IDE download, etc.

2009/4/17 Mark Volkmann 

>
> On Thu, Apr 16, 2009 at 4:10 PM, Marko Kocić 
> wrote:
> >
> > I have seen various scripts to start clojure in the net. Everyone
> > seems to have its favourite, even contrib has one. Also, there are a
> > lot of questions what is the "bestest" way to invoke clojure, how to
> > start REPL, how to run script, compile file, should it be used with
> > server or client VM.
> >
> > Do you think it would be benefitial to have such script included as
> > part of standard clojure?
>
> I think this would be beneficial, especially for beginners.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Matt Revelle


On Apr 17, 9:21 am, Rich Hickey  wrote:
*snip*
>Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach in the language
> itself.

I wonder if git-svn could be used so that git could be used and the
google code repository treated as a central hub?  A quick google for
"git svn google code" turned up several interesting results, including
a few posts from one of Google's blogs [1].  Also, GitHub recently
added issue tracking.

-
1 
http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html
--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread John Newman

I vote for 1.0 as soon as possible.  Seems stable to me.  I'm working on a
chat application and when we moved to fully lazy sequences, still none of my
code broke.

I vote no on making contrib the "Standard Library."  The Java Standard
Library is large enough.  I would like contrib to be easier to get though.

On Fri, Apr 17, 2009 at 11:42 AM, Stuart Halloway  wrote:

>
> I would love to see 1.0, and the sooner the better. At Relevance we
> are doing real work in Clojure today.
>
> As for wish list I would love to see improvements to the development
> process:
>
> * move from svn to git
> * move regression tests from contrib into clojure itself
>
> But neither of these need necessarily to block 1.0 IMO.
>
> When I release software that depends on Clojure I pin it to a commit
> number, not to a named release. For me the named release is more about
> public recognition than anything else.
>
> Cheers,
> Stu
>
> P.S. Git is to svn as functional languages are to mutable languages.
> Git repositories are immutable data structures, and repos-local
> pointers such as HEAD are like atoms. It would be interesting to see
> Clojure's data structures have a canonicalized serialization and play
> around with content addressability.
>
> > When we release software that depends on Clojure we don't care about
> > numbered releases at all -- we will run regression tests of our own
> > production app against the Clojure and contrib repositories and pin
> > our releases to a commit number, not a specif
>
>
> >
> > People (and not just book authors :) often ask - whither 1.0? [Ok,
> > maybe they don't use 'whither']. The fact remains, some people want a
> > 1.0 designation, and I'm not unwilling, providing we as a community
> > can come to an understanding as to what that means, the process it
> > implies, and the work it will require (and who will do it). Here are
> > some of the relevant issues, IMO:
> >
> > - Stability/completeness/robustness
> >
> > This is mostly about - does it work? Is it relatively free of bugs? Is
> > it free of gaping holes in core functionality? I think Clojure is in a
> > pretty good place right now, but am obviously biased. This in no way
> > implies there isn't room for improvement.
> >
> > - API stability
> >
> > With the semantic changes of fully lazy sequences behind us, I think
> > the syntax and semantics of existing functions is largely stable.
> >
> > - Development process stability
> >
> > Currently all new work (fixes and enhancements) occurs in trunk.
> > There's no way to get fixes without also getting enhancements. I think
> > this is the major missing piece in offering stable numbered releases.
> > While I've cut a branch for each of the prior two releases, no one has
> > ever submitted a bugfix patch for either. If people are going to want
> > to work with a particular release version for an extended period of
> > time, someone (other than me) will have to produce patches of (only!)
> > fixes from the trunk for the release branch, and occasionally produce
> > point releases (1.0.x) from that branch. I'd like to continue to do
> > the bulk of my work in trunk, without messing anyone up or forcing
> > everyone to follow along.
> >
> > - Freedom from change
> >
> > Numbered releases are most definitely not about absence of change in
> > general. There are more things I want to add and change, and there
> > will be for some time. That will keep Clojure a living language. 1.0
> > or any numbered release can't and won't constitute a promise of no
> > further change. But there are different kinds of change,  changes that
> > fix bugs and changes that add new capabilities or break existing code.
> > People need to be able to choose the type of change they can tolerate,
> > and when to incur it.
> >
> > - Perception
> >
> > Obviously, a 1.0 designation impacts perception. I am not interested
> > in pursuing it just to influence perception, but rather to
> > (collectively) acknowledge a milestone in usability and stability.
> > However there may be other perceptions, good/bad or simply wrong (e.g.
> > that Clojure is "finished").  Will the general perception engendered
> > by 1.0 be met in the large, or a mismatch?
> >
> > What does 1.0 mean to you? Are we there yet? Any recommendations for
> > the organization of the release branches, patch policy etc?
> >
> > Feedback welcome,
> >
> > Rich
> >
> > >
>
>
> >
>


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

Can't Build clojure-contrib


Hi, I'm trying to build clojure-contrib and running into an issue. I
checked out clojure-contrib as follows and attempted to build it on my
machine. I get a compiler error when I run ant.

svn checkout http://clojure-contrib.googlecode.com/svn/trunk/ clojure-
contrib-read-only

 [java] java.lang.IncompatibleClassChangeError (types.clj:14)
 [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:194)
 [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:
764)
 [java] at org.apache.tools.ant.taskdefs.Java.executeJava
(Java.java:218)
 [java] at org.apache.tools.ant.taskdefs.Java.executeJava
(Java.java:132)
 [java] at org.apache.tools.ant.taskdefs.Java.execute
(Java.java:105)
 [java] at org.apache.tools.ant.UnknownElement.execute
(UnknownElement.java:288)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
 [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
 [java] at java.lang.reflect.Method.invoke(Method.java:597)
... many more lines of stack trace ...

I need clojure-contrib to build vimclojure (among other things). Any
help would be appreciated.

Travis

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

How's This Macro?


Hi guys. I'm in the process of learning Clojure and loving it so far.
I've been dabbling in Common Lisp for years, but Clojure has so many
nice features that it's rapidly becoming my language of choice.
Recently, I've been trying to get my head wrapped around macros and
that an `or macro' would be a good candidate since you want to defer
evaluation of arguments until absolutely necessary. I hacked this up,
and it seems to work, but I wanted to see if I could have done
anything better.

(defmacro my-or [& args]
   (let [head (first args)
  tail (rest  args)]
  (if (nil? tail)
  head
  `(if ~head
   ~head
   (my-or ~...@tail)

Thanks,
Travis

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Daniel Jomphe


> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.

My thought was that I very much like that you don't have to bother too
much with:

* release-quality documentation
* release-quality tests (because you obviously didn't need them much
until now)
* release planning
* release press coverage, interviews & such

...so that you can continue improving our baby as fast as you're used
to.

Therefore, if you can find a way to fit in the former without
hindering you too much for the latter, I'm 100% supporting for a 1.0
cut. Why? Because I've heard quite a few business deciders mention
that "we're waiting for a 2.0 release". Consequently, I think it would
be great to see a 1.0 release today so that we can see a 2.0 release
sooner than later. :) But not at the cost of your ability to thrive at
clojure's development.

That said, I'm definitely dedicating more and more of my time to
clojure. I'm willing to help with the former (doc & tests, as soon as
I'm ready) to help you focus on the latter. For this reason, although
I would prefer that clojure's tests be part of the core not the
contrib, I understand that it suits you better like it is for now, and
I support that. The same could be said of all the other issues that
have been mentioned, as long as they help you focus.

Whatever you decide, I'll definitely support your call.

Finally, the only thing that I ask of you, in support to Luc
Préfontaine, is for you to write up some priorities for us to help you
better.
--~--~-~--~~~---~--~~
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: Can't Build clojure-contrib

2009-04-17 Thread Konrad Hinsen


On Apr 17, 2009, at 18:20, tmountain wrote:

> Hi, I'm trying to build clojure-contrib and running into an issue. I
> checked out clojure-contrib as follows and attempted to build it on my
> machine. I get a compiler error when I run ant.

Which Clojure revision are you using, and which revision of clojure- 
contrib? I can compile and test clojure-contrib just fine using the  
most recent versions of everything.

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: Enlive questions

2009-04-17 Thread David Nolen


Wow, thanks for the guidance, Enlive is improving at a rapid clip! ;)

On Friday, April 17, 2009, Christophe Grand  wrote:
>
> Updating to reflect last changes:
>
> (def snipgets
>   (let [divs (select (html-resource "widget.html")
>                [[:div (attr? :tiptree:widget)]])]
>     (into {}
>       (for [div divs]
>         [(-> div :attrs :tiptree:widget)
>          (snippet div [root]
>           [widget]
>            [:div.value] (content (if widget
>                                    (:value widget)
>                                    "foo")))
>
>
>
> Christophe Grand a écrit :
>> select, snippet, at and template are macro sugar. If you _really_ want
>> to use first-class selectors then you'll have to deal directly with
>> states machines and use at*, select* and snippet* (I'm going to improve
>> their usability).
>>
>> While selectors aren't first class, they can be parametrized (as you did
>> in [[:div (attr= :tiptree:widget (str widgetType))]]). You can play with
>> compile-selector to see how selectors are expanded.
>>
>> Regarding your code, I'd like to warn you against using snippet like
>> that for performance reason (and it won't get any better when I make
>> templates rendering faster).
>> It's better to extract snippets once for all:
>>
>> (def snipgets
>>   (let [divs (mapcat #(select % [[:div (attr? :tiptree:widget)]])
>>                (html-resource "widget.html"))]
>>     (into {}
>>       (for [div divs]
>>         [(-> div :attrs :tiptree:widget)
>>          (snippet div [root]
>>           [widget]
>>            [:div.value] (content (if widget
>>                                    (:value widget)
>>                                    "foo")))
>>
>> (deftemplate my-app6 "app2.html"
>>  [widgets]
>>   [[:div (attr? :tiptree:replace)]]
>>     (fn [node]
>>       (let [widgetType (:tiptree:replace (:attrs node))]
>>         ((snipgets widgetType) ((keyword widgetType) widgets)
>>
>>
>> David Nolen a écrit :
>>
>>> On second thought, this is actually not that critical for what I'm
>>> trying to accomplish, and I'm not sure yet if I'll ever use such a
>>> feature. Macros that define snippets will probably suffice.
>>>
>>> (deftemplate my-app6 "app2.html"
>>>   [widgets]
>>>   [[:div (attr? :tiptree:replace)]]
>>>     (fn [node]
>>>       (let [widgetType (:tiptree:replace (:attrs node))]
>>> ((snippet "widget.html" [[:div (attr= :tiptree:widget (str widgetType))]]
>>> [widget]
>>> [:div.value] (content (if widget
>>> (:value widget)
>>> "foo")))
>>> ((keyword widgetType) widgets)
>>>
>>> (apply str
>>>        (my-app6 {:widgetA {:value "0"},
>>> :widgetB {:value "1"}}))
>>>
>>> Works for me, and this was in general the use case I was thinking of.
>>>
>>>
>>> On Thu, Apr 16, 2009 at 4:24 PM, David Nolen >> > wrote:
>>>
>>>     Because predicates in selectors no longer need to be quoted it
>>>     seems you can't use Enlive selectors in a first class way with
>>>     snippets:
>>>
>>>     (let [aselector [[:div (attr= :tiptree:widget "widgetA")]]]
>>>       ((snippet "widget.html" aselector
>>>        [some-map]
>>>        [:div.value] (content "foo")) {}))
>>>
>>>     I believe this might be one of my final big requests :) I
>>>     personally don't mind the quoted predicate forms, especially if
>>>     this would simplify making selectors first class.  This would
>>>     allow templates to dynamically generate snippets based on the
>>>     properties of a particular node.
>>>
>>>     There's been a wild flurry of updates to Enlive recently and I am
>>>     extremely excited about the possibilities.  Enlive is an idea
>>>     which should be ripped off by every web framework worth talking
>>>     about! ;) Thanks again for creating and maintaining it.
>>>
>>>     On Thu, Apr 16, 2009 at 7:15 AM, Christophe Grand
>>>     mailto:christophe@

--~--~-~--~~~---~--~~
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's This Macro?

2009-04-17 Thread Christophe Grand


tmountain a écrit :
> Hi guys. I'm in the process of learning Clojure and loving it so far.
> I've been dabbling in Common Lisp for years, but Clojure has so many
> nice features that it's rapidly becoming my language of choice.
> Recently, I've been trying to get my head wrapped around macros and
> that an `or macro' would be a good candidate since you want to defer
> evaluation of arguments until absolutely necessary. I hacked this up,
> and it seems to work, but I wanted to see if I could have done
> anything better.
>
> (defmacro my-or [& args]
>(let [head (first args)
>   tail (rest  args)]
>   (if (nil? tail)
>   head
>   `(if ~head
>~head
>(my-or ~...@tail)
>   

You could use multiples arities to replace the (if (nil?... and shorten 
your macro:

(defmacro my-or 
 ([head] head)
 ([head & tail]
   `(if ~head
  ~head
  (my-or ~...@tail

There's still a problem: ~head appears twice which means the code substituted 
to head can be called twice if it returns true.
(defmacro my-or 
 ([head] head)
 ([head & tail]
   `(let [x# ~head]
  (if x#
x#
(my-or ~...@tail)

hth,

Christophe




-- 
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: Can't Build clojure-contrib


Problem solved! As you suggested I had an out of date version of
Clojure. I downloaded the 2008 revision on accident. Thank you for the
help.

Travis

On Apr 17, 1:30 pm, Konrad Hinsen  wrote:
> On Apr 17, 2009, at 18:20, tmountain wrote:
>
> > Hi, I'm trying to build clojure-contrib and running into an issue. I
> > checked out clojure-contrib as follows and attempted to build it on my
> > machine. I get a compiler error when I run ant.
>
> Which Clojure revision are you using, and which revision of clojure-
> contrib? I can compile and test clojure-contrib just fine using the  
> most recent versions of everything.
>
> 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: The Path to 1.0

2009-04-17 Thread Luke VanderHart


To me, major version numbers means no more nor less than a marker
pointing to a stable, consistent release that can be easily referred
to consistently by everyone. It doesn't mean that there can't be
major, breaking changes for 2.0 (or even 1.5, whatever). I don't even
care what features are in that release, as long as it's stable and
useful.

But I'd like a release of Clojure 1.0 so I can say to people "this
works with version X", with 100% certainty that we're talking about
the exact same feature set. It's hard for new people to get working
with Clojure, as it is, because everything is in a constant state of
flux and you never know when an upgrade will break Slime, ect.
Coherent versioning eliminates this worry.

To me, a 1.0 release is all about reducing barriers for newcomers by
saying "this is definitely safe to use." The only reason NOT to
release 1.0 immediately, imho, is if a major change is just around the
corner.

Thanks,
-Luke

On Apr 16, 12:53 pm, Rich Hickey  wrote:
> People (and not just book authors :) often ask - whither 1.0? [Ok,
> maybe they don't use 'whither']. The fact remains, some people want a
> 1.0 designation, and I'm not unwilling, providing we as a community
> can come to an understanding as to what that means, the process it
> implies, and the work it will require (and who will do it). Here are
> some of the relevant issues, IMO:
>
> - Stability/completeness/robustness
>
> This is mostly about - does it work? Is it relatively free of bugs? Is
> it free of gaping holes in core functionality? I think Clojure is in a
> pretty good place right now, but am obviously biased. This in no way
> implies there isn't room for improvement.
>
> - API stability
>
> With the semantic changes of fully lazy sequences behind us, I think
> the syntax and semantics of existing functions is largely stable.
>
> - Development process stability
>
> Currently all new work (fixes and enhancements) occurs in trunk.
> There's no way to get fixes without also getting enhancements. I think
> this is the major missing piece in offering stable numbered releases.
> While I've cut a branch for each of the prior two releases, no one has
> ever submitted a bugfix patch for either. If people are going to want
> to work with a particular release version for an extended period of
> time, someone (other than me) will have to produce patches of (only!)
> fixes from the trunk for the release branch, and occasionally produce
> point releases (1.0.x) from that branch. I'd like to continue to do
> the bulk of my work in trunk, without messing anyone up or forcing
> everyone to follow along.
>
> - Freedom from change
>
> Numbered releases are most definitely not about absence of change in
> general. There are more things I want to add and change, and there
> will be for some time. That will keep Clojure a living language. 1.0
> or any numbered release can't and won't constitute a promise of no
> further change. But there are different kinds of change,  changes that
> fix bugs and changes that add new capabilities or break existing code.
> People need to be able to choose the type of change they can tolerate,
> and when to incur it.
>
> - Perception
>
> Obviously, a 1.0 designation impacts perception. I am not interested
> in pursuing it just to influence perception, but rather to
> (collectively) acknowledge a milestone in usability and stability.
> However there may be other perceptions, good/bad or simply wrong (e.g.
> that Clojure is "finished").  Will the general perception engendered
> by 1.0 be met in the large, or a mismatch?
>
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
>
> Feedback welcome,
>
> 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: Is Clojure production ready?

2009-04-17 Thread Aaron Feng


Thanks to all of you for the input.  It sounds like most people are
comfortable with the current state of clojure.  That is great to hear!
 I know there has been a lot of talk to "1.0fy" clojure yesterday.
Going 1.0 will definitely help us make the jump (maybe others too?).
I understand 1.0 is only a perception, but unfortunately it's an
important one for us.

If anyone is interested in possibly working on a large scale
concurrent financial project in clojure, and don't mind living in
Philadelphia, feel free to drop me an email with resume.

Thanks again,

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

clojure-swank and macro expansion


Up until now I have made do with a simple clojure repl in Emacs but as
I am playing around with macros I feel it's time to test drive
clojure-swank and it's fancy macro expansion features!

I have installed clojure-swank following the instructions on the wiki
and the installation seems to have worked.  I can launch slime and I
get a clojure repl.  If I evaluate a function, then switch back to my
editor and type the function name followed by a space the arguments
for the function appear thanks to Slime.  So far so good.

When it comes to trying out other commands some things work, things
don't work as expected.  While I am curious which features are
available and which features others use on a daily basis, at the
moment I just want to focus on getting macro expansion to work.

Can someone please explain what steps I need to take to get
macro-expansion to work from a stock swank-clojure installation?  I
tried following the steps explained in a previous thread (the pprint
announcement) but I get confused as these instructions refer to
cl-format which was before pprint was added to clojure-contrib.

Thanks,
Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread revoltingdevelopment


Rich,

A list of the things you know you want to add or change would be
useful to this discussion.  For all we know, there could be a game-
changer on that list that would suggest holding off on 1.0.

Aside from that, I think you are right about the psychology of
language adoption and book-buying.  Declaring 1.0 to coincide with the
content and publication date of Stuart's book is just an excellent
idea, regardless of all the other issues raised so far.

Regards,
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: The Path to 1.0

2009-04-17 Thread mikel




On Apr 17, 8:21 am, Rich Hickey  wrote:
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book authors, but I'd like to make it clear that I think
> it is very important that Stuart's book correspond to a release of
> Clojure. It would be huge for newcomers coming to Clojure find a book
> that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> with the latest fixes.
>
> Stuart has worked hard on tracking the latest changes, as have I in
> trying to get in those changes that would be breaking as soon as I
> could before 1.0. I'm presuming it's not too late to get "Covers
> Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> decision.
>
> I'll also add that there is plenty more I'd like to do, and as soon as
> I get into that trunk will again be changing rapidly. There simply has
> to be a branch for fixes only.
>
> As to the feedback:
>
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us. Advantages of Maven vs Ivy vs whatever should be
> separate. Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach in the language
> itself.
>
> A deprecation policy is a good idea. Backward compatibility mode is
> unlikely.
>
> As for tests, there are tests in:
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> Anyone who wants more tests can contribute them.
>
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.


I think you could call it 1.0 now, if you're ready for the kinds of
expectations and bug reports that version brings with it.I don't think
it is any kind of barrier to further experimentation and development.
I do think that you're right to think that slapping a 1.0 label on it
means there should be some specific revision that people can download
called "1.0", and reasonably expect to get a specific, stable set of
features.

Clozure Associates went through this exact discussion a couple years
ago when it considered whether to designate the next release of
OpenMCL (now called CCL) as "1.0". It had pretty much the same set of
considerations. In the end, Clozure did adopt the "1.0" designation,
and I think on the whole the effect has been positive; it helped bring
the general perception of CCL's maturity closer to the reality.

Go ahead and call Clojure "1.0", when you're ready to make sure
there's a "1.0" release people can download, and when you're ready for
an influx of bug reports from new users who are confused by foiled
preconceptions.
--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Cosmin Stejerean

On Thu, Apr 16, 2009 at 11:53 AM, Rich Hickey  wrote:

[...]

>
> - Development process stability
>
> Currently all new work (fixes and enhancements) occurs in trunk.
> There's no way to get fixes without also getting enhancements. I think
> this is the major missing piece in offering stable numbered releases.
> While I've cut a branch for each of the prior two releases, no one has
> ever submitted a bugfix patch for either. If people are going to want
> to work with a particular release version for an extended period of
> time, someone (other than me) will have to produce patches of (only!)
> fixes from the trunk for the release branch, and occasionally produce
> point releases (1.0.x) from that branch.


This is actually something that I am interested in doing (porting fixes from
trunk to 1.0) so I would love to help with that process once we get to 1.0

-- 
Cosmin Stejerean
http://offbytwo.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: clojure-swank and macro expansion

2009-04-17 Thread David Nolen

If you have the latest version of clojure.contrib you can do the following:
Modify the namespace declaration in swank-clojure/swank/commands/basic.clj
to look like the following:

(ns swank.commands.basic
  (:refer-clojure :exclude [load-file])
  (:use (swank util commands core)
(swank.util.concurrent thread)
(swank.util string clojure)
clojure.contrib.pprint)
  (:require (swank.util [sys :as sys]))
  (:import (java.io StringReader File)
   (java.util.zip ZipFile)
   (clojure.lang LineNumberingPushbackReader)))

In the same file modify apply-macro-expander to look like the following:

(defn- apply-macro-expander [expander string]
 (binding [*print-suppress-namespaces* true]
   (with-pprint-dispatch *code-dispatch*
 (write (expander (read-from-string string)) :pretty true :stream
nil

Now that pprint is a part of contrib, these two changes should probably be
incorporated into swank-clojure.

On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond wrote:

>
> Up until now I have made do with a simple clojure repl in Emacs but as
> I am playing around with macros I feel it's time to test drive
> clojure-swank and it's fancy macro expansion features!
>
> I have installed clojure-swank following the instructions on the wiki
> and the installation seems to have worked.  I can launch slime and I
> get a clojure repl.  If I evaluate a function, then switch back to my
> editor and type the function name followed by a space the arguments
> for the function appear thanks to Slime.  So far so good.
>
> When it comes to trying out other commands some things work, things
> don't work as expected.  While I am curious which features are
> available and which features others use on a daily basis, at the
> moment I just want to focus on getting macro expansion to work.
>
> Can someone please explain what steps I need to take to get
> macro-expansion to work from a stock swank-clojure installation?  I
> tried following the steps explained in a previous thread (the pprint
> announcement) but I get confused as these instructions refer to
> cl-format which was before pprint was added to clojure-contrib.
>
> Thanks,
> Paul.
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> & Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the
> intended recipient(s)") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> applicable law. If you are not the intended recipient, please contact
> the sender as soon as possible. The views expressed in this
> communication may not necessarily be the views held by The Company.
>
> >
>

--~--~-~--~~~---~--~~
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 bug of clojure.contrib.json.read


On Apr 17, 10:00 am, Robert Luo  wrote:
> the following code:
>
>    (read-json-string (json-str {3 1}))
>
> results NumberFormatException, I think maybe it does not expect
> integer keys for a map.

That's correct.  I was following the "pure" JSON spec at http://json.org/
which says that maps can only have strings as keys.  Maybe json-str
should enforce that.
-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
-~--~~~~--~~--~--~---

Re: The Path to 1.0

2009-04-17 Thread mifrai


Rich says  "Git is not going to happen any time soon, great as it may
be, given the current lack of  infrastructure (google code) and tools
support."

I'm curious as to why github isn't a viable alternative to google
code? Now that it has issue tracking, I don't see the advantages of
choosing google code over it (aside from the learning curve).

Mike

On Apr 17, 6:21 am, Rich Hickey  wrote:
> Thanks all for the feedback. One impression I get is that it seems the
> existing community is getting along ok on trunk, so perhaps we also
> need to consider those not yet using Clojure, possibly even because of
> a lack of 1.0.
>
> I joked about book authors, but I'd like to make it clear that I think
> it is very important that Stuart's book correspond to a release of
> Clojure. It would be huge for newcomers coming to Clojure find a book
> that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> with the latest fixes.
>
> Stuart has worked hard on tracking the latest changes, as have I in
> trying to get in those changes that would be breaking as soon as I
> could before 1.0. I'm presuming it's not too late to get "Covers
> Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> decision.
>
> I'll also add that there is plenty more I'd like to do, and as soon as
> I get into that trunk will again be changing rapidly. There simply has
> to be a branch for fixes only.
>
> As to the feedback:
>
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us. Advantages of Maven vs Ivy vs whatever should be
> separate. Git is not going to happen any time soon, great as it may
> be, given the current lack of infrastructure (google code) and tools
> support. Is there some respect in which this impacts the core? It
> would seem dangerous to marry any single approach in the language
> itself.
>
> A deprecation policy is a good idea. Backward compatibility mode is
> unlikely.
>
> As for tests, there are tests in:
>
> http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> Anyone who wants more tests can contribute them.
>
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.
>
> 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: The Path to 1.0

I guess there's really no perfect solution here :-(

The question is :

do you prefer to have some clojure users united against subversion, or
divided by Rich not having chosen their preferred DVCS (Mercurial users vs
Git users, not sure whether clojure needs those kinds of nonsense internal
wars in the community )

2009/4/17 mifrai 

>
> Rich says  "Git is not going to happen any time soon, great as it may
> be, given the current lack of  infrastructure (google code) and tools
> support."
>
> I'm curious as to why github isn't a viable alternative to google
> code? Now that it has issue tracking, I don't see the advantages of
> choosing google code over it (aside from the learning curve).
>
> Mike
>
> On Apr 17, 6:21 am, Rich Hickey  wrote:
> > Thanks all for the feedback. One impression I get is that it seems the
> > existing community is getting along ok on trunk, so perhaps we also
> > need to consider those not yet using Clojure, possibly even because of
> > a lack of 1.0.
> >
> > I joked about book authors, but I'd like to make it clear that I think
> > it is very important that Stuart's book correspond to a release of
> > Clojure. It would be huge for newcomers coming to Clojure find a book
> > that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> > with the latest fixes.
> >
> > Stuart has worked hard on tracking the latest changes, as have I in
> > trying to get in those changes that would be breaking as soon as I
> > could before 1.0. I'm presuming it's not too late to get "Covers
> > Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> > decision.
> >
> > I'll also add that there is plenty more I'd like to do, and as soon as
> > I get into that trunk will again be changing rapidly. There simply has
> > to be a branch for fixes only.
> >
> > As to the feedback:
> >
> > A library management system seems like a tall order for a language
> > 1.0. It is certainly an interesting and useful pursuit, but given the
> > variety of approaches and opinions therein, it seems a bit out in
> > front of us. Advantages of Maven vs Ivy vs whatever should be
> > separate. Git is not going to happen any time soon, great as it may
> > be, given the current lack of infrastructure (google code) and tools
> > support. Is there some respect in which this impacts the core? It
> > would seem dangerous to marry any single approach in the language
> > itself.
> >
> > A deprecation policy is a good idea. Backward compatibility mode is
> > unlikely.
> >
> > As for tests, there are tests in:
> >
> > http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
> >
> > Anyone who wants more tests can contribute them.
> >
> > Overall, I'm getting feature requests (more change!) and not a strong
> > drive for 1.0 stability. If you feel otherwise, please speak up.
> > Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> > users wary of working from source.
> >
> > 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: clojure-swank and macro expansion

2009-04-17 Thread Jeffrey Chu


Thanks for the tip. I've added it to swank-clojure (only if you have
clojure.contrib installed though, so don't forget to have that
around).

- Jeff

On Apr 17, 12:14 pm, David Nolen  wrote:
> If you have the latest version of clojure.contrib you can do the following:
> Modify the namespace declaration in swank-clojure/swank/commands/basic.clj
> to look like the following:
>
> (ns swank.commands.basic
>   (:refer-clojure :exclude [load-file])
>   (:use (swank util commands core)
>         (swank.util.concurrent thread)
>         (swank.util string clojure)
> clojure.contrib.pprint)
>   (:require (swank.util [sys :as sys]))
>   (:import (java.io StringReader File)
>            (java.util.zip ZipFile)
>            (clojure.lang LineNumberingPushbackReader)))
>
> In the same file modify apply-macro-expander to look like the following:
>
> (defn- apply-macro-expander [expander string]
>  (binding [*print-suppress-namespaces* true]
>    (with-pprint-dispatch *code-dispatch*
>      (write (expander (read-from-string string)) :pretty true :stream
> nil
>
> Now that pprint is a part of contrib, these two changes should probably be
> incorporated into swank-clojure.
>
> On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond 
> wrote:
>
>
>
> > Up until now I have made do with a simple clojure repl in Emacs but as
> > I am playing around with macros I feel it's time to test drive
> > clojure-swank and it's fancy macro expansion features!
>
> > I have installed clojure-swank following the instructions on the wiki
> > and the installation seems to have worked.  I can launch slime and I
> > get a clojure repl.  If I evaluate a function, then switch back to my
> > editor and type the function name followed by a space the arguments
> > for the function appear thanks to Slime.  So far so good.
>
> > When it comes to trying out other commands some things work, things
> > don't work as expected.  While I am curious which features are
> > available and which features others use on a daily basis, at the
> > moment I just want to focus on getting macro expansion to work.
>
> > Can someone please explain what steps I need to take to get
> > macro-expansion to work from a stock swank-clojure installation?  I
> > tried following the steps explained in a previous thread (the pprint
> > announcement) but I get confused as these instructions refer to
> > cl-format which was before pprint was added to clojure-contrib.
>
> > Thanks,
> > Paul.
> > --
> > Iode Software Ltd, registered in England No. 6299803.
>
> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> > & Wear, DH5 8NE.
>
> > This message is intended only for the use of the person(s) ("the
> > intended recipient(s)") to whom it is addressed. It may contain
> > information which is privileged and confidential within the meaning of
> > applicable law. If you are not the intended recipient, please contact
> > the sender as soon as possible. The views expressed in this
> > communication may not necessarily be the views held by The Company.
>
>
--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Mark Engelberg

On Fri, Apr 17, 2009 at 6:21 AM, Rich Hickey  wrote:
> Overall, I'm getting feature requests (more change!) and not a strong
> drive for 1.0 stability. If you feel otherwise, please speak up.
> Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> users wary of working from source.

I'm all for feature requests, but it's worth keeping in mind that some
feature requests make more sense at this stage than others.  I'd like
to see 1.0 include the sorts of feature requests that people have made
that complete, round out, or refine the existing functionality.

For example things that have been suggested here like:
* compare should work on lists and sequences, doing lexicographic
comparison like vectors
* merge functionality of repeat and replicate into one function and
deprecate the other.
* figure out what contrib functions should belong in the core.

It seems like once those sorts of changes have been made, it's worth
stamping a 1.0 label on everything before plowing ahead with the more
visionary changes such as streams, multimethod enhancements,
distributed systems, etc.

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Tom Faulhaber


Tom's 2 cents:

I think Clojure is basically ready to go to 1.0. I like the idea of
having a book about Clojure 1.0 go hand in hand with the release.

While I agree that the library management problem is too hard for a
1.0 release (and also largely separable), it would be nice to see the
software version number (e.g. 1.0.0) and the subversion number (e.g.
r1352) in the built clojure.jar somewhere that's easily accessible to
tools that are trying to do library management. My solution to this
would probably just be to generate a couple of (def *clojure-version-
number* "1.0.0") things as part of the build. Do any Java/Maven heads
have more sophisticated ideas that we should consider here? I've just
started hacking on some svn manipulation stuff (and a little bit of
jar manipulation) in the process of doing my contrib autodoc robot, so
I'd be happy to help here too.

While I agree that "what is clojure.contrib?" is a pretty big issue, I
think we could leave it a little fuzzy for a while longer. One thing
we should probably do is do a real comparison of how we stack up
against python's "batteries included" model and see how we need to
address that. (To my mind, the python library has always felt very ad
hoc.) I do not agree with John Newman that the Java standard library
should be the Clojure standard library. There's enough that's
different in Clojure that I think we do want some of our own ways to
approach things. I think there's also space for some great documents
(& screencasts, etc.) that show how to leverage parts of the Java
library to do cool things in Clojure. (Rich's demo of building swing
apps in Clojure comes to mind.)

I'd also like to see a little more focus on the perl/python/ruby
equivalence from a newbie perspective. That is, more clarity around
startup, script execution (including having an equivalent to python's
"if  __name__ == '__main__':" construct), class path management, etc.
I know that this is one area where being in the JVM ecosystem makes
our life worse rather than better, but approaching Clojure is still a
bit daunting compared to these other languages.

You can count me among the git fanboys, but I can't get too worked up
about moving off google code right now (and that would be necessary if
we switched to git). (Aside to Matt Revelle: You can use git-svn on
the client side (and I do) but that provides only a local solution, so
it isn't a magic bullet.)

Really, we all know that 1.0 means 1.0. Clojure will be much further
along than most other languages at their 1.0 point, so I wouldn't
stress over it too much.

I think that might have been 6 cents worth :-).

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: How's This Macro?


Thanks for the very informative reply!

On Apr 17, 1:40 pm, Christophe Grand  wrote:
> tmountain a écrit :
>
>
>
> > Hi guys. I'm in the process of learning Clojure and loving it so far.
> > I've been dabbling in Common Lisp for years, but Clojure has so many
> > nice features that it's rapidly becoming my language of choice.
> > Recently, I've been trying to get my head wrapped around macros and
> > that an `or macro' would be a good candidate since you want to defer
> > evaluation of arguments until absolutely necessary. I hacked this up,
> > and it seems to work, but I wanted to see if I could have done
> > anything better.
>
> > (defmacro my-or [& args]
> >    (let [head (first args)
> >           tail (rest  args)]
> >           (if (nil? tail)
> >               head
> >               `(if ~head
> >                    ~head
> >                    (my-or ~...@tail)
>
> You could use multiples arities to replace the (if (nil?... and shorten
> your macro:
>
> (defmacro my-or
>  ([head] head)
>  ([head & tail]
>    `(if ~head
>       ~head
>       (my-or ~...@tail
>
> There's still a problem: ~head appears twice which means the code substituted 
> to head can be called twice if it returns true.
> (defmacro my-or
>  ([head] head)
>  ([head & tail]
>    `(let [x# ~head]
>       (if x#
>         x#
>         (my-or ~...@tail)
>
> hth,
>
> Christophe
>
> --
> 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: clojure-swank and macro expansion


Thanks guys - it's great that this is in clojure-swank now as well!  I
simply updated and it works - no code changes required :)

It looks like slime-macroexpand-all doesn't do what I expected it to
do though.  Is it just the same as the clojure macroexpand function?
I was hoping it would do a "recursive" expansion to include sub-forms.
 I will keep digging...

Thanks again,
Paul.

2009/4/17 Jeffrey Chu :
>
> Thanks for the tip. I've added it to swank-clojure (only if you have
> clojure.contrib installed though, so don't forget to have that
> around).
>
> - Jeff
>
> On Apr 17, 12:14 pm, David Nolen  wrote:
>> If you have the latest version of clojure.contrib you can do the following:
>> Modify the namespace declaration in swank-clojure/swank/commands/basic.clj
>> to look like the following:
>>
>> (ns swank.commands.basic
>>   (:refer-clojure :exclude [load-file])
>>   (:use (swank util commands core)
>>         (swank.util.concurrent thread)
>>         (swank.util string clojure)
>> clojure.contrib.pprint)
>>   (:require (swank.util [sys :as sys]))
>>   (:import (java.io StringReader File)
>>            (java.util.zip ZipFile)
>>            (clojure.lang LineNumberingPushbackReader)))
>>
>> In the same file modify apply-macro-expander to look like the following:
>>
>> (defn- apply-macro-expander [expander string]
>>  (binding [*print-suppress-namespaces* true]
>>    (with-pprint-dispatch *code-dispatch*
>>      (write (expander (read-from-string string)) :pretty true :stream
>> nil
>>
>> Now that pprint is a part of contrib, these two changes should probably be
>> incorporated into swank-clojure.
>>
>> On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond 
>> wrote:
>>
>>
>>
>> > Up until now I have made do with a simple clojure repl in Emacs but as
>> > I am playing around with macros I feel it's time to test drive
>> > clojure-swank and it's fancy macro expansion features!
>>
>> > I have installed clojure-swank following the instructions on the wiki
>> > and the installation seems to have worked.  I can launch slime and I
>> > get a clojure repl.  If I evaluate a function, then switch back to my
>> > editor and type the function name followed by a space the arguments
>> > for the function appear thanks to Slime.  So far so good.
>>
>> > When it comes to trying out other commands some things work, things
>> > don't work as expected.  While I am curious which features are
>> > available and which features others use on a daily basis, at the
>> > moment I just want to focus on getting macro expansion to work.
>>
>> > Can someone please explain what steps I need to take to get
>> > macro-expansion to work from a stock swank-clojure installation?  I
>> > tried following the steps explained in a previous thread (the pprint
>> > announcement) but I get confused as these instructions refer to
>> > cl-format which was before pprint was added to clojure-contrib.
>>
>> > Thanks,
>> > Paul.
>> > --
>> > Iode Software Ltd, registered in England No. 6299803.
>>
>> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
>> > & Wear, DH5 8NE.
>>
>> > This message is intended only for the use of the person(s) ("the
>> > intended recipient(s)") to whom it is addressed. It may contain
>> > information which is privileged and confidential within the meaning of
>> > applicable law. If you are not the intended recipient, please contact
>> > the sender as soon as possible. The views expressed in this
>> > communication may not necessarily be the views held by The Company.
>>
>>
> >
>



-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
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: The Path to 1.0


2009/4/17 Laurent PETIT :
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community )

I agree the last thing we want to do is start flame wars on Git Vs
Mercurial (for example) - that is pointless.  There are many credible
comparisons between specific VCSs (the Python PEP 374 I mentioned
earlier in this thread being one of them).

The question for me is whether it's important to move to a
*distributed* VCS and not so much which one to pick.  Having thought a
bit more on it, while I would like to see a move to a DVCS personally,
I don't think it's important in the context of a 1.0 release.  I think
it's a completely separate issue.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
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: The Path to 1.0


2009/4/17 Tom Faulhaber :
> While I agree that "what is clojure.contrib?" is a pretty big issue, I
> think we could leave it a little fuzzy for a while longer. One thing
> we should probably do is do a real comparison of how we stack up
> against python's "batteries included" model and see how we need to
> address that. (To my mind, the python library has always felt very ad
> hoc.)

One of the best things about the Python library being
batteries-included is that it's easy for newcomers to get started.

> I'd also like to see a little more focus on the perl/python/ruby
> equivalence from a newbie perspective. That is, more clarity around
> startup, script execution (including having an equivalent to python's
> "if  __name__ == '__main__':" construct), class path management, etc.
> I know that this is one area where being in the JVM ecosystem makes
> our life worse rather than better, but approaching Clojure is still a
> bit daunting compared to these other languages.

This is one of the main problems with clojure-contrib for me.  I think
it would be awkward to have a 1.0 release with clojure-contrib left as
is and would cause confusion for newcomers.

Unless I am mistaken there are still many open questions regarding how
clojure-contrib is integrated with clojure such as its dependency
relationship with clojure.jar for example.  Surely, this sort of thing
needs ironing out before a 1.0 release?

I think various comments in the following recent thread summarises
some of the main issues well:

http://groups.google.com/group/clojure/browse_thread/thread/9cd8dbe421285be7/eae77c266022dc5e?lnk=raot

Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Luke VanderHart


My .02 on the version control issue:

All of them work. Some are easier to use than others. There are
successful projects that use just about all of them. It's personal
preference. Rich is going to be doing most the contributing, let him
choose the VCS.

Period.


On Apr 17, 4:29 pm, Laurent PETIT  wrote:
> I guess there's really no perfect solution here :-(
>
> The question is :
>
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community )
>
> 2009/4/17 mifrai 
>
>
>
> > Rich says  "Git is not going to happen any time soon, great as it may
> > be, given the current lack of  infrastructure (google code) and tools
> > support."
>
> > I'm curious as to why github isn't a viable alternative to google
> > code? Now that it has issue tracking, I don't see the advantages of
> > choosing google code over it (aside from the learning curve).
>
> > Mike
>
> > On Apr 17, 6:21 am, Rich Hickey  wrote:
> > > Thanks all for the feedback. One impression I get is that it seems the
> > > existing community is getting along ok on trunk, so perhaps we also
> > > need to consider those not yet using Clojure, possibly even because of
> > > a lack of 1.0.
>
> > > I joked about book authors, but I'd like to make it clear that I think
> > > it is very important that Stuart's book correspond to a release of
> > > Clojure. It would be huge for newcomers coming to Clojure find a book
> > > that says "Covers Clojure 1.0", and a compatible download for 1.0.x
> > > with the latest fixes.
>
> > > Stuart has worked hard on tracking the latest changes, as have I in
> > > trying to get in those changes that would be breaking as soon as I
> > > could before 1.0. I'm presuming it's not too late to get "Covers
> > > Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this
> > > decision.
>
> > > I'll also add that there is plenty more I'd like to do, and as soon as
> > > I get into that trunk will again be changing rapidly. There simply has
> > > to be a branch for fixes only.
>
> > > As to the feedback:
>
> > > A library management system seems like a tall order for a language
> > > 1.0. It is certainly an interesting and useful pursuit, but given the
> > > variety of approaches and opinions therein, it seems a bit out in
> > > front of us. Advantages of Maven vs Ivy vs whatever should be
> > > separate. Git is not going to happen any time soon, great as it may
> > > be, given the current lack of infrastructure (google code) and tools
> > > support. Is there some respect in which this impacts the core? It
> > > would seem dangerous to marry any single approach in the language
> > > itself.
>
> > > A deprecation policy is a good idea. Backward compatibility mode is
> > > unlikely.
>
> > > As for tests, there are tests in:
>
> > >http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
>
> > > Anyone who wants more tests can contribute them.
>
> > > Overall, I'm getting feature requests (more change!) and not a strong
> > > drive for 1.0 stability. If you feel otherwise, please speak up.
> > > Otherwise, my conclusion is that 1.0 may be more important for not-yet-
> > > users wary of working from source.
>
> > > 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: The Path to 1.0

2009-04-17 Thread Dan

On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:

> I guess there's really no perfect solution here :-(
>
> The question is :
>
> do you prefer to have some clojure users united against subversion, or
> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
> Git users, not sure whether clojure needs those kinds of nonsense internal
> wars in the community )
>

We seem to be unanimous in preferring git.

In the meantime, I'm using svn-git to track clojure's official repo. The
whole history of clojure is a mere 2 megabytes.

--~--~-~--~~~---~--~~
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-swank and macro expansion

2009-04-17 Thread David Nolen

This is the standard behavior. Just place the cursor over any other
unexpanded forms in the expansion buffer and run the command again. It will
expand again in place.

On Fri, Apr 17, 2009 at 5:22 PM, Paul Drummond wrote:

>
> Thanks guys - it's great that this is in clojure-swank now as well!  I
> simply updated and it works - no code changes required :)
>
> It looks like slime-macroexpand-all doesn't do what I expected it to
> do though.  Is it just the same as the clojure macroexpand function?
> I was hoping it would do a "recursive" expansion to include sub-forms.
>  I will keep digging...
>
> Thanks again,
> Paul.
>
> 2009/4/17 Jeffrey Chu :
> >
> > Thanks for the tip. I've added it to swank-clojure (only if you have
> > clojure.contrib installed though, so don't forget to have that
> > around).
> >
> > - Jeff
> >
> > On Apr 17, 12:14 pm, David Nolen  wrote:
> >> If you have the latest version of clojure.contrib you can do the
> following:
> >> Modify the namespace declaration in
> swank-clojure/swank/commands/basic.clj
> >> to look like the following:
> >>
> >> (ns swank.commands.basic
> >>   (:refer-clojure :exclude [load-file])
> >>   (:use (swank util commands core)
> >> (swank.util.concurrent thread)
> >> (swank.util string clojure)
> >> clojure.contrib.pprint)
> >>   (:require (swank.util [sys :as sys]))
> >>   (:import (java.io StringReader File)
> >>(java.util.zip ZipFile)
> >>(clojure.lang LineNumberingPushbackReader)))
> >>
> >> In the same file modify apply-macro-expander to look like the following:
> >>
> >> (defn- apply-macro-expander [expander string]
> >>  (binding [*print-suppress-namespaces* true]
> >>(with-pprint-dispatch *code-dispatch*
> >>  (write (expander (read-from-string string)) :pretty true :stream
> >> nil
> >>
> >> Now that pprint is a part of contrib, these two changes should probably
> be
> >> incorporated into swank-clojure.
> >>
> >> On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond <
> paul.drumm...@iode.co.uk>wrote:
> >>
> >>
> >>
> >> > Up until now I have made do with a simple clojure repl in Emacs but as
> >> > I am playing around with macros I feel it's time to test drive
> >> > clojure-swank and it's fancy macro expansion features!
> >>
> >> > I have installed clojure-swank following the instructions on the wiki
> >> > and the installation seems to have worked.  I can launch slime and I
> >> > get a clojure repl.  If I evaluate a function, then switch back to my
> >> > editor and type the function name followed by a space the arguments
> >> > for the function appear thanks to Slime.  So far so good.
> >>
> >> > When it comes to trying out other commands some things work, things
> >> > don't work as expected.  While I am curious which features are
> >> > available and which features others use on a daily basis, at the
> >> > moment I just want to focus on getting macro expansion to work.
> >>
> >> > Can someone please explain what steps I need to take to get
> >> > macro-expansion to work from a stock swank-clojure installation?  I
> >> > tried following the steps explained in a previous thread (the pprint
> >> > announcement) but I get confused as these instructions refer to
> >> > cl-format which was before pprint was added to clojure-contrib.
> >>
> >> > Thanks,
> >> > Paul.
> >> > --
> >> > Iode Software Ltd, registered in England No. 6299803.
> >>
> >> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> >> > & Wear, DH5 8NE.
> >>
> >> > This message is intended only for the use of the person(s) ("the
> >> > intended recipient(s)") to whom it is addressed. It may contain
> >> > information which is privileged and confidential within the meaning of
> >> > applicable law. If you are not the intended recipient, please contact
> >> > the sender as soon as possible. The views expressed in this
> >> > communication may not necessarily be the views held by The Company.
> >>
> >>
> > >
> >
>
>
>
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> & Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the
> intended recipient(s)") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> applicable law. If you are not the intended recipient, please contact
> the sender as soon as possible. The views expressed in this
> communication may not necessarily be the views held by The Company.
>
> >
>

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

Improving clojure.jar/clojure-contrib.jar compression (ClassLoader alternatives)

2009-04-17 Thread Dimiter "malkia" Stanev


I'm asking here question not directly related to Clojure, but related
to the JVM:

Is there any alternative (ClassLoader?) to store the .class files in a
different compressed format?.NET can store lots of classes in one
assembly? Is there something like that for JVM?

For example right now clojure.jar is 1.5MB, but that's because JAR
(which is ZIP based) is inefficient when storing lots of small
(.class) files. Instead a solid archive (.tar.gz) is more efficient.
The size goes to 0.5MB when compressed like that.

Same for clojure-contrib.jar - from 2mb .jar goes down to 1mb .tar.gz
- so instead of 3.5mb it goes down to 1.5MB in total.

Anyone has an insight (I myself am Java newbie), but I'm concerned
with the size of 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
-~--~~~~--~~--~--~---

Re: clojure-swank and macro expansion

2009-04-17 Thread Jeffrey Chu


It's supposed to - but I was too lazy to write a walker. Fortunately
there's a contrib for it now and I've added that feature. Again, this
needs contrib so if it's not there it'll fallback on plain old
macroexpand.

- Jeff

On Apr 17, 2:22 pm, Paul Drummond  wrote:
> Thanks guys - it's great that this is in clojure-swank now as well!  I
> simply updated and it works - no code changes required :)
>
> It looks like slime-macroexpand-all doesn't do what I expected it to
> do though.  Is it just the same as the clojure macroexpand function?
> I was hoping it would do a "recursive" expansion to include sub-forms.
>  I will keep digging...
>
> Thanks again,
> Paul.
>
> 2009/4/17 Jeffrey Chu :
>
>
>
>
>
> > Thanks for the tip. I've added it to swank-clojure (only if you have
> > clojure.contrib installed though, so don't forget to have that
> > around).
>
> > - Jeff
>
> > On Apr 17, 12:14 pm, David Nolen  wrote:
> >> If you have the latest version of clojure.contrib you can do the following:
> >> Modify the namespace declaration in swank-clojure/swank/commands/basic.clj
> >> to look like the following:
>
> >> (ns swank.commands.basic
> >>   (:refer-clojure :exclude [load-file])
> >>   (:use (swank util commands core)
> >>         (swank.util.concurrent thread)
> >>         (swank.util string clojure)
> >> clojure.contrib.pprint)
> >>   (:require (swank.util [sys :as sys]))
> >>   (:import (java.io StringReader File)
> >>            (java.util.zip ZipFile)
> >>            (clojure.lang LineNumberingPushbackReader)))
>
> >> In the same file modify apply-macro-expander to look like the following:
>
> >> (defn- apply-macro-expander [expander string]
> >>  (binding [*print-suppress-namespaces* true]
> >>    (with-pprint-dispatch *code-dispatch*
> >>      (write (expander (read-from-string string)) :pretty true :stream
> >> nil
>
> >> Now that pprint is a part of contrib, these two changes should probably be
> >> incorporated into swank-clojure.
>
> >> On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond 
> >> wrote:
>
> >> > Up until now I have made do with a simple clojure repl in Emacs but as
> >> > I am playing around with macros I feel it's time to test drive
> >> > clojure-swank and it's fancy macro expansion features!
>
> >> > I have installed clojure-swank following the instructions on the wiki
> >> > and the installation seems to have worked.  I can launch slime and I
> >> > get a clojure repl.  If I evaluate a function, then switch back to my
> >> > editor and type the function name followed by a space the arguments
> >> > for the function appear thanks to Slime.  So far so good.
>
> >> > When it comes to trying out other commands some things work, things
> >> > don't work as expected.  While I am curious which features are
> >> > available and which features others use on a daily basis, at the
> >> > moment I just want to focus on getting macro expansion to work.
>
> >> > Can someone please explain what steps I need to take to get
> >> > macro-expansion to work from a stock swank-clojure installation?  I
> >> > tried following the steps explained in a previous thread (the pprint
> >> > announcement) but I get confused as these instructions refer to
> >> > cl-format which was before pprint was added to clojure-contrib.
>
> >> > Thanks,
> >> > Paul.
> >> > --
> >> > Iode Software Ltd, registered in England No. 6299803.
>
> >> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> >> > & Wear, DH5 8NE.
>
> >> > This message is intended only for the use of the person(s) ("the
> >> > intended recipient(s)") to whom it is addressed. It may contain
> >> > information which is privileged and confidential within the meaning of
> >> > applicable law. If you are not the intended recipient, please contact
> >> > the sender as soon as possible. The views expressed in this
> >> > communication may not necessarily be the views held by The Company.
>
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
> & Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the
> intended recipient(s)") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> applicable law. If you are not the intended recipient, please contact
> the sender as soon as possible. The views expressed in this
> communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

concurrency skeletons

2009-04-17 Thread Raoul Duke


hi,

anybody have experience with / opinions / thoughts / feelings on
skeletons (design patterns) for concurrency?

e.g. http://camlp3l.inria.fr/eng.htm

might the approach be useful even with STM?

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
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-swank and macro expansion


Excellent!  Many thanks to you guys and Tom Faulhaber (the author of
pprint) - this feature has already helped me so much with debugging my
macro.

2009/4/18 Jeffrey Chu :
>
> It's supposed to - but I was too lazy to write a walker. Fortunately
> there's a contrib for it now and I've added that feature. Again, this
> needs contrib so if it's not there it'll fallback on plain old
> macroexpand.
>
> - Jeff
>
> On Apr 17, 2:22 pm, Paul Drummond  wrote:
>> Thanks guys - it's great that this is in clojure-swank now as well!  I
>> simply updated and it works - no code changes required :)
>>
>> It looks like slime-macroexpand-all doesn't do what I expected it to
>> do though.  Is it just the same as the clojure macroexpand function?
>> I was hoping it would do a "recursive" expansion to include sub-forms.
>>  I will keep digging...
>>
>> Thanks again,
>> Paul.
>>
>> 2009/4/17 Jeffrey Chu :
>>
>>
>>
>>
>>
>> > Thanks for the tip. I've added it to swank-clojure (only if you have
>> > clojure.contrib installed though, so don't forget to have that
>> > around).
>>
>> > - Jeff
>>
>> > On Apr 17, 12:14 pm, David Nolen  wrote:
>> >> If you have the latest version of clojure.contrib you can do the 
>> >> following:
>> >> Modify the namespace declaration in swank-clojure/swank/commands/basic.clj
>> >> to look like the following:
>>
>> >> (ns swank.commands.basic
>> >>   (:refer-clojure :exclude [load-file])
>> >>   (:use (swank util commands core)
>> >>         (swank.util.concurrent thread)
>> >>         (swank.util string clojure)
>> >> clojure.contrib.pprint)
>> >>   (:require (swank.util [sys :as sys]))
>> >>   (:import (java.io StringReader File)
>> >>            (java.util.zip ZipFile)
>> >>            (clojure.lang LineNumberingPushbackReader)))
>>
>> >> In the same file modify apply-macro-expander to look like the following:
>>
>> >> (defn- apply-macro-expander [expander string]
>> >>  (binding [*print-suppress-namespaces* true]
>> >>    (with-pprint-dispatch *code-dispatch*
>> >>      (write (expander (read-from-string string)) :pretty true :stream
>> >> nil
>>
>> >> Now that pprint is a part of contrib, these two changes should probably be
>> >> incorporated into swank-clojure.
>>
>> >> On Fri, Apr 17, 2009 at 2:39 PM, Paul Drummond 
>> >> wrote:
>>
>> >> > Up until now I have made do with a simple clojure repl in Emacs but as
>> >> > I am playing around with macros I feel it's time to test drive
>> >> > clojure-swank and it's fancy macro expansion features!
>>
>> >> > I have installed clojure-swank following the instructions on the wiki
>> >> > and the installation seems to have worked.  I can launch slime and I
>> >> > get a clojure repl.  If I evaluate a function, then switch back to my
>> >> > editor and type the function name followed by a space the arguments
>> >> > for the function appear thanks to Slime.  So far so good.
>>
>> >> > When it comes to trying out other commands some things work, things
>> >> > don't work as expected.  While I am curious which features are
>> >> > available and which features others use on a daily basis, at the
>> >> > moment I just want to focus on getting macro expansion to work.
>>
>> >> > Can someone please explain what steps I need to take to get
>> >> > macro-expansion to work from a stock swank-clojure installation?  I
>> >> > tried following the steps explained in a previous thread (the pprint
>> >> > announcement) but I get confused as these instructions refer to
>> >> > cl-format which was before pprint was added to clojure-contrib.
>>
>> >> > Thanks,
>> >> > Paul.
>> >> > --
>> >> > Iode Software Ltd, registered in England No. 6299803.
>>
>> >> > Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
>> >> > & Wear, DH5 8NE.
>>
>> >> > This message is intended only for the use of the person(s) ("the
>> >> > intended recipient(s)") to whom it is addressed. It may contain
>> >> > information which is privileged and confidential within the meaning of
>> >> > applicable law. If you are not the intended recipient, please contact
>> >> > the sender as soon as possible. The views expressed in this
>> >> > communication may not necessarily be the views held by The Company.
>>
>> --
>> Iode Software Ltd, registered in England No. 6299803.
>>
>> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
>> & Wear, DH5 8NE.
>>
>> This message is intended only for the use of the person(s) ("the
>> intended recipient(s)") to whom it is addressed. It may contain
>> information which is privileged and confidential within the meaning of
>> applicable law. If you are not the intended recipient, please contact
>> the sender as soon as possible. The views expressed in this
>> communication may not necessarily be the views held by The Company.
> >
>



-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person

Executable Namespace Proposal

2009-04-17 Thread Stephen C. Gilardi

On Apr 17, 2009, at 5:21 PM, Tom Faulhaber wrote:

> I'd also like to see a little more focus on the perl/python/ruby
> equivalence from a newbie perspective. That is, more clarity around
> startup, script execution (including having an equivalent to python's
> "if  __name__ == '__main__':" construct), class path management, etc.
> I know that this is one area where being in the JVM ecosystem makes
> our life worse rather than better, but approaching Clojure is still a
> bit daunting compared to these other languages.

I have a proposal for a standard way to make a namespace "executable"  
and to invoke it as a program/script.

The basic idea is to mark each namespace intended to be run as  
"program" such that its entry point can be found and to provide  
support for calling that entry point easily.

An outline:

 - add a key to the "ns" form to specify, as a symbol, the name of  
a function to be called when the namespace is "invoked" as a script.

 - I propose ":run" (with no default so no namespace is ever  
accidentally executable.)

 - If provided, the :run value in the ns form is stored as  
the :run value in the namespace's metadata.

 - The run function should

 - accept/expect Strings as arguments

 - it may accept any number of Strings using normal  
Clojure arity rules.

 - return an Integer

 - zero indicates success

 - non-zero indicates (some kind of) failure

 - error codes should be chosen and documented by  
the namespace author

 - add a function to clojure.core to run an executable namespace:

 - (run ns-name arg*)

 - requires the namespace

 - retrieves the namespace's :run value and resolves it to  
a var in the namespace.

 - calls that function via:
 (apply the-run-func args)

 - returns the integer that the-run-func returns

 - add support to clojure-main to handle a namespace name in  
"script position" by:

 - calling "run" on it, passing *command-line-args* in for the  
args.

 - returning the status value to the OS via Java's System/exit  
facility

This would be a change away from the current handling of scripts which  
simply loads them, expecting them to do their operation at load time.  
It also requires the resource (file) that contains the script be in  
classpath. (Though that's easy to accomplish by adding "" to classpath.)

With this method, we have a new standard way to invoke a script, and  
the scripts we load this way are "clean" in the sense that they don't  
run arbitrary code while loading. (They can, of course, run arbitrary  
code during macro expansion but it's still a good idea not to have  
bits of executable code laying around being loaded when the  
namespace's definition is loaded.)

A clear separation for scripts between load time and run time is a win.

Also with this method, we can treat (specially marked) namespaces that  
have already been loaded into Clojure as runnable entities (albeit  
with a rather restricted interface for arguments and return values).  
We can invoke them from other Clojure code as we would in a shell  
script, but without involving the OS at all.

Via string arguments, these Clojure scripts could also indicate/react- 
to a desire to use *in* *out* and *err* to communicate as  
corresponding UNIX tools would when run by the shell.

People who want to "run code from a file" will still be able to do so  
by using "load", but that would no longer be the supported mechanism  
for writing/using/invoking Clojure scripts.

Thoughts?

--Steve

smime.p7s
Description: S/MIME cryptographic signature

Re: The Path to 1.0

2009-04-17 Thread rzeze...@gmail.com


As with any decision, it will be impossible to please everyone.  I
think the Git vs Subversion talk is way off topic at this point, but
to each his own.

Rich, I think it really depends on what *YOU* want Clojure to be.  If
you want to take a Haskell like approach and "avoid success at all
costs" then I would delay 1.0 for as long as possible.  However, if
you want to bring on wide adoption, which I think you do, then I think
it is *IMPERATIVE* that the front of Stu's book includes the text
"Works for Clojure 1.0".

It is my opinion that if "Programming Clojure" goes to print without
that text Clojure, as a community and a language, loses a lot of
potential users!  It isn't a big deal to bleeding-edge folks like
ourselves, but we are a *MINORITY*.  And a minority is all we will be
if we think in minor terms.

I agree with a lot of what has been said here, but I feel Stu's book
release should be at the top of the list.  It's Clojure's first
impression on the global community of developers, and we all know the
rule about first impressions.

I vote pragmatism, lets get this sucker rolling!

-Ryan
--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread Antony Blakey


As a lurker, considering Clojure for a project, the thing that is  
giving me pause isn't 1.0 per se, but the combination of a good  
library mechanism and documentation. I have Stuart's book, and I agree  
in the strongest possible terms that it should be a book explicitly  
about a stable Clojure 1.0. The choice for me is between Scala and  
Clojure, and the languages themselves are not a discriminator - it's  
the environments around the languages that determine the outcome.

It's not clear how to use the stuff in clojure-contrib, which  
certainly seems like the 'standard library' of useful tools that makes  
clojure into something other than a lispy language using Java libraries.

Please don't under-estimate the extent to which good documentation, an  
obvious and clean code base (which clojure-contrib isn't) and a  
documented story for packaging and managing extensions/contributions,  
gives the impression of quality, at least with respect to the kind of  
'quality' that comforts and convinces arms-length users. The website  
is quite good in some of those respects for clojure core.

Also +1 for moving to git and github - in my experience it motivates  
contributions/contributors because it is such a low-barrier platform  
for collaborative/experimentation.

Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The ultimate measure of a man is not where he stands in moments of  
comfort and convenience, but where he stands at times of challenge and  
controversy.
   -- Martin Luther King



--~--~-~--~~~---~--~~
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: The Path to 1.0

2009-04-17 Thread mikel




On Apr 17, 8:31 pm, Antony Blakey  wrote:
> As a lurker, considering Clojure for a project, the thing that is  
> giving me pause isn't 1.0 per se, but the combination of a good  
> library mechanism and documentation. I have Stuart's book, and I agree  
> in the strongest possible terms that it should be a book explicitly  
> about a stable Clojure 1.0. The choice for me is between Scala and  
> Clojure, and the languages themselves are not a discriminator - it's  
> the environments around the languages that determine the outcome.
>
> It's not clear how to use the stuff in clojure-contrib, which  
> certainly seems like the 'standard library' of useful tools that makes  
> clojure into something other than a lispy language using Java libraries.


This is a good point. Using clojure.contrib is in fact extremely easy,
but it's hard to tell that from the point of view of a new user. I was
a new user recently enough to remember my initial confusion about how
to set up my development environment and how to arrange it so that
clojure.contrib was as readily accessible as it should be.

It turns out that getting past these obstacles is quite easy, but, as
I say, you can't tell that when you're coming in cold. That suggests
that documentation is the solution.
--~--~-~--~~~---~--~~
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: Executable Namespace Proposal

Hi,

This indeed seems like an improvement to me, since from then there will be
no excuse to have namespaces doing time or resource consuming operations
(I'm thinking about those scripts that automatically load GUIs, ...) at load
(and even compile *ouch*) time.

* Concerning the name of the keyword, may I suggest to use :main instead of
:run ? The word "main" is the convention in the java world for referencing a
candidate class for being the Main class of the application (Main is used in
MANIFESTs , in naming the public static void main(String args[]) ...) ?

* We could make this :main keyword play well with the :gen-class directive
if it is present in the namespace declaration :

Examples of use:

(ns
  (:main)) ; there could be a default name for the function (if :main is
present of course). This could be (-main) to offer a smooth migration if
later on the ns is gen-classed

(ns
  (:main)
  (:gen-class (:prefix "foo")) ; here :main would stay "aligned" with
:gen-class by default (DRY principle) and the main function of the ns would
be the main function of the class generated : (foo-main)

(ns
  (:main ns-main-function)) ; the main function for the ns is
ns-main-function.

(ns
  (:main ns-main-function)
  (:gen-class)) ; here since :main explicit defines a name, it is
intentionally not aligned with the generated class' main function

* Concerning the execution : it could be interesting, then, to be able to
launch such a script as one would launch a plain old java executable : java
-cpclojure.jar:classes/:src/ my.ns
Considering this last proposition, this would imply to even more closely
couple the use of the new :main keyword with the :gen-class directive.
Indeed, this would imply that if :main is used alone (without :gen-class at
all), the namespace would be compiled into a file. (And then, the value for
the function name better be just always aligned with the :gen-class').
Though, I'm not sure whether this last step is a good idea, since it forces
either to always compile namespaces that would be auto-executable, or either
to "auto-compile" the ns if the :main keyword is found (and I don't like the
idea of compiling ahead of time in the background, since the classes/
directory may well not have been placed in the classpath by the user).

What do you think about that ?

My 0,02 €,

-- 
Laurent

2009/4/18 Stephen C. Gilardi 

>
> On Apr 17, 2009, at 5:21 PM, Tom Faulhaber wrote:
>
> > I'd also like to see a little more focus on the perl/python/ruby
> > equivalence from a newbie perspective. That is, more clarity around
> > startup, script execution (including having an equivalent to python's
> > "if  __name__ == '__main__':" construct), class path management, etc.
> > I know that this is one area where being in the JVM ecosystem makes
> > our life worse rather than better, but approaching Clojure is still a
> > bit daunting compared to these other languages.
>
> I have a proposal for a standard way to make a namespace "executable"
> and to invoke it as a program/script.
>
> The basic idea is to mark each namespace intended to be run as
> "program" such that its entry point can be found and to provide
> support for calling that entry point easily.
>
> An outline:
>
> - add a key to the "ns" form to specify, as a symbol, the name of
> a function to be called when the namespace is "invoked" as a script.
>
> - I propose ":run" (with no default so no namespace is ever
> accidentally executable.)
>
> - If provided, the :run value in the ns form is stored as
> the :run value in the namespace's metadata.
>
> - The run function should
>
> - accept/expect Strings as arguments
>
> - it may accept any number of Strings using normal
> Clojure arity rules.
>
> - return an Integer
>
> - zero indicates success
>
> - non-zero indicates (some kind of) failure
>
> - error codes should be chosen and documented by
> the namespace author
>
> - add a function to clojure.core to run an executable namespace:
>
> - (run ns-name arg*)
>
> - requires the namespace
>
> - retrieves the namespace's :run value and resolves it to
> a var in the namespace.
>
> - calls that function via:
> (apply the-run-func args)
>
> - returns the integer that the-run-func returns
>
> - add support to clojure-main to handle a namespace name in
> "script position" by:
>
> - calling "run" on it, passing *command-line-args* in for the
> args.
>
> - returning the status value to the OS via Java's System/exit
> facility
>
> This would be a change away from the current handling of scripts which
> simply loads them, expecting them to do their operation at load time.
> It also requires the resource (file) that contains the script be in
> classpath. (Though that's easy to accomplish by adding " script>" to classpath.)
>
> With this method, we have a n

Re: Executable Namespace Proposal


On Apr 17, 7:16 pm, "Stephen C. Gilardi"  wrote:
> I have a proposal for a standard way to make a namespace "executable"  
> and to invoke it as a program/script.
...
>      - add a key to the "ns" form to specify, as a symbol, the name of  
> a function to be called when the namespace is "invoked" as a script.
...
> Thoughts?

I suggest using a "-main" function for this purpose.  Then with
(ns ... (:gen-class)) you can generate a static Java class with same
behavior.

And "public static void main(String[] args)" is already the standard
Java way to make a class executable.

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

Re: Improving clojure.jar/clojure-contrib.jar compression (ClassLoader alternatives)

On Apr 17, 7:36 pm, "Dimiter \"malkia\" Stanev" 
wrote:
> Is there any alternative (ClassLoader?) to store the .class files in a
> different compressed format?.NET can store lots of classes in one
> assembly? Is there something like that for JVM?

ClassLoaders can do almost anything, including load classes via HTTP,
so I expect it would be possible to write a custom ClassLoader that
uses a different compression format (like tar.gz).  But it wouldn't
necessarily be easy.  ZIP is convenient because it permits random
access to any file within the archive, which tar does not.

Here's an (old) article with a related example:
http://www.javaworld.com/javaworld/jw-04-2000/jw-0421-zipclass.html

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

Re: concurrency skeletons


On Apr 17, 7:59 pm, Raoul Duke  wrote:
> anybody have experience with / opinions / thoughts / feelings on
> skeletons (design patterns) for concurrency?
>
> e.g.http://camlp3l.inria.fr/eng.htm

Some of these might be useful in Clojure.  Some already exist --
parallel map, for example.

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

Re: The Path to 1.0

2009/4/18 Dan 

>
>
> On Fri, Apr 17, 2009 at 4:29 PM, Laurent PETIT wrote:
>
>> I guess there's really no perfect solution here :-(
>>
>> The question is :
>>
>> do you prefer to have some clojure users united against subversion, or
>> divided by Rich not having chosen their preferred DVCS (Mercurial users vs
>> Git users, not sure whether clojure needs those kinds of nonsense internal
>> wars in the community )
>>
>
> We seem to be unanimous in preferring git.

A last word from me on the subject : unanimous is certainly not the right
term here, if you consider that at least Rich disagrees (and unanimity
implies "all people", not even one let apart).
And you can also count on me, Meikel Brandmeyer (author of VimClojure),
maybe Paul Drummond (?) that pointed to python's decision to use Mercurial.

But if 'unanimity' is not the right word, I admit that it seems that
'majority' would be.

Anyway, since I don't want to start or continue a pointless DVCS comparison
war, I won't even give any argument here in favor of mercurial or git.

Rich is the main maintainer of clojure source, just let him use the DVCS he
wants. And really, it's not that difficult to checkout a working copy of
svn, hack on it, and do a svn diff > mypatch.diff to send him when ready (so
more complex management cases may well be easier with DVCs in the
contributor side, of course) ...

Regards,

-- 
Laurent

>
> In the meantime, I'm using svn-git to track clojure's official repo. The
> whole history of clojure is a mere 2 megabytes.
>
>
> >
>

--~--~-~--~~~---~--~~
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: The Path to 1.0

2009/4/18 Laurent PETIT 

>
>
>
> Rich is the main maintainer of clojure source, just let him use the DVCS he
> wants. And really, it's not that difficult to checkout a working copy of
> svn, hack on it, and do a svn diff > mypatch.diff to send him when ready (so
> more complex management cases may well be easier with DVCs in the
> contributor side, of course) ...
>

 :%s/so/though

(you see Meikel, I know some Vim commands as well ;-)

--~--~-~--~~~---~--~~
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: Executable Namespace Proposal

2009/4/18 Stuart Sierra 

>
> On Apr 17, 7:16 pm, "Stephen C. Gilardi"  wrote:
> > I have a proposal for a standard way to make a namespace "executable"
> > and to invoke it as a program/script.
> ...
> >  - add a key to the "ns" form to specify, as a symbol, the name of
> > a function to be called when the namespace is "invoked" as a script.
> ...
> > Thoughts?
>
> I suggest using a "-main" function for this purpose.  Then with
> (ns ... (:gen-class)) you can generate a static Java class with same
> behavior.
>
> And "public static void main(String[] args)" is already the standard
> Java way to make a class executable.
>

There should be STMs for e-mails :-)

I agree with Stuart's answer, of course, just wanted to add that it could
also be "watheverprefix-main" if (:gen-class) defines a prefix.
And I still see value in having the :main keyword if the (:gen-class) is not
necessary.

Regards,

-- 
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
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: The Path to 1.0

Hi Rich,

Every decision is a balance and will have good and bad aspects, of course.

In the good aspects of releasing a 1.0 quickly, is the fact that (coupled
with Stu's book release) I can try to more succesfully promote clojure
internally in my company (Ah, these psychological issues ;-).

In the bad aspects, are of course, some things I would like to see more
"polished" before releasing a 1.0.

By "polished", I don't necessary am asking for still adding more
functionality, but cleaning up things here and there.
Especially, removing complexity where it's not needed would be good, because
it eases the learning curve for newcomers.
I'm thinking here of the ns <-> lib somewhat unneeded distinction, which may
cause newcomers halt to think about it for (I think) no good reason.
Something like : "Wait, in the ns doc, they speak about something called a
"lib-spec". Lib definitely looks like the prefix of "library", so there must
be the concept of "library" in clojure. Where is it ? ... search ... search
... search  well it doesn't seem to me that there is stuff related to
library in a way that it differs from stuff related to namespaces  think
... think ... think ... is it me that doesn't understand something ? ...
think ... think ... is it just over engineering ".

Multiply the above thoughts by the number of newcomers.

If I'm right, I am candidate to submit patches for removing "lib-spec" from
clojure source, clojure-contrib and wiki documentation.

Regards,

-- 
Laurent

2009/4/16 Rich Hickey 

>
> People (and not just book authors :) often ask - whither 1.0? [Ok,
> maybe they don't use 'whither']. The fact remains, some people want a
> 1.0 designation, and I'm not unwilling, providing we as a community
> can come to an understanding as to what that means, the process it
> implies, and the work it will require (and who will do it). Here are
> some of the relevant issues, IMO:
>
> - Stability/completeness/robustness
>
> This is mostly about - does it work? Is it relatively free of bugs? Is
> it free of gaping holes in core functionality? I think Clojure is in a
> pretty good place right now, but am obviously biased. This in no way
> implies there isn't room for improvement.
>
> - API stability
>
> With the semantic changes of fully lazy sequences behind us, I think
> the syntax and semantics of existing functions is largely stable.
>
> - Development process stability
>
> Currently all new work (fixes and enhancements) occurs in trunk.
> There's no way to get fixes without also getting enhancements. I think
> this is the major missing piece in offering stable numbered releases.
> While I've cut a branch for each of the prior two releases, no one has
> ever submitted a bugfix patch for either. If people are going to want
> to work with a particular release version for an extended period of
> time, someone (other than me) will have to produce patches of (only!)
> fixes from the trunk for the release branch, and occasionally produce
> point releases (1.0.x) from that branch. I'd like to continue to do
> the bulk of my work in trunk, without messing anyone up or forcing
> everyone to follow along.
>
> - Freedom from change
>
> Numbered releases are most definitely not about absence of change in
> general. There are more things I want to add and change, and there
> will be for some time. That will keep Clojure a living language. 1.0
> or any numbered release can't and won't constitute a promise of no
> further change. But there are different kinds of change,  changes that
> fix bugs and changes that add new capabilities or break existing code.
> People need to be able to choose the type of change they can tolerate,
> and when to incur it.
>
> - Perception
>
> Obviously, a 1.0 designation impacts perception. I am not interested
> in pursuing it just to influence perception, but rather to
> (collectively) acknowledge a milestone in usability and stability.
> However there may be other perceptions, good/bad or simply wrong (e.g.
> that Clojure is "finished").  Will the general perception engendered
> by 1.0 be met in the large, or a mismatch?
>
> What does 1.0 mean to you? Are we there yet? Any recommendations for
> the organization of the release branches, patch policy etc?
>
> Feedback welcome,
>
> 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: The Path to 1.0


On Apr 17, 9:21 am, Rich Hickey  wrote:
> A library management system seems like a tall order for a language
> 1.0. It is certainly an interesting and useful pursuit, but given the
> variety of approaches and opinions therein, it seems a bit out in
> front of us.

Yes.  I retract my request. :)  But it's worth thinking about, given
the level of interest recently.

I don't care about git/svn/whatever.  It's pretty easy to bridge
between them these days.

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

Re: The Path to 1.0


2009/4/18 Laurent PETIT :
> [snip] at least Rich disagrees (and unanimity
> implies "all people", not even one let apart).
> And you can also count on me, Meikel Brandmeyer (author of VimClojure),
> maybe Paul Drummond (?) that pointed to python's decision to use Mercurial.

I have only used SVN myself and so don't have any preference regarding
Mercurial Vs Git Vs any-other-DVCS-out-there.  As I mentioned earlier,
I think Clojure should use a *distributed* VCS one day (the sooner the
better) but - importantly - that decision isn't relevant to a 1.0
release.

Paul.
-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.

--~--~-~--~~~---~--~~
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: Executable Namespace Proposal

2009-04-17 Thread Stephen C. Gilardi



On Apr 17, 2009, at 10:28 PM, Stuart Sierra wrote:


I suggest using a "-main" function for this purpose.  Then with
(ns ... (:gen-class)) you can generate a static Java class with same
behavior.


And if the :gen-class clause renamed main would the main function for  
this namespace be that named function?



And "public static void main(String[] args)" is already the standard
Java way to make a class executable.


There's currently no way to return a "status" value from an argument  
with that signature without using System/exit which has the  
unfortunate side effect of also shutting down the JVM.


We could create a var for the status return analogous to *command-line- 
args*. One could wrap the invocation of the main function with:


(binding [*command-line-status* 0]
  (apply the-main *command-line-args*)
  *command-line-status*)

Which would assume success, but allow the-main to indicate another  
status code with


(set! *command-line-status* the-status)

--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: Executable Namespace Proposal