On Sep 9, 8:04 pm, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote:
[...]
I think issues like that are fundamentally important if Clojure is to
be adopted for production work.
I agree - which is why I'm pushing on clojure-dev
On Sat, Sep 10, 2011 at 5:59 AM, Jan Rychter jrych...@gmail.com wrote:
On Sep 9, 8:04 pm, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote:
[...]
I think issues like that are fundamentally important if Clojure is to
be
+1
We have production code here and would like to see 1.3 out even if the contrib
issue
resolve itself later. The first stable release of 1.3 needs to get used as
widely
as possible.
If some issues emerge in 1.3 it would be better to know it as early as possible.
There are significant blocks
On Sep 10, 5:20 pm, Steve Purcell st...@sanityinc.com wrote:
David Nolen dnolen.li...@gmail.com writes:
Waiting for contrib authors to sort out their libraries seems
unrelated as to whether 1.3 should or should not be released. That's
like delaying Python 3 because libraries don't support
On Sat, Sep 10, 2011 at 12:46 PM, Jan Rychter jrych...@gmail.com wrote:
On Sep 10, 5:20 pm, Steve Purcell st...@sanityinc.com wrote:
David Nolen dnolen.li...@gmail.com writes:
Waiting for contrib authors to sort out their libraries seems
unrelated as to whether 1.3 should or should not
C in S-expression approach might be helpful, if you just want to write
C in Clojure syntax.
The advantage of this pure translator approach is you can fully
recognize what you do.
Such implementation already exist in Scheme.
http://practical-scheme.net/gauche/man/gauche-refe_76.html
I think
My worry is that the decoupling of core Clojure from contrib will
result in contrib authors not caring too much about sorting out the
current situation. Also, I think much of the fanfare of the 1.3
release will be shadowed by the contrib situation. And perhaps most
importantly, I worry that I
On Sat, Sep 10, 2011 at 2:59 AM, Jan Rychter jrych...@gmail.com wrote:
Thanks for the explanations. I'll summarize: clojure-contrib is being
reorganized. There is no clear migration path for applications that
use the monolithic 1.2 contrib. Not all of 1.2 contrib code made its
way into new
On Fri, Sep 9, 2011 at 11:04 AM, Sean Corfield seancorfi...@gmail.com wrote:
On Fri, Sep 9, 2011 at 1:09 AM, Jan Rychter jrych...@gmail.com wrote:
Take an example -- even in the relatively simple case of
clojure.contrib.combinatorics: note that it is NOT listed on
On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter jrych...@gmail.com wrote:
If you use Clojure to build an application that you subsequently
launch and maintain, it is pretty much a given that you use contrib.
Lots of it, in fact.
I think that depends on when you started building stuff with
You can use goog.dom/getChildren to get the children (I think it will
exclude the non-Nodes such as text and comments ) but it will return
an HTMLCollection doesn t implement ISeq, so you need to transform it
to a regular js array with goog.array/toArray.
something along these lines:
(ns
On Sep 10, 9:33 pm, Max Penet zcams...@gmail.com wrote:
You can use goog.dom/getChildren to get the children (I think it will
exclude the non-Nodes such as text and comments)
I meant non Element Nodes
--
You received this message because you are subscribed to the Google
Groups Clojure
+1
We were in production in Jan 2009 before Clojure 1.0 came out.
We face the issue of un-rooting ourselves from the old contrib stuff.
After analysis, 97% of the stuff we need from the old contrib is now
available in 1.3
as separate libs.
The only thing we would like to keep is the trace
On Sat, Sep 10, 2011 at 2:52 PM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
We were in production in Jan 2009 before Clojure 1.0 came out.
We face the issue of un-rooting ourselves from the old contrib stuff.
After analysis, 97% of the stuff we need from the old contrib is now
Greetings,
I would greatly appreciate any guidance on where to find a working and
complete set of instructions for how to set up Emacs with swank-
clojure. I am in Ubuntu.
I have followed exactly every step of the instructions on this page
I'm a clojure beginner and from the future api , the only way I found
to create a future from another is to block the resulting future's
thread with 'deref'. I'm a little bit afraid of exhausting my thread
pool.
For example:
(def x (future 1))
(def y (future (+ 1 @x)))
y will block and consume a
Greetings, Clojurers!
I've been playing with clojure, particularly with lazy sequences.
Some of the
results have left me puzzled, so I saved a REPL session wherein I
illustrate the points
of puzzlement. REPL lines are indented below; added comments are
unindented.
Clojure 1.2.1
I define a
the future thread pool is unbounded (it uses the same thread pool as send-off).
I have a library for composing async tasks like futures:
https://github.com/hiredman/die-geister
On Sat, Sep 10, 2011 at 12:12 PM, Illim illminou...@gmail.com wrote:
I'm a clojure beginner and from the future api ,
This was quite helpful for me.
http://technomancy.us/149
On Sat, Sep 10, 2011 at 1:29 PM, Curran curran.kelle...@gmail.com wrote:
Greetings,
I would greatly appreciate any guidance on where to find a working and
complete set of instructions for how to set up Emacs with swank-
clojure. I am
Follow these instructions, it will work..
http://riddell.us/ClojureWithEmacsSlimeSwankOnUbuntu.html
On 11 September 2011 10:15, Brian Mosley brian.d.mos...@gmail.com wrote:
This was quite helpful for me.
http://technomancy.us/149
On Sat, Sep 10, 2011 at 1:29 PM, Curran
20 matches
Mail list logo
