20081217 Release
Rich Hickey
http://clojure.googlecode.com/files/clojure_20081217.zip
It reflects the many enhancements made since the last release:
AOT Compilation
gen-class
gen-interface
clojure.main
proxy performance tweaks
move to EPL
io! blocks
atoms
intern, trampoline, while
enhanced doto, doseq
uniform local bindings
print multimethods
print-dup
maps implement java.util.Map
agent watches
*1 et al
and many more fixes and enhancements:
http://code.google.com/p/clojure/source/list
This release should facilitate everyone using the same post-AOT API,
and brings us closer to the 1.0 release. I'll be going through the
docs to bring them up to date. If you are using an old release, please
move to this one, as it is what the documentation will reflect moving
forward.
There are a few small things marked high priority I'd like to get done
for 1.0:
http://code.google.com/p/clojure/issues/list?can=2&q=priority:High
Patches welcome from any registered contributors.
Thanks again for all of your support and feedback!
Rich
Mark Fredrickson
> and brings us closer to the 1.0 release. I'll be going through the
> docs to bring them up to date. If you are using an old release, please
> move to this one, as it is what the documentation will reflect moving
> forward.
Rich, if you put the docs in a public repo we could help with the
burden and submit patches (e.g. the slightly out of date code for the
Celsius calculator I noticed the other day).
Cheers,
-Mark
Rich Hickey
Yes, I plan to investigate using the Google Code wiki for the docs,
but not right now.
The calculator sample only became out of date last night when I cut a
new release - (the docs other than the API page reflect the most
recent release), and was changed last night to match the release.
That doesn't negate your point, just another item to do :)
Rich
Stuart Sierra
with clojure.lang.Repl, when all you need now is:
java -jar clojure.jar
-Stuart Sierra
Rich Hickey
On Dec 18, 10:44 am, Stuart Sierra <the.stuart.sie...@gmail.com>
wrote:
> with clojure.lang.Repl, when all you need now is:
> java -jar clojure.jar
>
think you want to show someone, as they will have to abandon that
method almost immediately.
Rich
Mark Volkmann
<the.stua...@gmail.com> wrote:
>
> FYI, I noticed that the readme.txt in the release still says to run
> with clojure.lang.Repl, when all you need now is:
> java -jar clojure.jar
I wonder how many people will really use it that way (with -jar). The
problem is that you can't also include clojure-contrib.jar if you use
that form. I'm guessing that almost everybody wants that in the
classpath too, but I could be wrong.
--
R. Mark Volkmann
Object Computing, Inc.
bc
> I've cut a new release, 20081217, which is available from Google Code:
>
> http://clojure.googlecode.com/files/clojure_20081217.zip
the September Clojure tarball and tried (with mixed success) to get a
working development environment setup. Some would have given up on
Clojure while others would have learned that they were better off
using the development svn/git versions of things. However, the
development versions of libraries are not always stable so you can
potentially waste a lot of time trying to get a development
environment setup. Sure you can run Clojure from a command line or use
a lisp-ignorant text editor, but nobody is really going to do that for
very long. There are some "packaged" options that have been proposed
in the past ("Clojure Box" is one), but not everyone wants/needs
something like that either (many developers are happy to have just the
Clojure & Wiki setup instructions). However, all potential new Clojure
developers would almost certainly like to know that the packages that
they need to install will actually work together. Therefore, it might
be worthwhile to discuss a process whereby tarballs of "core Clojure-
related development libraries" that are known to work with a specific
release are saved off to a specific location (so that noob's can be
pointed to the latest set of files that are known to work together
instead of having to struggle with setting up multiple different
libraries that may or may not work properly together at any given
point in time). Currently, there are 4 key 3rd-party libraries that
most people need for developing Clojure code:
1. clojure-contrib
2. slime
3. clojure-mode
4. swank-clojure
(in the future, perhaps the Gorilla/Netbeans/Eclipse libs too;
however, maybe there won't be as many interdependent libraries and
potential for "breakage" with those)
For clojure-contrib, it would make sense to create a matching tarball
whenever a Clojure release occurs. For the other 3, it would be
necessary for someone to test and save off a copy of the libraries
somewhere (that by itself would make getting started with Clojure a
much easier task).
I'm not sure what the best way to manage this (the "where" and "who")
would be. One option would be to store files in the Clojure Google
Groups file area (although this could be a bit problematic since the
Google Groups file area isn't very "flexible" and everything is
jumbled in there together). Another option is to maintain the 3rd
party tarballs as separate "Featured" downloads in the clojure-contrib
Google Code Downloads area. I think the latter might make more sense
as it would keep "release-related" tarballs all in the clojure-contrib
project without actually "polluting" the clojure-contrib source
repository with foreign libraries. It would also provide "ownership"
of the process (assuming the clojure-contrib members are willing to
take this on).
Since the clojure_20081217.zip release is "pre-1.0", maybe we don't
need to do anything yet; however, it would be nice to come up with a
Clojure-community approach to deal with this issue in preparation for
a "post-1.0" world.
Thoughts?
--
Bill Clementson
Meikel Brandmeyer
On 19 Dez., 02:10, bc <billc...@gmail.com> wrote:
> For clojure-contrib, it would make sense to create a matching tarball
> whenever a Clojure release occurs. For the other 3, it would be
> necessary for someone to test and save off a copy of the libraries
> somewhere (that by itself would make getting started with Clojure a
> much easier task).
>
> I'm not sure what the best way to manage this (the "where" and "who")
> would be.
third-party library. The "where" is probably the place
for the "who" hosts his project.
> One option would be to store files in the Clojure Google
> Groups file area (although this could be a bit problematic since the
> Google Groups file area isn't very "flexible" and everything is
> jumbled in there together). Another option is to maintain the 3rd
> party tarballs as separate "Featured" downloads in the clojure-contrib
> Google Code Downloads area. I think the latter might make more sense
> as it would keep "release-related" tarballs all in the clojure-contrib
> project without actually "polluting" the clojure-contrib source
> repository with foreign libraries. It would also provide "ownership"
> of the process (assuming the clojure-contrib members are willing to
> take this on).
place for such files. Concerning the contrib download
area: who decides, which projects are allowed to go
there? Who plays the postman who puts up the files?
(The upstream author is probably not allowed to...)
A centralised approach would be feasible if there was
some CCAN, where every author can upload his files
himself.
I would propose, that the files are hosted where ever
they are hosted now with suitable labels with which
Clojure version they work. This works out of the box
with the least amount of trouble.
Sincerely
Meikel
Mon Key
> they are hosted now with suitable labels with which
> Clojure version they work. This works out of the box
> with the least amount of trouble.
>
In contrast to the monolithic GG Code repo or C*AN or git/hg/bzr.*hubs
I find that the Emacswiki (while by no means perfect) is the best
model I have encountered for this sort thing because:
a) it acommodates small libs that can easily be extended into ones
working environment.
b) it allows for user interaction in a temporally adhoc manner
dissimilar from that of a maillist, IRC, static site, etc.
c) it promotes community interaction
d) it consolidates questions/answers regarding *particular* libs,
tasks, data-models, environs, etc.
e) it is independent of the core Emacs devels
f) anyone can play at any level
g) itsa wiki
h) it doesn't require code be hosted on a particular server
*****NOTE***** I am *not* suggesting that any approach toward this
model need be in any way tied to Emacs. It's just that Emacs happens
to be what prompted the Emacs Wiki - if there are other communities
with a similar flavor I am simply unaware of them.
Bill Clementson
On Thu, Dec 18, 2008 at 11:18 PM, Meikel Brandmeyer <m...@kotka.de> wrote:
> On 19 Dez., 02:10, bc <billc...@gmail.com> wrote:
>> For clojure-contrib, it would make sense to create a matching tarball
>> whenever a Clojure release occurs. For the other 3, it would be
>> necessary for someone to test and save off a copy of the libraries
>> somewhere (that by itself would make getting started with Clojure a
>> much easier task).
>>
>> I'm not sure what the best way to manage this (the "where" and "who")
>> would be.
>
> The "who" is probably the maintainer/developer of the
> third-party library.
Although this might seem logical, if fact it is probably not the best
solution because:
1. There are multiple inter-related projects (slime, clojure-mode,
swank-clojure) that would all need to be "snapshot-ed" simultaneously.
2. It assumes the developer(s) of the projects are interested in doing
this (SLIME developers support many lisp implementations).
3. The snapshot of all 3 inter-related projects (slime, clojure-mode,
swank-clojure) should occur after it has been confirmed that they all
currently work together with the latest clojure release.
> The "where" is probably the place
> for the "who" hosts his project.
Both swank-clojure and clojure-mode are hosted on git-hub. Although it
is possible to download a tar/zip file of the current set of files in
a git-hub repository, I didn't see any functionality to store other
"historical" snapshots.
SLIME (as mentioned above) is not clojure-specific. Historically, the
SLIME developers have not been keen to create snapshots.
>> One option would be to store files in the Clojure Google
>> Groups file area (although this could be a bit problematic since the
>> Google Groups file area isn't very "flexible" and everything is
>> jumbled in there together). Another option is to maintain the 3rd
>> party tarballs as separate "Featured" downloads in the clojure-contrib
>> Google Code Downloads area. I think the latter might make more sense
>> as it would keep "release-related" tarballs all in the clojure-contrib
>> project without actually "polluting" the clojure-contrib source
>> repository with foreign libraries. It would also provide "ownership"
>> of the process (assuming the clojure-contrib members are willing to
>> take this on).
>
> I don't think, that the Google Group is a suitable
> place for such files. Concerning the contrib download
> area: who decides, which projects are allowed to go
> there? Who plays the postman who puts up the files?
> (The upstream author is probably not allowed to...)
I agree, I just suggested it because it is an option. I think Google
Code is much better suited for this.
> A centralised approach would be feasible if there was
> some CCAN, where every author can upload his files
> himself.
>
> I would propose, that the files are hosted where ever
> they are hosted now with suitable labels with which
> Clojure version they work. This works out of the box
> with the least amount of trouble.
For the reasons I listed above, I don't think it's practical to do
this for slime, clojure-mode, and swank-clojure.
- Bill