Re: [parallel][incanter]State, how to do it right ? (rng state for parallel computing)

[Lee Spector]

On Jul 22, 2011, at 11:20 AM, bernardH wrote:
> 
> But there is a small catch : most of the time is spent in the Random
> Number Generator [3] so it would be sub-optimal to just have worker
> threads processing the output of a single threaded rng.

I am not very confident in my solution to a similar problem, and my application 
makes measurement difficult, but in case it's food for thought what I did was 
the following, using the standard Java rng:

;; create a root binding for the "thread-local-random-generator", although this 
won't be used in the distributed code:

(def thread-local-random-generator (new java.util.Random))

;; create some work-alikes to rand-int and lrand-int that use the thread local 
generator

(defn lrand-int
  "Return a random integer, using the thread-local random generator, that is 
less than the
provided n. Arguments greater than 2^31-1 are treated as if they were 2^31-1 
(2147483647)."
  [n]
  (if (<= n 1)
0
(if (= (type n) java.lang.Integer)
  (. thread-local-random-generator (nextInt n))
  (. thread-local-random-generator (nextInt 2147483647) ;; biggest 
java.lang.Integer

(defn lrand
  "Return a random float between 0 and 1 usng the thread-local random 
generator."
  ([] (. thread-local-random-generator (nextFloat)))
  ([n] (* n (lrand

;; Then use lrand-int and lrand instead of rand-int and rand throughout my 
code, and,
;; for things that I'm going to want to distribute, re-bind the rng as in this 
example:

(defn evaluate-individual
  "Returns the given individual with errors and total-errors, computing them if 
necessary."
  [i error-function rand-gen]
  (binding [thread-local-random-generator rand-gen]
))

;; Now the code that dispatches the distributed stuff. I do this by creating a 
vector of agents 
;; that will do the computations and a vector of rngs that will be used in 
those computations,
;; like:

  (let [pop-agents (vec (doall (for [_ (range population-size)] 
 (agent (make-individual 
  :program (random-code max-points 
atom-generators))
   :error-handler (fn [agnt except] (println 
except))
rand-gens (vec (doall (for [_ (range population-size)]
(java.util.Random.]

;; and then to do the actual computations I have something like the following 
within
;; the let that I started above:

  (dorun (map #(send % evaluate-individual error-function %2) pop-agents 
rand-gens))
  (apply await pop-agents) ;; SYNCHRONIZE

Again, I make no claims for this, and I'd love to hear if someone sees 
something wrong or a simpler way to accomplish this.

The larger context of the above snippets is: https://github.com/lspector/Clojush

 -Lee 

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

Re: User.clj and set!

[Andreas Liljeqvist]

This should really be in some earthshaking announcement somewhere...
https://github.com/technomancy/leiningen/commit/2ff64b77367601a216afa9e6964d1d330e3dbdb1

Load ~/.lein/user.clj inside project if present. Fixes #215
.


Now I can finally do (set! *print-length* 100) in user.clj.


Great stuff!


How would I require clojure.java.javadoc as something shorter

and have it visible in all namespaces?


2011/6/22 Paul Stadig 

> On Jun 19, 5:11 pm, Andreas Liljeqvist  wrote:
> > Thanks for the answer.
> > Would there be any problems associated with changing the root bindings?
> >
>
> It means that every thread in the whole JVM would get that value, but
> that's probably what you want. It also means that if someone else
> changed the root value to a different value, all the threads would get
> that new value, instead of the one you want.
>
> In the case of this particular var none of this may be an issue.
>
>
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Needing type hinting help for number crunching

[Chas Emerick]

A couple of thoughts:

You should be using 1.3.0-beta1 of Clojure 1.3 -- anything with 
-master-SNAPSHOT is woefully out of date at this point.

No, reduce always returns an Object, and will always box the result of the 
function you're using in the reduce.  Clojure's type inference does not work 
across HOF application, so compute-step can declare or hint whatever return 
type you like, but reduce's result will only every be known as an Object (same 
goes for other results from HOF usage).

Your DoubleMersenneTwister ctor is flagged with a reflection warning because 
swap! returns an Object as well (I assume it's looking for an int or long?).  
Same principles apply.

However, I wouldn't expect (much of) a speedup from those minor tweaks.  First, 
if that reduce with the `compute-step` fn is your hot loop, reduce will box you 
into oblivion.  At least until primitives work across applications of HOFs, 
you'll need to unroll that by hand.  Second, you're destructuring with 
`[next-put-value next-call-value]`.  Destructuring is convenient and usually 
not a bottleneck, but it often is if you're attempting to avoid boxing 
overhead: what you have now is boxing the two values you're binding, and then 
creating a vector to hold them, and then pulling that vector apart to get to 
the original values.  You can just move your conditional out of the let's 
binding vector, and use it to choose between two recur paths:

(if (pos? delta-price)
  (recur (+ put-value delta-price) call-value)
  (recur put-value (- call-value delta-price)))

Assuming all of the values involved are primitives, the above will ensure that 
they remain so.

- Chas

On Jul 23, 2011, at 7:41 AM, bernardH wrote:

> Hi,
> 
> I have rewritten some number crunching code from C++ to Clojure.
> I was pleasantly surprised to find that the Clojure code is within 10x
> of the C++ excecution time (both multicore implementations), but
> always eager for more speed, I (reluctantly) moved away from incanter
> (only used a couple of thin wrappers over Colt) to Clojure 1.3
> (Clojure 1.3.0-master-SNAPSHOT) for type hinting.
> 
> However, no matter how hard I try, I fail to resolve some
> "recur arg for primitive local: put_value is not matching primitive,
> had: Object, needed: double"
> leading to "Auto-boxing loop arg: put-value" in the most performance
> sensitive code :(
> 
> ( complete code on github [*]) the relevant parts are :
> 
> (let [double-normal-rng (Normal. 0. volatility
> 
> (DoubleMersenneTwister. (swap! seed inc)))]
> (loop [put-value  0.
>  call-value  0.]
> (if (neg? (swap! n-iters-todo dec))
> [put-value call-value]
> (let [delta-price (- strike-price
>(reduce compute-
> step stock-price
>  (repeatedly n-
> steps
> 
> #(.nextDouble double-normal-rng
> 
> 0. volatility
>   [next-put-value next-call-value] (if
> (pos? delta-price)
>  [(+
> put-value delta-price) call-value]
>  [put-
> value (- call-value delta-price)])]
>   (recur  next-put-value next-call-
> value)
> 
> And with
> (set! *warn-on-reflection* true)
> (set! *unchecked-math* true)
> I get
> Reflection warning, NO_SOURCE_PATH:2535 - call to
> cern.jet.random.tdouble.engine.DoubleMersenneTwister ctor can't be
> resolved.
> NO_SOURCE_FILE:2548 recur arg for primitive local: put_value is not
> matching primitive, had: Object, needed: double
> NO_SOURCE_FILE:2548 recur arg for primitive local: call_value is not
> matching primitive, had: Object, needed: double
> Auto-boxing loop arg: put-value
> Auto-boxing loop arg: call-value
> 
> When I eval the whole function def. :(
> I should note that have type hinted the inner most function,
> previously defined in a letfn
> (compute-step
> ^:static ^double [^double price ^double rnd-number]
> (* price (+ 1.
> (* rnd-number (Math/sqrt (/ years-to-maturity
> n-steps)))
> (* risk-free-rate (/ years-to-maturity n-
> steps)
> 
> What is wrong with the DoubleMersenneTwister ctor ?
> Shouldn' t the reduce call preserve the type information from
> compute ? strike-price is type-hinted to double so shouldn't the
> *unchecked-math* preserve this type info all the way to next-put-value
> and next-call-value ?
> 
> Any help (even only a hint ;) on where to look for) *greatly*
> appreciated !
> 
> Best Regards,
> 
> Bernard
> 
> [*] 
> https://github.com/scientific-coder/Black-Scholes/blob/master/src/black-scholes/src/montecarlo.clj#L57
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.co

{ANN} clojure-control---DSL for system admin and deployment with many remote machines

[dennis]

1.What is clojure-control?

The idea came from node-control(https://github.com/tsmith/node-
control).
Define clusters and tasks for system administration or code
deployment, then execute them on one or many remote machines.
Clojure-control depends only on OpenSSH and clojure on the local
control machine.Remote machines simply need a standard sshd daemon.

2.Quick example

Get the current date from the two machines listed in the 'mycluster'
config with a single command:

 (ns samples
 (:use [control.core :only [task cluster scp ssh begin]]))
 ;;define clusters
 (cluster :mycluster
 :clients [
   { :host "a.domain.com" :user "alogin"}
   { :host "b.domain.com" :user "blogin"}
 ])
 ;;define tasks
 (task :date "Get date"
  (ssh "date"))
;;start running
(begin)

If saved in a file named "controls.clj",run with

java -cp clojure.jar:clojure-contrib.jar:control-0.1-SNAPSHOT.jar
clojure.main controls.clj mycluster date

Each machine execute "date" command ,and the output form the remote
machine is printed to the console.Exmaple console output

Performing mycluster
Performing date for a.domain.com
a.domain.com:ssh: date
a.domain.com:stdout: Sun Jul 24 19:14:09 CST 2011
a.domain.com:exit: 0
Performing date for b.domain.com
b.domain.com:ssh: date
b.domain.com:stdout: Sun Jul 24 19:14:09 CST 2011
b.domain.com:exit: 0

Each line of output is labeled with the address of the machine the
command was executed on. The actual command sent and the user used to
send it is displayed. stdout and stderr output of the remote process
is identified as well as the final exit code of the local ssh
command.

3.How to scp files?
Let's define a new task named deploy

  (task :deploy "scp files to remote machines"
(scp ("release1.tar.gz" "release2.tar.gz") "/home/alogin/"))

Then it will copy release1.tar.gz and release2.tar.gz to remote
machine's /home/alogin directory.

4.More information please goto project homepage

https://github.com/killme2008/clojure-control

Any suggestion or bug reports welcomed.

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

Alright, fess up, who's unhappy with clojurescript?

[James Keats]

Alright, to be honest, I'm disappointed.

First of all, congrats and good job to all involved in putting it out.
On the plus side, it's a good way to use the Google Closure javascript
platform.

On the minus, imho, that's what's wrong with it.

Google Closure is too Java. It's not idiomatic JavaScript. I find it
disappointing that rather than porting from a functional language like
Clojure straight to another functional language like Javascript, the
google closure with its ugly Java-isms is right there obnoxiously in
the middle.

Then, there's the elephant in the room, and that elephant is Jquery. I
believe any targetting-javascript tool that misses out on jquery-first-
and-foremost is missing out on the realities of javascript in 2011.
Jquery is huge in its community and plugins, and it has tons of books
and tutorials. In much the same way that you can have lots of libs on
the JVM, there are lots of plugins for jquery. So much so that the
latest edition of Javascript: the Definitive Guide includes a chapter
on it; quoted:

"Because the jQuery library has become so widely used, web developers
should be fa-
miliar with it: even if you don’t use it in your own code, you are
likely to encounter it
in code written by others."

Then, the Google Closure compiler is a moot point. Everyone by now
already has a copy of jquery from the Google CDN and linking to it in
your code will not download it any further after your first visit to a
website that does so. In any case, it's already small and fast.

Then there's rhino/jvm. I would much rather an in-browser focus.

I'm tempted to "fork" clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.

Discuss?


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

Re: Alright, fess up, who's unhappy with clojurescript?

[Stuart Halloway]

Hi James,

The Clojure/dev folks who built ClojureScript disagree with all of the key 
points of your analysis:

> Google Closure is too Java. It's not idiomatic JavaScript.

If you target idiomatic JavaScript you will find yourself living in the world 
of JavaScript semantics. It is evident that many people want that.  We don't.

> Then, there's the elephant in the room, and that elephant is Jquery.

JQuery is a powerful library. So is Google Closure. I don't share your 
certainty that JQuery is the elephant. (I don't use any JQuery apps that have 
the sophistication of GMail.)

But in any case, we are targeting a future community, not any 
currently-existing one. 

> Then, the Google Closure compiler is a moot point. Everyone by now
> already has a copy of jquery from the Google CDN and linking to it in
> your code will not download it any further after your first visit to a
> website that does so. In any case, it's already small and fast.

This is a good argument for modest applications, and a poor argument for 
substantial ones. We are interested in the latter.

> Then there's rhino/jvm. I would much rather an in-browser focus.

Rhino is an implementation detail of the development platform. That 
implementation detail could and probably should change.

> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.

If that is your objective, the ClojureScript codebase won't be a useful 
starting point. You would be better off to start from scratch.

Cheers,
Stu

Stuart Halloway
Clojure/core
http://clojure.com

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Aaron Bedra]

First:

* I respect your opinions. I am glad that you have taken the time to 
start exploring ClojureScript


Second:

* Dude, stop trolling. This is the second time you have started a thread 
with a baiting subject line and no clear end goal. Your opinions are 
yours, and I have no problems with that, however, this offers no 
constructive feedback. If you would like to write your own Clojure on 
JavaScript, that would be a great way to learn and get exactly what you 
want out of it.  I encourage you to look at the ClojureScript source 
code for ideas while you are doing your implementation.


* If you want to start discussions like this, please do so elsewhere.  
If you have something in particular you want to discuss about Clojure or 
ClojureScript, then this is the place.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/24/2011 08:19 AM, James Keats wrote:

Alright, to be honest, I'm disappointed.

First of all, congrats and good job to all involved in putting it out.
On the plus side, it's a good way to use the Google Closure javascript
platform.

On the minus, imho, that's what's wrong with it.

Google Closure is too Java. It's not idiomatic JavaScript. I find it
disappointing that rather than porting from a functional language like
Clojure straight to another functional language like Javascript, the
google closure with its ugly Java-isms is right there obnoxiously in
the middle.

Then, there's the elephant in the room, and that elephant is Jquery. I
believe any targetting-javascript tool that misses out on jquery-first-
and-foremost is missing out on the realities of javascript in 2011.
Jquery is huge in its community and plugins, and it has tons of books
and tutorials. In much the same way that you can have lots of libs on
the JVM, there are lots of plugins for jquery. So much so that the
latest edition of Javascript: the Definitive Guide includes a chapter
on it; quoted:

"Because the jQuery library has become so widely used, web developers
should be fa-
miliar with it: even if you don’t use it in your own code, you are
likely to encounter it
in code written by others."

Then, the Google Closure compiler is a moot point. Everyone by now
already has a copy of jquery from the Google CDN and linking to it in
your code will not download it any further after your first visit to a
website that does so. In any case, it's already small and fast.

Then there's rhino/jvm. I would much rather an in-browser focus.

I'm tempted to "fork" clojurescript and redo it in javascript perhaps
so that seamless interop with jquery would be the main priority.

Discuss?





--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Rathwell]

Wasn't it just a couple weeks ago that you were arguing that everything
should be more like Java?  Now you're arguing that Google Closure is bad
because it has some similarities to Java development (mainly verbosity and
documentation).  I'm honestly not sure if you are just trying to be
controversial, or to appear smart, but I'll bite (time for a break anyways).

Closure is not idomatic javascript:
---

Do you have an actual argument from experience here, or are you
regurgitating what you've read in articles like [1].  Is CoffeeScript
idiomatic javascript?  How about Dojo?  SproutCore?  jQuery?  What exactly
is idiomatic javascript?

vs. jQuery:
---

jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
apps, I don't think anyone argues that.  And it is extrememly simple, not
even requiring the user to know any javascript to use it.  This is why it is
so (deservedly) popular.

Large scale, single page applications are a different thing than page based
sites, however.  Writing these types of apps with only jQuery quickly turns
to spaghetti.  There are some nice libraries/frameworks out there, like
Backbone and Underscore, that do a very nice job of making it cleaner and
scalable.  These are all still fairly young though, to be fair.

In the realm of proven environments for large scale, client side javascript
development, you have Dojo and Google Closure, and to some degree SproutCore
and Cappuccino.  If you can point me to larger scale apps than GMail, Google
Docs, etc., written using jQuery, I will gladly have a look.

Once you get to that scale, you really needing a way to organize code, to
package and load modules, etc.  Dojo and Closure offer a pretty nice, and
proven, system for this.

So, yes, I would have preferred Dojo, because I am more familiar.  But to be
fair, Closure is very similar, is a very complete library, and has very good
documentation and examples for the most part.

[1] http://www.sitepoint.com/google-closure-how-not-to-write-javascript/

 - Mark


On Sun, Jul 24, 2011 at 11:19 AM, James Keats wrote:

>
> Alright, to be honest, I'm disappointed.
>
> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>
> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.
> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials. In much the same way that you can have lots of libs on
> the JVM, there are lots of plugins for jquery. So much so that the
> latest edition of Javascript: the Definitive Guide includes a chapter
> on it; quoted:
>
> "Because the jQuery library has become so widely used, web developers
> should be fa-
> miliar with it: even if you don’t use it in your own code, you are
> likely to encounter it
> in code written by others."
>
> Then, the Google Closure compiler is a moot point. Everyone by now
> already has a copy of jquery from the Google CDN and linking to it in
> your code will not download it any further after your first visit to a
> website that does so. In any case, it's already small and fast.
>
> Then there's rhino/jvm. I would much rather an in-browser focus.
>
> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>
> Discuss?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Baishampayan Ghose]

Sorry for the digression, but what about YUI 3?

Regards,
BG

---
Sent from phone. Please excuse brevity.
On Jul 24, 2011 9:32 PM, "Mark Rathwell"  wrote:
> Wasn't it just a couple weeks ago that you were arguing that everything
> should be more like Java? Now you're arguing that Google Closure is bad
> because it has some similarities to Java development (mainly verbosity and
> documentation). I'm honestly not sure if you are just trying to be
> controversial, or to appear smart, but I'll bite (time for a break
anyways).
>
> Closure is not idomatic javascript:
> ---
>
> Do you have an actual argument from experience here, or are you
> regurgitating what you've read in articles like [1]. Is CoffeeScript
> idiomatic javascript? How about Dojo? SproutCore? jQuery? What exactly
> is idiomatic javascript?
>
> vs. jQuery:
> ---
>
> jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
> apps, I don't think anyone argues that. And it is extrememly simple, not
> even requiring the user to know any javascript to use it. This is why it
is
> so (deservedly) popular.
>
> Large scale, single page applications are a different thing than page
based
> sites, however. Writing these types of apps with only jQuery quickly turns
> to spaghetti. There are some nice libraries/frameworks out there, like
> Backbone and Underscore, that do a very nice job of making it cleaner and
> scalable. These are all still fairly young though, to be fair.
>
> In the realm of proven environments for large scale, client side
javascript
> development, you have Dojo and Google Closure, and to some degree
SproutCore
> and Cappuccino. If you can point me to larger scale apps than GMail,
Google
> Docs, etc., written using jQuery, I will gladly have a look.
>
> Once you get to that scale, you really needing a way to organize code, to
> package and load modules, etc. Dojo and Closure offer a pretty nice, and
> proven, system for this.
>
> So, yes, I would have preferred Dojo, because I am more familiar. But to
be
> fair, Closure is very similar, is a very complete library, and has very
good
> documentation and examples for the most part.
>
> [1] http://www.sitepoint.com/google-closure-how-not-to-write-javascript/
>
> - Mark
>
>
> On Sun, Jul 24, 2011 at 11:19 AM, James Keats wrote:
>
>>
>> Alright, to be honest, I'm disappointed.
>>
>> First of all, congrats and good job to all involved in putting it out.
>> On the plus side, it's a good way to use the Google Closure javascript
>> platform.
>>
>> On the minus, imho, that's what's wrong with it.
>>
>> Google Closure is too Java. It's not idiomatic JavaScript. I find it
>> disappointing that rather than porting from a functional language like
>> Clojure straight to another functional language like Javascript, the
>> google closure with its ugly Java-isms is right there obnoxiously in
>> the middle.
>>
>> Then, there's the elephant in the room, and that elephant is Jquery. I
>> believe any targetting-javascript tool that misses out on jquery-first-
>> and-foremost is missing out on the realities of javascript in 2011.
>> Jquery is huge in its community and plugins, and it has tons of books
>> and tutorials. In much the same way that you can have lots of libs on
>> the JVM, there are lots of plugins for jquery. So much so that the
>> latest edition of Javascript: the Definitive Guide includes a chapter
>> on it; quoted:
>>
>> "Because the jQuery library has become so widely used, web developers
>> should be fa-
>> miliar with it: even if you don’t use it in your own code, you are
>> likely to encounter it
>> in code written by others."
>>
>> Then, the Google Closure compiler is a moot point. Everyone by now
>> already has a copy of jquery from the Google CDN and linking to it in
>> your code will not download it any further after your first visit to a
>> website that does so. In any case, it's already small and fast.
>>
>> Then there's rhino/jvm. I would much rather an in-browser focus.
>>
>> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
>> so that seamless interop with jquery would be the main priority.
>>
>> Discuss?
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Rathwell]

Yes, true, I always forget about YUI, and it never gets its fair
recognition.

 - Mark

On Sun, Jul 24, 2011 at 12:08 PM, Baishampayan Ghose wrote:

> Sorry for the digression, but what about YUI 3?
>
> Regards,
> BG
>
> ---
> Sent from phone. Please excuse brevity.
> On Jul 24, 2011 9:32 PM, "Mark Rathwell"  wrote:
> > Wasn't it just a couple weeks ago that you were arguing that everything
> > should be more like Java? Now you're arguing that Google Closure is bad
> > because it has some similarities to Java development (mainly verbosity
> and
> > documentation). I'm honestly not sure if you are just trying to be
> > controversial, or to appear smart, but I'll bite (time for a break
> anyways).
> >
> > Closure is not idomatic javascript:
> > ---
> >
> > Do you have an actual argument from experience here, or are you
> > regurgitating what you've read in articles like [1]. Is CoffeeScript
> > idiomatic javascript? How about Dojo? SproutCore? jQuery? What exactly
> > is idiomatic javascript?
> >
> > vs. jQuery:
> > ---
> >
> > jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
> > apps, I don't think anyone argues that. And it is extrememly simple, not
> > even requiring the user to know any javascript to use it. This is why it
> is
> > so (deservedly) popular.
> >
> > Large scale, single page applications are a different thing than page
> based
> > sites, however. Writing these types of apps with only jQuery quickly
> turns
> > to spaghetti. There are some nice libraries/frameworks out there, like
> > Backbone and Underscore, that do a very nice job of making it cleaner and
> > scalable. These are all still fairly young though, to be fair.
> >
> > In the realm of proven environments for large scale, client side
> javascript
> > development, you have Dojo and Google Closure, and to some degree
> SproutCore
> > and Cappuccino. If you can point me to larger scale apps than GMail,
> Google
> > Docs, etc., written using jQuery, I will gladly have a look.
> >
> > Once you get to that scale, you really needing a way to organize code, to
> > package and load modules, etc. Dojo and Closure offer a pretty nice, and
> > proven, system for this.
> >
> > So, yes, I would have preferred Dojo, because I am more familiar. But to
> be
> > fair, Closure is very similar, is a very complete library, and has very
> good
> > documentation and examples for the most part.
> >
> > [1] http://www.sitepoint.com/google-closure-how-not-to-write-javascript/
> >
> > - Mark
> >
> >
> > On Sun, Jul 24, 2011 at 11:19 AM, James Keats  >wrote:
> >
> >>
> >> Alright, to be honest, I'm disappointed.
> >>
> >> First of all, congrats and good job to all involved in putting it out.
> >> On the plus side, it's a good way to use the Google Closure javascript
> >> platform.
> >>
> >> On the minus, imho, that's what's wrong with it.
> >>
> >> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> >> disappointing that rather than porting from a functional language like
> >> Clojure straight to another functional language like Javascript, the
> >> google closure with its ugly Java-isms is right there obnoxiously in
> >> the middle.
> >>
> >> Then, there's the elephant in the room, and that elephant is Jquery. I
> >> believe any targetting-javascript tool that misses out on jquery-first-
> >> and-foremost is missing out on the realities of javascript in 2011.
> >> Jquery is huge in its community and plugins, and it has tons of books
> >> and tutorials. In much the same way that you can have lots of libs on
> >> the JVM, there are lots of plugins for jquery. So much so that the
> >> latest edition of Javascript: the Definitive Guide includes a chapter
> >> on it; quoted:
> >>
> >> "Because the jQuery library has become so widely used, web developers
> >> should be fa-
> >> miliar with it: even if you don’t use it in your own code, you are
> >> likely to encounter it
> >> in code written by others."
> >>
> >> Then, the Google Closure compiler is a moot point. Everyone by now
> >> already has a copy of jquery from the Google CDN and linking to it in
> >> your code will not download it any further after your first visit to a
> >> website that does so. In any case, it's already small and fast.
> >>
> >> Then there's rhino/jvm. I would much rather an in-browser focus.
> >>
> >> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> >> so that seamless interop with jquery would be the main priority.
> >>
> >> Discuss?
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> > --
> > You recei

Re: Anyone on Google+ yet?

[MHOOO]

I've never been fond of facebook, mainly because there is this
tendency to have a lot of people in your friends list whom you barely
know. G+ seems to do better with circles being private. Anyone mind
giving me an invite? Its thomas.karol...@googlemail.com

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

Re: Alright, fess up, who's unhappy with clojurescript?

[David Nolen]

As a professional JavaScripter for the past 6 years who has built his own
frameworks and written considerable amounts of Prototype, MooTools, and
jQuery.

I don't think jQuery is special or particularly interesting and most of the
libraries around it are terrible IMO. It certainly doesn't help in building
sophisticated clientside applications (if it did, why Backbone.js, why
Cappuccino, why SproutCore?, etc).

For simple stuff it's fine. But then so is Google Closure.

I think the Clojure community can do much, much better. In fact a clientside
framework could be the first Clojure killer app ...

David

On Sun, Jul 24, 2011 at 11:19 AM, James Keats wrote:

>
> Alright, to be honest, I'm disappointed.
>
> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java. It's not idiomatic JavaScript. I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>
> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.
> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials. In much the same way that you can have lots of libs on
> the JVM, there are lots of plugins for jquery. So much so that the
> latest edition of Javascript: the Definitive Guide includes a chapter
> on it; quoted:
>
> "Because the jQuery library has become so widely used, web developers
> should be fa-
> miliar with it: even if you don’t use it in your own code, you are
> likely to encounter it
> in code written by others."
>
> Then, the Google Closure compiler is a moot point. Everyone by now
> already has a copy of jquery from the Google CDN and linking to it in
> your code will not download it any further after your first visit to a
> website that does so. In any case, it's already small and fast.
>
> Then there's rhino/jvm. I would much rather an in-browser focus.
>
> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>
> Discuss?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Frank Gerhardt]

On Sun, Jul 24, 2011 at 7:03 PM, David Nolen  wrote:
>
> I think the Clojure community can do much, much better. In fact a
> clientside framework could be the first Clojure killer app ...
>

Yes, absolutely.

Integration with other libraries is essential, and possible as I understand
it. For client side UIs I need a choice of JQuery, YUI, ExtJs, Closure and
others. Most of the time there are customer-related constraints for or
against a certain UI library. As clojurescript is only alpha we can't expect
that story to be completely done. It would be nice to get an idea in what
direction you are thinking for a client-side framework, especially idiomatic
UIs.

Frank.

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> Wasn't it just a couple weeks ago that you were arguing that everything
> should be more like Java?  Now you're arguing that Google Closure is bad
> because it has some similarities to Java development (mainly verbosity and
> documentation).  I'm honestly not sure if you are just trying to be
> controversial, or to appear smart, but I'll bite (time for a break anyways).
>
> Closure is not idomatic javascript:
> ---
>
> Do you have an actual argument from experience here, or are you
> regurgitating what you've read in articles like [1].  Is CoffeeScript
> idiomatic javascript?  How about Dojo?  SproutCore?  jQuery?  What exactly
> is idiomatic javascript?
>
> vs. jQuery:
> ---
>
> jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
> apps, I don't think anyone argues that.  And it is extrememly simple, not
> even requiring the user to know any javascript to use it.  This is why it is
> so (deservedly) popular.
>
> Large scale, single page applications are a different thing than page based
> sites, however.  Writing these types of apps with only jQuery quickly turns
> to spaghetti.  There are some nice libraries/frameworks out there, like
> Backbone and Underscore, that do a very nice job of making it cleaner and
> scalable.  These are all still fairly young though, to be fair.
>
> In the realm of proven environments for large scale, client side javascript
> development, you have Dojo and Google Closure, and to some degree SproutCore
> and Cappuccino.  If you can point me to larger scale apps than GMail, Google
> Docs, etc., written using jQuery, I will gladly have a look.
>
> Once you get to that scale, you really needing a way to organize code, to
> package and load modules, etc.  Dojo and Closure offer a pretty nice, and
> proven, system for this.
>
> So, yes, I would have preferred Dojo, because I am more familiar.  But to be
> fair, Closure is very similar, is a very complete library, and has very good
> documentation and examples for the most part.
>

On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> Wasn't it just a couple weeks ago that you were arguing that everything
> should be more like Java?  Now you're arguing that Google Closure is bad
> because it has some similarities to Java development (mainly verbosity and
> documentation).  I'm honestly not sure if you are just trying to be
> controversial, or to appear smart, but I'll bite (time for a break anyways).
>
> Closure is not idomatic javascript:
> ---

I'm not "arguing that everything should be more like Java", but
rather, if you're targetting the JVM then Java, if you're targetting
javascript then javascript.

I'm aware of the article you pointed out, but no, that article is
mostly about the implementation details within closure, which is a
lesser concern to me. I think a good book about idiomatic javascript
would probably be Douglass Crockford's Javascript: the Good Parts, and
just as good if not even better is JavaScript Patterns by Stoyan
Stefanov; emphasis on a functional programming small subset of
javascript, using closures and prototypes, et cetera. I had been aware
of the Google Closure library through its book, which I read when it
first came out; I invite you to read this book. It's too Java-esque;
java-inspired annotations, java-inspired OOP, too much complexity and
ceremony, and the author pointedly dismisses much of the javascript
community idioms: http://bolinfest.com/javascript/inheritance.php

I think it's a bit absurd, folks, to criticize Java's OOP as
incidental complexity, too much ceremony, and even suggest in the Joy
of Clojure that a Steve Yegge's Universal Design Pattern and prototype
pattern a la Javascript could be married to clojure's in the chapter
that discuss namespaces, multimethods, protocols and datatypes, and
then turn around and implicitly declare to the world with the release
of clojurescript "oh noes! if we're gonna do anything substantial then
this doesn't scale! we need a Java like solution!"


> [1]http://www.sitepoint.com/google-closure-how-not-to-write-javascript/
>
>  - Mark
>
> On Sun, Jul 24, 2011 at 11:19 AM, James Keats wrote:
>
>

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Wilson MacGyver]

Given that google closure library has a fairly decent size UI elements, and the 
pitch about how clojurescript makes google closure usable for mortals. I think 
that's probably where it will start.

On Jul 24, 2011, at 1:15 PM, Frank Gerhardt  
wrote:
...
> expect that story to be completely done. It would be nice to get an idea in 
> what direction you are thinking for a client-side framework, especially 
> idiomatic UIs.

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

Re: ClojureScript

[Peter Taoussanis]

Just want to throw in on this real quick. I am -dumbfounded- by how
cool ClojureScript is.

It was about 2AM my time when I first heard the announcement and I
stayed up another 3 hours after that watching Rich's talk and playing
with the samples. As I see it right now, this is a Big Deal. For lots
of reasons. And I suspect it might take some time for the whole
concept and its wide ramifications to fully digest for everyone.

Like many (I'm guessing), my first question was: will it work with
jQuery? I'd never even heard of Google Closure. Suffice it to say it
didn't take much time looking into it to get me excited. And for it to
click just how smart this whole approach seems it might just be.


I am, literally, deploying this to my web app right now. I've got a
Compojure route setup for a the resulting output of memoized
ClojureScript compile call. I can work on the ClojureScript directly
from my project. When something changes, I re-evaluate the memoized fn
on my dev box (or on the production server through an SSH tunnel) and
boom: I have a fully-optimized script going out to users. Add in a
content-hash of the compiled script to automatically expire the old
resource, and I have a workflow that I couldn't imagine being much
better.

Client-side side stuff I've wanted to do with my app but couldn't even
begin to have the patience to implement- now suddenly seem trivial in
principle. Having access to the reader for transmitting native data
structures between the server and client... I don't even have the
words.


And this is just the stuff that touches me directly and that's
obvious. I can't wait to see what people are going to do with this in
time.


Thank you: awesome job, guys. And what an awesome surprise!

--
Peter

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 6:03 pm, David Nolen  wrote:
> As a professional JavaScripter for the past 6 years who has built his own
> frameworks and written considerable amounts of Prototype, MooTools, and
> jQuery.
>
> I don't think jQuery is special or particularly interesting and most of the
> libraries around it are terrible IMO. It certainly doesn't help in building
> sophisticated clientside applications (if it did, why Backbone.js, why
> Cappuccino, why SproutCore?, etc).
>
> For simple stuff it's fine. But then so is Google Closure.
>
> I think the Clojure community can do much, much better. In fact a clientside
> framework could be the first Clojure killer app ...
>
> David
>

I was hoping that clojure itself would help jquery build sophisticated
applications, by bringing proper functional programming to the
clientside, rather than bringing Java's OOP in the form of gClosure.

The Javascript notaries have advocated using a small functional subset
of javascript, rather than the full gamut of javscript's quirks, and I
was saddened while watching the Rich Hickey talk when he said that
clojurescript would abstract away the complex conventions and
discipline required when writing apps for gClosure by producing code
ready for its optimizing compiler, when it could've simply enforced
that small functional subset of javascript itself (sans gClosure)
that's now considered idiomatic best practice.

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

Forcing evaluation of returned anonymous javascript function in ClojureScript

[Alen Ribic]

Firstly, thank you Clojure/core team and other contributors for this
exciting project.

I have a small problem I've encountered while building a simple
personal blog, as an exercise, with Clojure/ClojureScript and would
appreciate any feedback.

I have a client-side function that sends a request to a specific URI
on the server-side that respondes with an HTML fragment/snippet.
The request event is received by the front-end callback function and
it simply "replaces" a specific HTML node with the HTML fragment
received from the server side.

The Cljs code:
https://gist.github.com/1102641

Upon the request from the client-side code, I can confirm that the
server successfully responds with the HTML fragment as shown in the
example below:


  
Content sub-heading
Content...
[Meta-data]
  
  
Content sub-heading 2
Content 2...
[Meta-data]
  


Line 15 in the cljs script is meant to replace the HTML node with the
HTML fragment received from the server above.
Instead, the result is an unevaluated anonymous function below:

function (){try{return this.a?this.a.responseText:""}catch(a){return
E(this.e,"Can not get responseText: "+a.message),""}}

If I replace the (-> % .target .getResponseText) on line 16, with a
simple hardcoding, "Test", everything works as
expected.

To conclude, I have tested the entire cljs script, and it works as
expected, with an exception to (-> % .target .getResponseText) on line
16.

Do I perhaps have to force the evaluation of the returned anonymous
function or is there some special ClojureScript macro/function that I
omitted from the process?

-Alen

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

Re: Alright, fess up, who's unhappy with clojurescript?

[David Nolen]

On Sun, Jul 24, 2011 at 1:46 PM, James Keats wrote:

> The Javascript notaries have advocated using a small functional subset
> of javascript, rather than the full gamut of javscript's quirks, and I
> was saddened while watching the Rich Hickey talk when he said that
> clojurescript would abstract away the complex conventions and
> discipline required when writing apps for gClosure by producing code
> ready for its optimizing compiler, when it could've simply enforced
> that small functional subset of javascript itself (sans gClosure)
> that's now considered idiomatic best practice.


Restricting yourself to a functional subset of JavaScript can't fix
JavaScript. The functional subset stinks, Javascript notaries be damned.

David

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 7:05 pm, David Nolen  wrote:
> On Sun, Jul 24, 2011 at 1:46 PM, James Keats wrote:
>
> > The Javascript notaries have advocated using a small functional subset
> > of javascript, rather than the full gamut of javscript's quirks, and I
> > was saddened while watching the Rich Hickey talk when he said that
> > clojurescript would abstract away the complex conventions and
> > discipline required when writing apps for gClosure by producing code
> > ready for its optimizing compiler, when it could've simply enforced
> > that small functional subset of javascript itself (sans gClosure)
> > that's now considered idiomatic best practice.
>
> Restricting yourself to a functional subset of JavaScript can't fix
> JavaScript. The functional subset stinks, Javascript notaries be damned.
>
> David

If so where does this leave clojure itself and its advocacy of
functional programming, then; see last paragraph of my reply to Mark.

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

clojurescript patches

[kjeldahl]

I've got a small patch that I would like to contribute (simple stuff,
figures out the correct classpath for repljs and cljsc), but I can't
find any "issues" link on github. Am I required to fork clojurescript
and request a pull to contribute patches, or does clojurescript use
another issue tracker where I can send it?

Thanks,

Marius K.

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Michael Gardner]

On Jul 24, 2011, at 1:11 PM, James Keats wrote:

>> Restricting yourself to a functional subset of JavaScript can't fix
>> JavaScript. The functional subset stinks, Javascript notaries be damned.
> 
> If so where does this leave clojure itself and its advocacy of
> functional programming, then; see last paragraph of my reply to Mark.

You can't draw any inference along those lines from David's observation. The 
functional parts of Javascript are far different from those of Clojure (and not 
in a good way).

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

Problem with ClojureScript + Node.js

[Benny Tsai]

I'm experimenting with ClojureScript on Windows.  After applying the patch 
kindly provided by pmbauer in this thread:

https://groups.google.com/d/topic/clojure/kObCK4Ik3tY/discussion

... I was able to get as far as compiling the nodehello.cljs example code 
from the Quick Start guide.  However, when I tried to run the resulting .js 
file using Node, I got the following error:

node.js:195
throw e; // process.nextTick error, or 'error' event on first tick
  ^
GetConsoleTitleW: The access code is invalid.
TypeError: Cannot read property 'prototype' of undefined
at Object. (C:\clojurescript\nodehello.js:14:382)
at Module._compile (module.js:420:26)
at Object..js (module.js:459:10)
at Module.load (module.js:335:31)
at Function._load (module.js:294:12)
at Array. (module.js:479:10)
at EventEmitter._tickCallback (node.js:187:26)

The same error was encountered with both the 0.5.2 and 0.5.1 Windows 
binaries from http://nodejs.org/dist/.  A similar error was thrown when I 
tried the 0.4.9 and 0.4.8 binaries from http://node-js.prcn.co.cc/:

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
WideCharToMultiByte: The data area passed to a system call is too small.
TypeError: Cannot read property 'prototype' of undefined
at Object. (/cygdrive/c/clojurescript/nodehello.js:14:382)
at Module._compile (module.js:402:26)
at Object..js (module.js:408:10)
at Module.load (module.js:334:31)
at Function._load (module.js:293:12)
at Array. (module.js:421:10)
at EventEmitter._tickCallback (node.js:126:26)

Has anyone had success using ClojureScript with Node.js, either on Windows 
or otherwise?

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

Re: clojurescript: How to transform a clojurescript map to a javascript object?

[Matthew Gilliard]

A function to turn clojure maps is shown here: https://gist.github.com/1098417
to go the reverse way, use (js->clj), there are examples here:
https://github.com/clojure/clojurescript/blob/master/samples/twitterbuzz/src/twitterbuzz/core.cljs

  mg

On Fri, Jul 22, 2011 at 8:50 PM, Robert Luo  wrote:
> To interact with various javascript libraries, they often requires you
> provide data in javascript object, while in clojurescript we normally
> use a map. How can we transform a map to javascript object and vice
> versa?
>
> BTW, now I use (js* "{width: 400, height: 300}") to do 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
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

clojurescript and external libs

[Jack Moffitt]

I'm exploring clojurescript and wondering how to use an external
library? In my particular case, I was trying to use Soy from Closure
Templates.

I realize that arbitrary third party libraries will need to fit into
the Closure Compiler ways, and part of my exploration is trying to
port some of my own to them, but my first roadblock was figuring out
how to get clojurescript to see them at all.

Is there a simple example of this anyone can share? Or a pointer to
the code would probably help as well.

jack.

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

ClojureScript source maps

[John]

Is there any interest in having ClojureScript generate source maps?

http://code.google.com/p/closure-compiler/wiki/SourceMaps

There are a couple of ways to accomplish this.

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

Re: clojurescript and external libs

[Wilson MacGyver]

You use js* like here

https://gist.github.com/1098417

See how jquery is being pulled in

On Jul 24, 2011, at 12:35 PM, Jack Moffitt  wrote:

> I'm exploring clojurescript and wondering how to use an external
> library? In my particular case, I was trying to use Soy from Closure
> Templates.
> 
> I realize that arbitrary third party libraries will need to fit into
> the Closure Compiler ways, and part of my exploration is trying to
> port some of my own to them, but my first roadblock was figuring out
> how to get clojurescript to see them at all.
> 
> Is there a simple example of this anyone can share? Or a pointer to
> the code would probably help as well.
> 
> jack.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: ClojureScript source maps

[David Nolen]

On Sun, Jul 24, 2011 at 1:19 PM, John  wrote:

> Is there any interest in having ClojureScript generate source maps?
>
> http://code.google.com/p/closure-compiler/wiki/SourceMaps
>
> There are a couple of ways to accomplish this.
>

I'm sure there is a considerable amount of interest in this.

David

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

Re: Anyone on Google+ yet?

[Dave Ray]

Invite sent in case someone else didn't send one already.

Cheers,

Dave

On Sun, Jul 24, 2011 at 12:26 PM, MHOOO  wrote:
> I've never been fond of facebook, mainly because there is this
> tendency to have a lot of people in your friends list whom you barely
> know. G+ seems to do better with circles being private. Anyone mind
> giving me an invite? Its thomas.karol...@googlemail.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 7:24 pm, Michael Gardner  wrote:
> On Jul 24, 2011, at 1:11 PM, James Keats wrote:
>
> >> Restricting yourself to a functional subset of JavaScript can't fix
> >> JavaScript. The functional subset stinks, Javascript notaries be damned.
>
> > If so where does this leave clojure itself and its advocacy of
> > functional programming, then; see last paragraph of my reply to Mark.
>
> You can't draw any inference along those lines from David's observation.

I'm not drawing an inference, but an argument.


> The functional parts of Javascript are far different from those of Clojure 
> (and not in a good way).

How so? javasript, while not as functional as clojure, is far more
functional than java ( first class functions, closures, anonymous
functions etc. A small subset of clojure would mirror and could expand
on a small subset of javascript); it's been called a "Lisp in C's
Clothing", and Brendan Eich famously and repeatedly said "As I’ve
often said, and as others at Netscape can confirm, I was recruited to
Netscape with the promise of “doing Scheme” in the browser" Back at
Netscape "doing a scheme in the browser" was botched a bit by a deal
with Sun and "the diktat from upper engineering management was that
the language must “look like Java”."[1], and whereas clojure/
clojurescript now had an opportunity to correct that, instead it's
piling on the Java-ism with gClosure.

[1] http://brendaneich.com/tag/history/

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

Re: Forcing evaluation of returned anonymous javascript function in ClojureScript

[Dave Ray]

See the "Host Interop" section here [1]. With ClojureScript there's a
distinction between method lookup and method invocation. I think what
you want is:

(-> % .target (.getResponseText))

Dave

[1] https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure

On Sun, Jul 24, 2011 at 1:51 PM, Alen Ribic  wrote:
> Firstly, thank you Clojure/core team and other contributors for this
> exciting project.
>
> I have a small problem I've encountered while building a simple
> personal blog, as an exercise, with Clojure/ClojureScript and would
> appreciate any feedback.
>
> I have a client-side function that sends a request to a specific URI
> on the server-side that respondes with an HTML fragment/snippet.
> The request event is received by the front-end callback function and
> it simply "replaces" a specific HTML node with the HTML fragment
> received from the server side.
>
> The Cljs code:
> https://gist.github.com/1102641
>
> Upon the request from the client-side code, I can confirm that the
> server successfully responds with the HTML fragment as shown in the
> example below:
>
> 
>      
>        Content sub-heading
>        Content...
>        [Meta-data]
>      
>      
>        Content sub-heading 2
>        Content 2...
>        [Meta-data]
>      
> 
>
> Line 15 in the cljs script is meant to replace the HTML node with the
> HTML fragment received from the server above.
> Instead, the result is an unevaluated anonymous function below:
>
> function (){try{return this.a?this.a.responseText:""}catch(a){return
> E(this.e,"Can not get responseText: "+a.message),""}}
>
> If I replace the (-> % .target .getResponseText) on line 16, with a
> simple hardcoding, "Test", everything works as
> expected.
>
> To conclude, I have tested the entire cljs script, and it works as
> expected, with an exception to (-> % .target .getResponseText) on line
> 16.
>
> Do I perhaps have to force the evaluation of the returned anonymous
> function or is there some special ClojureScript macro/function that I
> omitted from the process?
>
> -Alen
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Anyone on Google+ yet?

[MHOOO]

Thanks Joop Kiefte & Dave Ray!

On Jul 24, 9:00 pm, Dave Ray  wrote:
> Invite sent in case someone else didn't send one already.
>
> Cheers,
>
> Dave
>
>
>
>
>
>
>
> On Sun, Jul 24, 2011 at 12:26 PM, MHOOO  
> wrote:
> > I've never been fond of facebook, mainly because there is this
> > tendency to have a lot of people in your friends list whom you barely
> > know. G+ seems to do better with circles being private. Anyone mind
> > giving me an invite? Its thomas.karol...@googlemail.com
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: clojurescript patches

[Sean Corfield]

On Sun, Jul 24, 2011 at 11:15 AM, kjeldahl
 wrote:
> I've got a small patch that I would like to contribute (simple stuff,
> figures out the correct classpath for repljs and cljsc), but I can't
> find any "issues" link on github. Am I required to fork clojurescript
> and request a pull to contribute patches, or does clojurescript use
> another issue tracker where I can send it?

ClojureScript follows the same process as Clojure itself:

http://clojure.org/contributing

Get a signed CA on file, get an account on JIRA, open a ticket and
attach a patch file. Whilst some people complain about this process,
it protects the Clojure project from certain important legal issues
going forward and allows corporations to adopt Clojure without fear of
copyright problems.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: clojurescript and external libs

[Jack Moffitt]

> You use js* like here
>
> https://gist.github.com/1098417
>
> See how jquery is being pulled in

Unfortunately this means that my external JS lib won't get any
benefits from the closure compiler. Is there some way to tell the
compiler where more external libs are and then use them via :require
just like closure library (let's assume for the moment they are
goog.provides and goog.require compatible,etc)?

jack.

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

Re: clojurescript: How to transform a clojurescript map to a javascript object?

[Sean Corfield]

On Sun, Jul 24, 2011 at 5:33 AM, Matthew Gilliard
 wrote:
> A function to turn clojure maps is shown here: https://gist.github.com/1098417

There's also this (shorter) way using Google Closure's API:
https://gist.github.com/1098521
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Michael Gardner]

On Jul 24, 2011, at 2:08 PM, James Keats wrote:

> On Jul 24, 7:24 pm, Michael Gardner  wrote:
>> The functional parts of Javascript are far different from those of Clojure 
>> (and not in a good way).
> 
> How so? javasript, while not as functional as clojure, is far more
> functional than java ( first class functions, closures, anonymous
> functions etc.

Javascript is simply painful to use functionally. The verbosity of anonymous 
functions, the lack of crucial HOFs like map/filter/reduce, the lack of 
functional data structures, the lack of macros (not strictly a "functional" 
feature, but especially useful with functional code)... You can fix these to 
varying degrees with libraries; but in any case the overall superiority of 
Clojure syntax and data structures must be obvious to anyone interested in 
ClojureScript, since those are the sole advantages it provides over Javascript.

> A small subset of clojure would mirror and could expand
> on a small subset of javascript); it's been called a "Lisp in C's
> Clothing", and Brendan Eich famously and repeatedly said "As I’ve
> often said, and as others at Netscape can confirm, I was recruited to
> Netscape with the promise of “doing Scheme” in the browser" Back at
> Netscape "doing a scheme in the browser" was botched a bit by a deal
> with Sun and "the diktat from upper engineering management was that
> the language must “look like Java”."[1], and whereas clojure/
> clojurescript now had an opportunity to correct that, instead it's
> piling on the Java-ism with gClosure.

Why should we care what kind of Javascript ClojureScript generates, as long as 
it's correct and performant? The whole point of the project is to allow us to 
write Clojure rather than Javascript!

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

Re: Forcing evaluation of returned anonymous javascript function in ClojureScript

[Alen Ribic]

Thanks Dave for pointing me to the distinctions section.

For some reason (-> % .target (.getRequestText)) didn't work but
instead the .. interop macro worked as follows (.. % target
(getResponseText)) [1].

-Al

[1] Working version: https://gist.github.com/1102641

On Jul 24, 9:19 pm, Dave Ray  wrote:
> See the "Host Interop" section here [1]. With ClojureScript there's a
> distinction between method lookup and method invocation. I think what
> you want is:
>
> (-> % .target (.getResponseText))
>
> Dave
>
> [1]https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure
>
>
>
>
>
>
>
> On Sun, Jul 24, 2011 at 1:51 PM, Alen Ribic  wrote:
> > Firstly, thank you Clojure/core team and other contributors for this
> > exciting project.
>
> > I have a small problem I've encountered while building a simple
> > personal blog, as an exercise, with Clojure/ClojureScript and would
> > appreciate any feedback.
>
> > I have a client-side function that sends a request to a specific URI
> > on the server-side that respondes with an HTML fragment/snippet.
> > The request event is received by the front-end callback function and
> > it simply "replaces" a specific HTML node with the HTML fragment
> > received from the server side.
>
> > The Cljs code:
> >https://gist.github.com/1102641
>
> > Upon the request from the client-side code, I can confirm that the
> > server successfully responds with the HTML fragment as shown in the
> > example below:
>
> > 
> >      
> >        Content sub-heading
> >        Content...
> >        [Meta-data]
> >      
> >      
> >        Content sub-heading 2
> >        Content 2...
> >        [Meta-data]
> >      
> > 
>
> > Line 15 in the cljs script is meant to replace the HTML node with the
> > HTML fragment received from the server above.
> > Instead, the result is an unevaluated anonymous function below:
>
> > function (){try{return this.a?this.a.responseText:""}catch(a){return
> > E(this.e,"Can not get responseText: "+a.message),""}}
>
> > If I replace the (-> % .target .getResponseText) on line 16, with a
> > simple hardcoding, "Test", everything works as
> > expected.
>
> > To conclude, I have tested the entire cljs script, and it works as
> > expected, with an exception to (-> % .target .getResponseText) on line
> > 16.
>
> > Do I perhaps have to force the evaluation of the returned anonymous
> > function or is there some special ClojureScript macro/function that I
> > omitted from the process?
>
> > -Alen
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Sean Corfield]

On Sun, Jul 24, 2011 at 11:11 AM, James Keats  wrote:
> If so where does this leave clojure itself and its advocacy of
> functional programming, then; see last paragraph of my reply to Mark.

Given that JS is merely the "assembler" that ClojureScript targets -
in exactly the same way that Java bytecode is the "assembler" that
Clojure targets on the JVM (and presumably CLR bytecode for that VM) -
I don't see why you're concerned about the Closure library here.
Clojure developers are used to working with nice, clean functional
wrappers around Java libraries so why should ClojureScript be any
different? Closure is an implementation detail.

(and, yes, you do seem to be trolling... again)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: clojurescript and external libs

[Sean Corfield]

On Sun, Jul 24, 2011 at 12:31 PM, Jack Moffitt  wrote:
> Unfortunately this means that my external JS lib won't get any
> benefits from the closure compiler. Is there some way to tell the
> compiler where more external libs are and then use them via :require
> just like closure library (let's assume for the moment they are
> goog.provides and goog.require compatible,etc)?

Isn't that the problem tho'? Outside of Google Closure itself, most JS
libraries aren't sufficiently compatible with the compiler's
conventions to be optimized - Rich specifically called out jQuery in
his talk as an example of this.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Mark Rathwell]

>I think it's a bit absurd, folks, to criticize Java's OOP as
>incidental complexity, too much ceremony, and even suggest in the Joy
>of Clojure that a Steve Yegge's Universal Design Pattern and prototype
>pattern a la Javascript could be married to clojure's in the chapter
>that discuss namespaces, multimethods, protocols and datatypes, and
>then turn around and implicitly declare to the world with the release
>of clojurescript "oh noes! if we're gonna do anything substantial then
>this doesn't scale! we need a Java like solution!"

>From this quote (and many others) of yours: " I always advocate that people
adopt a managerial/business-case approach.", it seemed as though you value
maturity and a proven track record, both in programmers and in technology
stacks.  Google's library is the result of many years in battle with large
scale javascript applications, and it is a proven solution.  To me it seems
a bit absurd to champion Java because it is a proven, robust option, then
belittle Closure because it isn't the flavor of javascript you like.

In any case, from the coding point of view, you will be writing code in
Clojure (with a "j"), only using the functionality of google's library, in
the much the same way as you use the functionality of the JDK, so I'm not
sure exactly what it is you are wanting with ClojureScript and jQuery.

 - Mark


On Sun, Jul 24, 2011 at 1:25 PM, James Keats wrote:

>
>
> On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> > Wasn't it just a couple weeks ago that you were arguing that everything
> > should be more like Java?  Now you're arguing that Google Closure is bad
> > because it has some similarities to Java development (mainly verbosity
> and
> > documentation).  I'm honestly not sure if you are just trying to be
> > controversial, or to appear smart, but I'll bite (time for a break
> anyways).
> >
> > Closure is not idomatic javascript:
> > ---
> >
> > Do you have an actual argument from experience here, or are you
> > regurgitating what you've read in articles like [1].  Is CoffeeScript
> > idiomatic javascript?  How about Dojo?  SproutCore?  jQuery?  What
> exactly
> > is idiomatic javascript?
> >
> > vs. jQuery:
> > ---
> >
> > jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
> > apps, I don't think anyone argues that.  And it is extrememly simple, not
> > even requiring the user to know any javascript to use it.  This is why it
> is
> > so (deservedly) popular.
> >
> > Large scale, single page applications are a different thing than page
> based
> > sites, however.  Writing these types of apps with only jQuery quickly
> turns
> > to spaghetti.  There are some nice libraries/frameworks out there, like
> > Backbone and Underscore, that do a very nice job of making it cleaner and
> > scalable.  These are all still fairly young though, to be fair.
> >
> > In the realm of proven environments for large scale, client side
> javascript
> > development, you have Dojo and Google Closure, and to some degree
> SproutCore
> > and Cappuccino.  If you can point me to larger scale apps than GMail,
> Google
> > Docs, etc., written using jQuery, I will gladly have a look.
> >
> > Once you get to that scale, you really needing a way to organize code, to
> > package and load modules, etc.  Dojo and Closure offer a pretty nice, and
> > proven, system for this.
> >
> > So, yes, I would have preferred Dojo, because I am more familiar.  But to
> be
> > fair, Closure is very similar, is a very complete library, and has very
> good
> > documentation and examples for the most part.
> >
>
> On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> > Wasn't it just a couple weeks ago that you were arguing that everything
> > should be more like Java?  Now you're arguing that Google Closure is bad
> > because it has some similarities to Java development (mainly verbosity
> and
> > documentation).  I'm honestly not sure if you are just trying to be
> > controversial, or to appear smart, but I'll bite (time for a break
> anyways).
> >
> > Closure is not idomatic javascript:
> > ---
>
> I'm not "arguing that everything should be more like Java", but
> rather, if you're targetting the JVM then Java, if you're targetting
> javascript then javascript.
>
> I'm aware of the article you pointed out, but no, that article is
> mostly about the implementation details within closure, which is a
> lesser concern to me. I think a good book about idiomatic javascript
> would probably be Douglass Crockford's Javascript: the Good Parts, and
> just as good if not even better is JavaScript Patterns by Stoyan
> Stefanov; emphasis on a functional programming small subset of
> javascript, using closures and prototypes, et cetera. I had been aware
> of the Google Closure library through its book, which I read when it
> first came out; I invite you to read this book. It's too Java-esque;
> java-inspired annotations, java-inspired OOP, too much complexity and
> ceremony, and the author pointedly dismisses much of the 

Clojure number crunching win ! was Re: Needing type hinting help for number crunching

[bernardH]

Thank you very much for the help !

On Jul 24, 2:30 pm, Chas Emerick  wrote:
> A couple of thoughts:
>
> You should be using 1.3.0-beta1 of Clojure 1.3 -- anything with 
> -master-SNAPSHOT is woefully out of date at
> this point.

Damned, I thought -master-SNAPSHOT was as snapshot of the current
HEAD.
Thanks for pointing that out.

> ...
> However, I wouldn't expect (much of) a speedup from those minor tweaks.  
> First, if that reduce with the >`compute-step` fn is your hot loop, reduce 
> will box you into oblivion.  At least until primitives work across
> applications of HOFs, you'll need to unroll that by hand.  Second, you're 
> destructuring with `[next-put-value
> next-call-value]`.  Destructuring is convenient and usually not a bottleneck, 
> but it often is if you're
> attempting to avoid boxing overhead: what you have now is boxing the two 
> values you're binding, and then
> creating a vector to hold them, and then pulling that vector apart to get to 
> the original values.  You can just
> move your conditional out of the let's binding vector, and use it to choose 
> between two recur paths:
>...

I had a wallclock time of 54094 msecs and two relection warnings about
the loop variables (plus the unimportnant one about the swap! return
type).
I first followed your advice to remove destructuring and was surprised
to see that the warnings for the two loop variables had disappeared !
However, the speedup was indeed minor, down to 50573 msecs.
I then removed the reduce as you suggested and went to this inner
loop :
(loop [put-value  0.
   call-value  0.]
  (if (neg? (swap! n-iters-todo dec))
  [put-value call-value]
  (let [delta-price (- strike-price
   (loop [price stock-price
  s n-steps]
  (if (== s 0)
   price
   (recur (* price (+ 1.
  (*
(.nextDouble double-normal-rng 0. volatility)
 
coeff)
  (* risk-
free-rate (/ years-to-maturity n-steps
   (dec s)]
(if (pos? delta-price)
(recur  (+ put-value delta-price) call-value)
(recur  put-value (- call-value delta-price)))

Quiet ugly by Clojure standard I confess, but *incredibly* efficient
with a run time down to 5993 msecs !
(No missing digit: a near x10 speedup !) : faster than both my C++
OpenMP and my C++ 0X multi-threaded implementations !

This is the first time that I witness this (discounting micro
benchmarks made on purpose to show off the JIT).

Thanks for making this happen :)

Best Regards,
Bernard

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

Re: clojurescript and external libs

[Brenton]

Jack,

You can use the :libs key in the options which are passed to build.

For example, there is a directory of third party libraries in "closure/
library/third_party/closure" which may be pulled in like this:

cljsc src {:libs ["closure/library/third_party/closure"] ...other
options...} > ouptput.js

You may now require things from this library and use the standard
interop mechanisms. The JavaScript files from these libraries will be
pulled into the build process and run through the Closure compiler
with the rest of your code. The library files must conform to the
Google Closure standards and use the Closure dependency system (i.e.
goog.provide and goog.require).

This feature is not documented yet and may change in the future.

As a related issue, if you would like to include third party
ClojureScript files in your project, they only need to be put on the
classpath.

P.S.

js* is not for doing interop. It for implementing nasty stuff at the
very bottom and for temporarily working around problems until
ClojureScript is finished.

On Jul 24, 12:35 pm, Jack Moffitt  wrote:
> I'm exploring clojurescript and wondering how to use an external
> library? In my particular case, I was trying to use Soy from Closure
> Templates.
>
> I realize that arbitrary third party libraries will need to fit into
> the Closure Compiler ways, and part of my exploration is trying to
> port some of my own to them, but my first roadblock was figuring out
> how to get clojurescript to see them at all.
>
> Is there a simple example of this anyone can share? Or a pointer to
> the code would probably help as well.
>
> jack.

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

Re: Clojure number crunching win ! was Re: Needing type hinting help for number crunching

[Sean Corfield]

On Sun, Jul 24, 2011 at 1:11 PM, bernardH
 wrote:
> On Jul 24, 2:30 pm, Chas Emerick  wrote:
>> You should be using 1.3.0-beta1 of Clojure 1.3 -- anything with 
>> -master-SNAPSHOT is woefully out of date at
>> this point.
> Damned, I thought -master-SNAPSHOT was as snapshot of the current
> HEAD.
> Thanks for pointing that out.

If you specify the Sonatype snapshots repository, you can pull nightly builds:

  :repositories { "sonatype" { :url
"https://oss.sonatype.org/content/repositories/snapshots"; } }
  :dependencies [[org.clojure/clojure "1.3.0-master-SNAPSHOT"]]

That just pulled clojure-1.3.0-master-20110622.000355-98.jar which is
the most recent nightly build according to build.clojure.org.

Without that repo, I've no idea what build you'd get...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Anyone on Google+ yet?

[Alen Ribic]

https://plus.google.com/118362877851205553020/posts

-Al

On Jul 14, 7:12 pm, Claudia Doppioslash
 wrote:
> My Clojure circle is all set up but empty.
> My g+ is:http://gplus.to/gattoclaudia
>
> Please add link to your profile below.

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

Re: [incanter]State, how to do it right ? (rng state for parallel computing)

[bernardH]

(@cej38: thanks for bringing that up to my radar ! However, I'd have
to check the fine prints because I like the "Open" in "OpenCL" and
dispise vendor lock-ins, no matter how shiny the shackles :) )


On Jul 24, 1:11 pm, Lee Spector  wrote:
> On Jul 22, 2011, at 11:20 AM, bernardH wrote:
>
>
>
> > But there is a small catch : most of the time is spent in the Random
> > Number Generator [3] so it would be sub-optimal to just have worker
> > threads processing the output of a single threaded rng.
>
> I am not very confident in my solution to a similar problem, and my 
> application makes measurement difficult,
> but in case it's food for thought what I did was the following, using the 
> standard Java rng:
>
> ;; create a root binding for the "thread-local-random-generator", although 
> this won't be used in
> the distributed code:
>
> (def thread-local-random-generator (new java.util.Random))

Thank you for your anwser. I cannot comment much on your particular
choice wrt to java.Util.Random because I wanted to use MersenneTwister
and was contraint by some of it's implementation details (in parallel
colt).

I had though about going the same root of a thread local binding but
the colt implementation was not synchronized when using generator
objects (but the static member functions are synchronized).
So I first had a root binding to nil, and a rng that checked if the
binding was nil (calling the static synchronized member functions) or
not (calling the member functions).

However, I gave up on having a generic solution because I'd have to
give up half of the performance if I wanted generic generators (i.e.
not tied to mean, sd) as the Box-Muller algorithm comptes pairs of
numbers (and the colt implementation caches the number if possible
(mean and sd same as given upon generator construction).

This is an ugly implementation detail but I really wanted the best
performance, efficient rng being of utmost importance for my Monte-
Carlo code. Otherwise, I can't think of anything better that your
approach (but hey, that is why I called the gurus here for help :) ).

One should however investigated the thread-safety of the rng because
either the root binding is not safe to share, or your are paying for
useless synchro in your thread-local rng.

Best Regards,

Bernard

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Base]

"Why should we care what kind of Javascript ClojureScript generates,
as long as it's correct and performant? The whole point of the project
is to allow us to write Clojure rather than Javascript!"

James, you do get this point, right?  Just like GWT allows you to
program in Java to write JavaScript, and get the 'benefits' of not
having to actually write JS to develop web clients, ClojureScript
allows you to program in Clojure to write JavaScript that CloSure
likes.

If you like programming in Clojure than you *should* appreciate this
point.  If you don't, than it seems to me that you are just picking a
fight to pick a fight.

On Jul 24, 3:09 pm, Mark Rathwell  wrote:
> >I think it's a bit absurd, folks, to criticize Java's OOP as
> >incidental complexity, too much ceremony, and even suggest in the Joy
> >of Clojure that a Steve Yegge's Universal Design Pattern and prototype
> >pattern a la Javascript could be married to clojure's in the chapter
> >that discuss namespaces, multimethods, protocols and datatypes, and
> >then turn around and implicitly declare to the world with the release
> >of clojurescript "oh noes! if we're gonna do anything substantial then
> >this doesn't scale! we need a Java like solution!"
>
> From this quote (and many others) of yours: " I always advocate that people
> adopt a managerial/business-case approach.", it seemed as though you value
> maturity and a proven track record, both in programmers and in technology
> stacks.  Google's library is the result of many years in battle with large
> scale javascript applications, and it is a proven solution.  To me it seems
> a bit absurd to champion Java because it is a proven, robust option, then
> belittle Closure because it isn't the flavor of javascript you like.
>
> In any case, from the coding point of view, you will be writing code in
> Clojure (with a "j"), only using the functionality of google's library, in
> the much the same way as you use the functionality of the JDK, so I'm not
> sure exactly what it is you are wanting with ClojureScript and jQuery.
>
>  - Mark
>
> On Sun, Jul 24, 2011 at 1:25 PM, James Keats wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> > > Wasn't it just a couple weeks ago that you were arguing that everything
> > > should be more like Java?  Now you're arguing that Google Closure is bad
> > > because it has some similarities to Java development (mainly verbosity
> > and
> > > documentation).  I'm honestly not sure if you are just trying to be
> > > controversial, or to appear smart, but I'll bite (time for a break
> > anyways).
>
> > > Closure is not idomatic javascript:
> > > ---
>
> > > Do you have an actual argument from experience here, or are you
> > > regurgitating what you've read in articles like [1].  Is CoffeeScript
> > > idiomatic javascript?  How about Dojo?  SproutCore?  jQuery?  What
> > exactly
> > > is idiomatic javascript?
>
> > > vs. jQuery:
> > > ---
>
> > > jQuery is awesome for adding dynamicity and ajaxy stuff to page based web
> > > apps, I don't think anyone argues that.  And it is extrememly simple, not
> > > even requiring the user to know any javascript to use it.  This is why it
> > is
> > > so (deservedly) popular.
>
> > > Large scale, single page applications are a different thing than page
> > based
> > > sites, however.  Writing these types of apps with only jQuery quickly
> > turns
> > > to spaghetti.  There are some nice libraries/frameworks out there, like
> > > Backbone and Underscore, that do a very nice job of making it cleaner and
> > > scalable.  These are all still fairly young though, to be fair.
>
> > > In the realm of proven environments for large scale, client side
> > javascript
> > > development, you have Dojo and Google Closure, and to some degree
> > SproutCore
> > > and Cappuccino.  If you can point me to larger scale apps than GMail,
> > Google
> > > Docs, etc., written using jQuery, I will gladly have a look.
>
> > > Once you get to that scale, you really needing a way to organize code, to
> > > package and load modules, etc.  Dojo and Closure offer a pretty nice, and
> > > proven, system for this.
>
> > > So, yes, I would have preferred Dojo, because I am more familiar.  But to
> > be
> > > fair, Closure is very similar, is a very complete library, and has very
> > good
> > > documentation and examples for the most part.
>
> > On Jul 24, 5:02 pm, Mark Rathwell  wrote:
> > > Wasn't it just a couple weeks ago that you were arguing that everything
> > > should be more like Java?  Now you're arguing that Google Closure is bad
> > > because it has some similarities to Java development (mainly verbosity
> > and
> > > documentation).  I'm honestly not sure if you are just trying to be
> > > controversial, or to appear smart, but I'll bite (time for a break
> > anyways).
>
> > > Closure is not idomatic javascript:
> > > ---
>
> > I'm not "arguing that everything should be more like Java", but
> > rather, if you're targetting the JVM 

Re: Alright, fess up, who's unhappy with clojurescript?

[Rich Hickey]

On Jul 24, 11:19 am, James Keats  wrote:
> Alright, to be honest, I'm disappointed.
>

I'll make sure you get a refund then.

Seriously, this is like being disappointed an action movie was an
action movie instead of a comedy. Your expectations are a complete
mismatch for the intentions of ClojureScript.

> First of all, congrats and good job to all involved in putting it out.
> On the plus side, it's a good way to use the Google Closure javascript
> platform.
>
> On the minus, imho, that's what's wrong with it.
>
> Google Closure is too Java.

Actually, it's too JavaScript. Some JS proponents want to disavow its
pseudo class model, but it certainly is part of the design of
JavaScript. And it has some particular advantages over the other
strategies, as outlined here:

http://bolinfest.com/javascript/inheritance.php

> It's not idiomatic JavaScript.

There's no such thing as idiomatic JavaScript. There are a lot of
different conventions used by different libraries.

> I find it
> disappointing that rather than porting from a functional language like
> Clojure straight to another functional language like Javascript, the
> google closure with its ugly Java-isms is right there obnoxiously in
> the middle.
>

In the middle of what? I look at ClojureScript code and it looks like
Clojure to me. Google Closure is under, and it is no more annoying
there than Java is under Clojure - an implementation detail, and a
rich source of production-quality code.

> Then, there's the elephant in the room, and that elephant is Jquery. I
> believe any targetting-javascript tool that misses out on jquery-first-
> and-foremost is missing out on the realities of javascript in 2011.

Should it be the purpose of a new language like ClojureScript to
orient itself around the realities of currently popular JavaScript
libraries? I think not. If you want jQuery as the center of your
universe, JavasScript is your language - good luck with it. I see
jQuery as a tool to be leveraged when appropriate (i.e. rarely in
large programs), not an architectural centerpiece.

> Jquery is huge in its community and plugins, and it has tons of books
> and tutorials.

So what? Those people are satisfied by, and not leaving, JavaScript,
and I'm fine with that.

> Then, the Google Closure compiler is a moot point.

If you seriously cannot see the benefits of Google's compiler then you
are not the target audience for ClojureScript. In any case, for those
interested there is an argument for Google's approach in the
rationale, as well as this page on the wiki:

https://github.com/clojure/clojurescript/wiki/Google-Closure

> I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> so that seamless interop with jquery would be the main priority.
>

Is that a threat, or a promise? I suggest you start by writing up a
rationale like this one:

https://github.com/clojure/clojurescript/wiki/Rationale

making your intentions and the superiority of your approach clear.
Then prepare yourself for messages from people who don't bother to
read or understand it.

Messages like yours make creating things and releasing them for free a
really exhausting endeavor.

Good luck with your fork - please start a separate mailing list for
discussions about it.

Rich

p.s. note to others - if you have read the docs and have honest
questions about the approach, I and others would be happy to explain.
But we could do without messages about disappointment, threats of
forks etc. ClojureScript is an action movie, and we're interested in
helping people kick butt.

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

clojurescript development workflow

[Sam Aaron]

Hi there,

Having never really enjoyed javascript and therefore avoiding it for the 
longest time, I'm now quite excited to jump into it given the introduction of 
ClojureScript. It's really quite exciting - thanks everyone for putting so much 
effort and thought into it.

One thing I'm wondering about (and hope that someone with more ClojureScript 
dev experience than myself could help illuminate things for me) is what a 
typical ClojureScript development workflow looks like.

With Clojure, I do the following:

* start up a swank server
* hack in the repl
* hack in the text editor - sending forms to be evaled on the swank server
* instantly see/hear (if I'm doing GUI/sound work) the results of my evals

I walked through the first two Google Closure tutorials:

* http://code.google.com/closure/library/docs/gettingstarted.html
* http://code.google.com/closure/library/docs/tutorial.html

My workflow lacked a REPL (although I believe they exist in some web browsers) 
but I was able to modify the code, hit refresh in the browser and immediately 
see changes.

However, when I went through the ClojureScript tutorial:

* https://github.com/clojure/clojurescript/wiki/Quick-Start

Although I did get a REPL, it was totally disconnected from the browser, so I 
wasn't able to test any GUI stuff with it and if I modified the code I had to 
wait quite a long time for the js to compile before I saw the changes in the 
browser.

I'm therefore wondering, how do other people with more experience develop with 
ClojureScript? Is there any way of getting the wonderful flow of code 
creation/evaluation/visibility that you can get in a typical Clojure workflow?

Thanks in advance,

Sam

---
http://sam.aaron.name

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Charlie Griefer]

On Sun, Jul 24, 2011 at 2:28 PM, Rich Hickey  wrote:
>ClojureScript is an action movie, and we're interested in
> helping people kick butt.

Could you please tweet that, if only so I can retweet it? :)

-- 
Charlie Griefer
http://charlie.griefer.com/

I have failed as much as I have succeeded. But I love my life. I love
my wife. And I wish you my kind of success.

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

Re: leiningen 1.6.1 not compatible with lein-nailgun 1.1.0

[Phil Hagelberg]

On Tue, Jul 19, 2011 at 6:27 PM, Wei Hsu  wrote:
> Thanks for the tips, Phil! This may be somewhat of a newbie question,
> but what's the best way to modify lein-nailgun and include that local
> fork in my project using leiningen?

It's probably best to create your own github fork of lein-nailgun and
do the fix there. Then submit it as a pull request upstream. If you
need to use it locally before it gets accepted upstream, just run
"lein install" inside your own checkout. It's best if your fork has a
different version number (or a snapshot) from upstream so you can
distinguish it in your own project's project.clj file.

-Phil

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

Re: clojurescript development workflow

[Eric Lavigne]

>
>
> Although I did get a REPL, it was totally disconnected from the browser, so
> I wasn't able to test any GUI stuff with it and if I modified the code I had
> to wait quite a long time for the js to compile before I saw the changes in
> the browser.
>
>
As mentioned in Rich's presentation video, a lot of the "compile" time is
actually startup time. If the compiler is invoked from a Clojure REPL, it is
much faster.

I know this isn't a complete answer to your question - just offering my 2
cents.

Also, look for a recent post by Peter Taoussanis. It sounds like he has come
up with a very good workflow for ClojureScript development.

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

Re: Leiningen on OpenBSD

[Phil Hagelberg]

On Sat, Jul 23, 2011 at 10:24 AM, Scott Scites  wrote:
> While walking through the Clojure/Heroku/Database tutorial the Leiningen REPL 
> fails to display a prompt.  When I control-c out, the final output before 
> closing shows a connection being made and the prompt.  If I change out of the 
> project directory and lein repl I get the connection and the prompt as I 
> would expect.
>
> Is there a solution to this problem?  How might I debug the issue?  Should I 
> file a bug with the Leiningen project?

Feel free to file a bug on the github issue tracker for Leiningen,
provided you're running a compliant Java 1.5 or higher. (not GCJ, for
instance.)

When you run a repl inside a project directory, Leiningen starts a
socket server inside your project, and it runs what is essentially a
telnet client inside Leiningen's own process. (This is due to a
shortcoming of ant where stdin isn't visible from your project's
process.) So you can try to determine if the failure is in the client
or the server. One way to check would be to set the LEIN_REPL_PORT
environment variable to something like 2000, then try to connect via
telnet or netcat in a separate terminal. If it works, then the problem
is with the I/O inside the Leiningen JVM rather than the code that
Leiningen runs inside your project's process.

Another thing to check would be to see if
clojure.contrib.server-socket/create-socket-repl (from contrib 1.2)
works. If not, then it's probably not a Leiningen bug.

-Phil

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

Re: Leiningen on OpenBSD

[Aaron Bedra]

It appears that the ports tree does offer a sun jdk now that you can 
build, but it is 1.7.  If you are running 4.9 and are using the jdk from 
the ports tree, this could also be the source of your problem.


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 07/23/2011 09:57 PM, Aaron Bedra wrote:

The java that you cobble together for openbsd is really a mess. Unless they 
have a working version of the standard jdk, I wouldn't bother. I love and 
support the openbsd project, but I stay away from any kind of java on openbsd.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On Jul 23, 2011, at 10:24 AM, Scott Scites  wrote:


While walking through the Clojure/Heroku/Database tutorial the Leiningen REPL 
fails to display a prompt.  When I control-c out, the final output before 
closing shows a connection being made and the prompt.  If I change out of the 
project directory and lein repl I get the connection and the prompt as I would 
expect.

Is there a solution to this problem?  How might I debug the issue?  Should I 
file a bug with the Leiningen project?

Thank you.

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



--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

Well I'm very very sorry if the intent of my post was misunderstood or
I articulated it poorly, but I would like to emphasize, Rich, that I'm
a big fan of yours and in no way intended to exhaust you, I was merely
and honestly voicing my concerns, just like in a previous thread I
have quoted you time and again and voiced my agreement with and
admiration of your work and positions with regard to clojure itself. I
have watched all your talks on vimeo several times, and read most of
what I could find online of interviews with you, and with regard to
clojurescript I did read the rationale, I watched your talk twice and
carefully, and I had the google closure book for almost a year now,
which includes a reprint of the article you linked to and that I had
previously linked to this this thread.

"forking" was in no way a threat, but a suggested possibility to see
what everyone here thought, whether there were others like me, who
aren't fond of google closure, who perceive a demand for it, as a non-
gclosure alternative that'd be part of the clojure toolset.
Unfortunately my intent seems to have been misunderstood or I'd
miscommunicated it, whichever, I find regrettable.


On Jul 24, 10:28 pm, Rich Hickey  wrote:
> On Jul 24, 11:19 am, James Keats  wrote:
>
> > Alright, to be honest, I'm disappointed.
>
> I'll make sure you get a refund then.
>
> Seriously, this is like being disappointed an action movie was an
> action movie instead of a comedy. Your expectations are a complete
> mismatch for the intentions of ClojureScript.
>
> > First of all, congrats and good job to all involved in putting it out.
> > On the plus side, it's a good way to use the Google Closure javascript
> > platform.
>
> > On the minus, imho, that's what's wrong with it.
>
> > Google Closure is too Java.
>
> Actually, it's too JavaScript. Some JS proponents want to disavow its
> pseudo class model, but it certainly is part of the design of
> JavaScript. And it has some particular advantages over the other
> strategies, as outlined here:
>
> http://bolinfest.com/javascript/inheritance.php
>
> > It's not idiomatic JavaScript.
>
> There's no such thing as idiomatic JavaScript. There are a lot of
> different conventions used by different libraries.
>
> > I find it
> > disappointing that rather than porting from a functional language like
> > Clojure straight to another functional language like Javascript, the
> > google closure with its ugly Java-isms is right there obnoxiously in
> > the middle.
>
> In the middle of what? I look at ClojureScript code and it looks like
> Clojure to me. Google Closure is under, and it is no more annoying
> there than Java is under Clojure - an implementation detail, and a
> rich source of production-quality code.
>
> > Then, there's the elephant in the room, and that elephant is Jquery. I
> > believe any targetting-javascript tool that misses out on jquery-first-
> > and-foremost is missing out on the realities of javascript in 2011.
>
> Should it be the purpose of a new language like ClojureScript to
> orient itself around the realities of currently popular JavaScript
> libraries? I think not. If you want jQuery as the center of your
> universe, JavasScript is your language - good luck with it. I see
> jQuery as a tool to be leveraged when appropriate (i.e. rarely in
> large programs), not an architectural centerpiece.
>
> > Jquery is huge in its community and plugins, and it has tons of books
> > and tutorials.
>
> So what? Those people are satisfied by, and not leaving, JavaScript,
> and I'm fine with that.
>
> > Then, the Google Closure compiler is a moot point.
>
> If you seriously cannot see the benefits of Google's compiler then you
> are not the target audience for ClojureScript. In any case, for those
> interested there is an argument for Google's approach in the
> rationale, as well as this page on the wiki:
>
> https://github.com/clojure/clojurescript/wiki/Google-Closure
>
> > I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> > so that seamless interop with jquery would be the main priority.
>
> Is that a threat, or a promise? I suggest you start by writing up a
> rationale like this one:
>
> https://github.com/clojure/clojurescript/wiki/Rationale
>
> making your intentions and the superiority of your approach clear.
> Then prepare yourself for messages from people who don't bother to
> read or understand it.
>
> Messages like yours make creating things and releasing them for free a
> really exhausting endeavor.
>
> Good luck with your fork - please start a separate mailing list for
> discussions about it.
>
> Rich
>
> p.s. note to others - if you have read the docs and have honest
> questions about the approach, I and others would be happy to explain.
> But we could do without messages about disappointment, threats of
> forks etc. ClojureScript is an action movie, and we're interested in
> helping people kick butt.

-- 
You received this message because you are subscribed to the G

Re: Problem with ClojureScript and Node.js

[Ulrik Sandberg]

I have the same problem, using an unmodified clojurescript checkout
(08db38f) with nodejs 0.4.10 on MacOSX 10.6.8.

$ cat nodehello.cljs
(ns nodehello)

(defn -main [& args]
  (println (apply str (map [\ "world" "hello"] [2 0 1]

(set! *main-cli-fn* -main)
$ bin/cljsc nodehello.cljs
'{:optimizations :advanced :target :nodejs}' > nodehello.js
$ node nodehello.js

node.js:134
throw e; // process.nextTick error, or 'error' event on first
tick
^
TypeError: Cannot read property 'prototype' of undefined
at Object. (/Source/Git/clojurescript/nodehello.js:
14:382)
at Module._compile (module.js:402:26)
at Object..js (module.js:408:10)
at Module.load (module.js:334:31)
at Function._load (module.js:293:12)
at Array. (module.js:421:10)
at EventEmitter._tickCallback (node.js:126:26)

On 24 Juli, 07:53, Benny Tsai  wrote:
> I should add that I did have to make one change to closure.clj in order to
> compile nodehello.cljs; I changed the following line in the ns->file-name
> function:
>
>   path (string/replace (munge ns) \. java.io.File/separatorChar)]
>
> To:
>
>   path (string/replace (munge ns) \. \/)]

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

Re: Alright, fess up, who's unhappy with clojurescript?

[James Keats]

On Jul 24, 10:23 pm, Base  wrote:
> "Why should we care what kind of Javascript ClojureScript generates,
> as long as it's correct and performant? The whole point of the project
> is to allow us to write Clojure rather than Javascript!"
>
> James, you do get this point, right?  Just like GWT allows you to
> program in Java to write JavaScript, and get the 'benefits' of not
> having to actually write JS to develop web clients, ClojureScript
> allows you to program in Clojure to write JavaScript that CloSure
> likes.
>
> If you like programming in Clojure than you *should* appreciate this
> point.  If you don't, than it seems to me that you are just picking a
> fight to pick a fight.

I'm certainly not just picking a fight, I'm honestly voicing a
concern. I believe you still need to learn and know and understand and
be mindful of gclojure to use clojurescript. Furthermore, gClosure is
low level in what it offers, you'd have to roll your own for much of
what you could reuse elsewhere, and google acknowledges this in its
docs:

"What is the relation between the Closure Library and other JavaScript
libraries?
Many JavaScript libraries emphasize the ability to easily add
JavaScript effects and features with minimal development time. Google
engineers use these third-party tools for precisely the reason that
the libraries are powerful for rapid development.
The Closure Library is designed for use in very large JavaScript
applications. It has a rich API and provides tools for working with
the browser at a lower level. It's not well suited for all tasks, but
we think it provides a useful option for web developers."

Outside of google the closure library hasn't had much uptake and it's
not part of the burgeoning javascript scene.

I just feel it's ironic that on the JVM the idea is that the best
practices of java that are conducive to "very large" application
development are considered too painful for everyday development and
therefore the reason d'etre of clojure, but when it comes to
javascript then it's the "very large" apps that we'll gear up for and
put up with the consequent everyday pain. It's also ironic that with
clojure on the JVM we'd think that things like transaction software
memory are worthwhile compromises performance-wise, but towards
javascript then a slavish obiedience to the google closure compiler -
which predates JITed javascript VMs, and predates the closure library
which was modeled with it in mind - is prioritized over the
development experience or a burgeoning platform of libs.

Anyhow, not wishing to be further misunderstood, I regret any
miscommunication and offer everyone my kindest regards.

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

Re: Alright, fess up, who's unhappy with clojurescript?

[Ulrik Sandberg]

OK, good. Now, say you're sorry if you offended him. -"I'm sorry if I
offended you." And you, say you're sorry if you over-reacted. "I'm
sorry if I over-reacted." Very good. Now, shake hands. Good. I love
you both. You should love each other too. You'll need each other
later.

--
Father of three boys

On 25 Juli, 00:34, James Keats  wrote:
> Well I'm very very sorry if the intent of my post was misunderstood or
> I articulated it poorly, but I would like to emphasize, Rich, that I'm
> a big fan of yours and in no way intended to exhaust you, I was merely
> and honestly voicing my concerns, just like in a previous thread I
> have quoted you time and again and voiced my agreement with and
> admiration of your work and positions with regard to clojure itself. I
> have watched all your talks on vimeo several times, and read most of
> what I could find online of interviews with you, and with regard to
> clojurescript I did read the rationale, I watched your talk twice and
> carefully, and I had the google closure book for almost a year now,
> which includes a reprint of the article you linked to and that I had
> previously linked to this this thread.
>
> "forking" was in no way a threat, but a suggested possibility to see
> what everyone here thought, whether there were others like me, who
> aren't fond of google closure, who perceive a demand for it, as a non-
> gclosure alternative that'd be part of the clojure toolset.
> Unfortunately my intent seems to have been misunderstood or I'd
> miscommunicated it, whichever, I find regrettable.
>
> On Jul 24, 10:28 pm, Rich Hickey  wrote:
>
>
>
>
>
>
>
> > On Jul 24, 11:19 am, James Keats  wrote:
>
> > > Alright, to be honest, I'm disappointed.
>
> > I'll make sure you get a refund then.
>
> > Seriously, this is like being disappointed an action movie was an
> > action movie instead of a comedy. Your expectations are a complete
> > mismatch for the intentions of ClojureScript.
>
> > > First of all, congrats and good job to all involved in putting it out.
> > > On the plus side, it's a good way to use the Google Closure javascript
> > > platform.
>
> > > On the minus, imho, that's what's wrong with it.
>
> > > Google Closure is too Java.
>
> > Actually, it's too JavaScript. Some JS proponents want to disavow its
> > pseudo class model, but it certainly is part of the design of
> > JavaScript. And it has some particular advantages over the other
> > strategies, as outlined here:
>
> >http://bolinfest.com/javascript/inheritance.php
>
> > > It's not idiomatic JavaScript.
>
> > There's no such thing as idiomatic JavaScript. There are a lot of
> > different conventions used by different libraries.
>
> > > I find it
> > > disappointing that rather than porting from a functional language like
> > > Clojure straight to another functional language like Javascript, the
> > > google closure with its ugly Java-isms is right there obnoxiously in
> > > the middle.
>
> > In the middle of what? I look at ClojureScript code and it looks like
> > Clojure to me. Google Closure is under, and it is no more annoying
> > there than Java is under Clojure - an implementation detail, and a
> > rich source of production-quality code.
>
> > > Then, there's the elephant in the room, and that elephant is Jquery. I
> > > believe any targetting-javascript tool that misses out on jquery-first-
> > > and-foremost is missing out on the realities of javascript in 2011.
>
> > Should it be the purpose of a new language like ClojureScript to
> > orient itself around the realities of currently popular JavaScript
> > libraries? I think not. If you want jQuery as the center of your
> > universe, JavasScript is your language - good luck with it. I see
> > jQuery as a tool to be leveraged when appropriate (i.e. rarely in
> > large programs), not an architectural centerpiece.
>
> > > Jquery is huge in its community and plugins, and it has tons of books
> > > and tutorials.
>
> > So what? Those people are satisfied by, and not leaving, JavaScript,
> > and I'm fine with that.
>
> > > Then, the Google Closure compiler is a moot point.
>
> > If you seriously cannot see the benefits of Google's compiler then you
> > are not the target audience for ClojureScript. In any case, for those
> > interested there is an argument for Google's approach in the
> > rationale, as well as this page on the wiki:
>
> >https://github.com/clojure/clojurescript/wiki/Google-Closure
>
> > > I'm tempted to "fork" clojurescript and redo it in javascript perhaps
> > > so that seamless interop with jquery would be the main priority.
>
> > Is that a threat, or a promise? I suggest you start by writing up a
> > rationale like this one:
>
> >https://github.com/clojure/clojurescript/wiki/Rationale
>
> > making your intentions and the superiority of your approach clear.
> > Then prepare yourself for messages from people who don't bother to
> > read or understand it.
>
> > Messages like yours make creating things and releasing them for free a
> > r

clojurescript advanced compile error

[Jack Moffitt]

I'm working through Closure tutorials translating them to
ClojureScript. Unfortunately, I've hit a problem where the code works
with {:optimizations :simple} but fails with {:optimizations
:advanced}.

The code is very simple. It basically is a trivial template example
with Soy (from Closure templates). Here's example/core.cljs:

(ns example.core
  (:require [goog.dom :as dom]
[goog.date :as date]
[soy :as soy]
[example.templates :as tmpls]))

(defn map-to-obj [m]
  (.strobj (reduce (fn [m [k v]]
 (assoc m k v))
   {}
   (map #(vector (name %1) %2) (keys m) (vals m)

(defn ^:export say-hello [message]
  (let [hello (dom/getElement "hello")]
(dom/setTextContent hello message)))

(defn ^:export say-hello2 [message]
  (let [hello (dom/getElement "hello")
data {:greeting message
  :year (. (date/Date.) (getFullYear))}]
(soy/renderElement hello tmpls/welcome (map-to-obj data


And the template hello.soy:


{namespace example.templates}

/**
 * @param greeting
 * @param year
 */
{template .welcome}
  {$greeting}
  The year is {$year}.
{/template}


The template is compiled to hello.soy.js.  I pass in the path to
hello.soy.js as well as closure-templates/javascript during compile.

The HTML:




  
Example: Hello World
  
  





  example.core.say_hello2("Hello World!");

  


With simple optimizations, this produces the expected output. With
advanced optimizations both fields of the template are undefined.

I'm probably doing something silly. Any ideas?

jack.

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

Re: clojurescript and external libs

[Jack Moffitt]

> You can use the :libs key in the options which are passed to build.

Thanks very much for this pointer. That worked like a charm.

jack.

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

casting and type declaration

[Kartik]

Hello.  I have the following code snippet to start reading an mp3 file

(let [file (File. filename)
  stream (AudioSystem/getAudioInputStream file)
  base-format (.getFormat stream)
  decoded-format (AudioFormat. AudioFormat$Encoding/
PCM_SIGNED ...)
  line-info (DataLine$Info. SourceDataLine decoded-format)
  decoded-stream (AudioSystem/getAudioInputStream decoded-format
stream)
  line (AudioSystem/getLine line-info)
  buffer (byte-array (* 1024 4))]
  (pprint line)
  (.open line decoded-format)
  (.start line)
  ...)

This works fine on Mac OSX.  The pprint gives

#

When I run it in windows I get

Can't call public method of non-public class: public void
com.sun.media.sound.AbstractDataLine.open(javax.sound.sampled.AudioFormat)
throws javax.sound.sampled.LineUnavailableException
  [Thrown class java.lang.IllegalArgumentException]

This time the pprint gives

 #

The problem is that getLine on windows returns DirectSDL which is a
private inner class of DirectAudioDevice.  I tried casting it to
SourceDataLine which is the type I need (which is a literal
translation of equivalent java code I'm following) by doing

  line (cast SourceDataLine (AudioSystem/getLine line-info))

But that didn't work.  I had to declare the type like so

  #^SourceDataLine line (AudioSystem/getLine line-info)

My question is what is the difference between casting and type
declaration?  Why does one work and not the other in this case?  In
general, when is one used over the other?

I found a related post from Rich 
http://www.mail-archive.com/clojure@googlegroups.com/msg13283.html
where he says the let (without type declaration I assume) should allow
the compiler to infer the type.

Thanks

Kartik

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

Re: Problem with ClojureScript + Node.js

[Sean Corfield]

On Sat, Jul 23, 2011 at 9:28 PM, Benny Tsai  wrote:
> The same error was encountered with both the 0.5.2 and 0.5.1 Windows
> binaries from http://nodejs.org/dist/.  A similar error was thrown when I
> tried the 0.4.9 and 0.4.8 binaries from http://node-js.prcn.co.cc/:
...
> Has anyone had success using ClojureScript with Node.js, either on Windows
> or otherwise?

On Mac OS X, I built Node from source per the instructions here:
https://github.com/joyent/node/wiki/Installation

That gave me version v0.4.11-pre and it seems to be working just fine
with ClojureScript. The build from source option on Windows sounds
like it isn't very stable which makes we wonder about the pre-built
binaries and why those would be any more stable? :(
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Problem with ClojureScript + Node.js

[Benny Tsai]

On Sunday, July 24, 2011 1:33:47 PM UTC-6, Sean Corfield wrote:
>
> That gave me version v0.4.11-pre and it seems to be working just fine
> with ClojureScript. The build from source option on Windows sounds
> like it isn't very stable which makes we wonder about the pre-built
> binaries and why those would be any more stable? :(
>
 Thank you for replying, Sean :)  It's probably time for me to go back to 
Ubuntu as my development environment and save myself some pain...

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

Re: Problem with ClojureScript and Node.js

[Benny Tsai]

Thank you for your response, Urlik.  It's good to know someone else saw the 
same error, on a non-Windows platform, no less.  Sean Corfield, responding 
to an earlier failed attempt by me to post about the problem, said that he 
was able to use Node with ClojureScript on OSX after following the 
instructions at https://github.com/joyent/node/wiki/Installation 
and building Node 0.4.11-pre from source.  Perhaps that might work for you 
as well?

If anyone else has experienced this problem, please feel free to chime in!

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

Re: better community docs: getting started

[nchurch]

> The community getting started page could be much better. In particular, 
> people have opined that there should be a clear, no-choices-
> to-make path "For Newbies" section.Help welcome!

I just got edit privileges on dev.clojure and am eager work on it.
How do people want to see Getting Started on dev.clojure organized?
Right now there are 12 (!) headings right under Getting Started.  How
about reducing it to four:

1) Getting Clojure
2) Editing Clojure
3) Using Clojure
4) Tools

This is the order in which newcomers need to do things.

Under 1) would be a guide for setting up Lein with the Lein REPL.  At
the end would be a list of links for alternative options.
Under 2) would be a guide for setting up Emacs (immediately divided
into Mac, Windows, Linux).  At the end would be a list of alternative
options: Eclipse, Netbeans, IntelliJ, etc.
Under 3), guides to setting up web programming (+ ClojureScript now?),
Incanter, and any other killer apps---but not an infinite list by any
means.  Less common applications again would be relegated to links
(which may link within dev.clojure of course).
Under 4), anything that doesn't fit under the first three: build tools
and debuggers with a standard option for each, and once again
alternative choices at the end.  (Lein has of course already been
covered.)

The basic idea is to make some choices, and tuck all the extra
information out of the top level.  Perhaps there could also be a link
at the top for an index to everything, as well.

If we really wanted to be radically open, we could include with each
option some of the data from the recent State of Clojure survey,
describing what proportion of the community actually use the option in
question.  This is exactly the kind of thing newcomers want to know,
and have trouble finding.  Perhaps it is impolitic to be so open about
it, but

I don't know how complicated this would be to do, but is there any way
to make a kind of community scratch space for the documentation?  It
would be nice to try out and work on reorganized and rewritten
documentation before it is linked to directly from clojure.org.  Just
a thought.

N.

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

Re: {ANN} clojure-control---DSL for system admin and deployment with many remote machines

[dennis]

Now it's allow passing command line arguments to task now,the task
macro is changed,it must have an argument vector now:

(task :deploy "deploy a file to remote machines"
  [file]
  (scp (file) "/home/user1"))

And run with

 clojure controls.clj deploy release.tar.gz

The "release.tar.gz" will be used as "file" argument for scp macro.

clojure-control is still on development,any suggestion welcomed.


On 7月24日, 下午9时41分, dennis  wrote:
> 1.What is clojure-control?
>
> The idea came from node-control(https://github.com/tsmith/node-
> control).
> Define clusters and tasks for system administration or code
> deployment, then execute them on one or many remote machines.
> Clojure-control depends only on OpenSSH and clojure on the local
> control machine.Remote machines simply need a standard sshd daemon.
>
> 2.Quick example
>
> Get the current date from the two machines listed in the 'mycluster'
> config with a single command:
>
>  (ns samples
>  (:use [control.core :only [task cluster scp ssh begin]]))
>  ;;define clusters
>  (cluster :mycluster
>  :clients [
>{ :host "a.domain.com" :user "alogin"}
>{ :host "b.domain.com" :user "blogin"}
>  ])
>  ;;define tasks
>  (task :date "Get date"
>   (ssh "date"))
> ;;start running
> (begin)
>
> If saved in a file named "controls.clj",run with
>
> java -cp clojure.jar:clojure-contrib.jar:control-0.1-SNAPSHOT.jar
> clojure.main controls.clj mycluster date
>
> Each machine execute "date" command ,and the output form the remote
> machine is printed to the console.Exmaple console output
>
> Performing mycluster
> Performing date for a.domain.com
> a.domain.com:ssh: date
> a.domain.com:stdout: Sun Jul 24 19:14:09 CST 2011
> a.domain.com:exit: 0
> Performing date for b.domain.com
> b.domain.com:ssh: date
> b.domain.com:stdout: Sun Jul 24 19:14:09 CST 2011
> b.domain.com:exit: 0
>
> Each line of output is labeled with the address of the machine the
> command was executed on. The actual command sent and the user used to
> send it is displayed. stdout and stderr output of the remote process
> is identified as well as the final exit code of the local ssh
> command.
>
> 3.How to scp files?
> Let's define a new task named deploy
>
>   (task :deploy "scp files to remote machines"
> (scp ("release1.tar.gz" "release2.tar.gz") "/home/alogin/"))
>
> Then it will copy release1.tar.gz and release2.tar.gz to remote
> machine's /home/alogin directory.
>
> 4.More information please goto project homepage
>
> https://github.com/killme2008/clojure-control
>
> Any suggestion or bug reports welcomed.

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

Re: Leiningen on OpenBSD

[scitesy]

On Jul 24, 6:21 pm, Aaron Bedra  wrote:
> It appears that the ports tree does offer a sun jdk now that you can
> build, but it is 1.7.  If you are running 4.9 and are using the jdk from
> the ports tree, this could also be the source of your problem.

Thanks for your help!
I'm running OpenBSD 5.0 beta with jdk 1.7.  Does Leiningen not run on
1.7 yet?

Scott
>
> Cheers,
>
> Aaron Bedra
> --
> Clojure/corehttp://clojure.com
>
> On 07/23/2011 09:57 PM, Aaron Bedra wrote:
>
>
>
>
>
>
>
>
>
> > The java that you cobble together for openbsd is really a mess. Unless they 
> > have a working version of the standard jdk, I wouldn't bother. I love and 
> > support the openbsd project, but I stay away from any kind of java on 
> > openbsd.
>
> > Cheers,
>
> > Aaron Bedra
> > --
> > Clojure/core
> >http://clojure.com
>
> > On Jul 23, 2011, at 10:24 AM, Scott Scites  wrote:
>
> >> While walking through the Clojure/Heroku/Database tutorial the Leiningen 
> >> REPL fails to display a prompt.  When I control-c out, the final output 
> >> before closing shows a connection being made and the prompt.  If I change 
> >> out of the project directory and lein repl I get the connection and the 
> >> prompt as I would expect.
>
> >> Is there a solution to this problem?  How might I debug the issue?  Should 
> >> I file a bug with the Leiningen project?
>
> >> Thank you.
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/clojure?hl=en
>
> --
> Cheers,
>
> Aaron Bedra
> --
> Clojure/corehttp://clojure.com

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

Re: better community docs: getting started

[Ken Wesson]

On Sun, Jul 24, 2011 at 10:28 PM, nchurch  wrote:
>
>> The community getting started page could be much better. In particular, 
>> people have opined that there should be a clear, no-choices-
>> to-make path "For Newbies" section.Help welcome!
>
> I just got edit privileges on dev.clojure and am eager work on it.
> How do people want to see Getting Started on dev.clojure organized?
> Right now there are 12 (!) headings right under Getting Started.  How
> about reducing it to four:
>
> 1) Getting Clojure
> 2) Editing Clojure
> 3) Using Clojure
> 4) Tools
>
> This is the order in which newcomers need to do things.
>
> Under 1) would be a guide for setting up Lein with the Lein REPL.  At
> the end would be a list of links for alternative options.
> Under 2) would be a guide for setting up Emacs (immediately divided
> into Mac, Windows, Linux).  At the end would be a list of alternative
> options: Eclipse, Netbeans, IntelliJ, etc.

No.

No, no, no, no, no!

That will kill 90% of the people that try it as potential future
Clojurians. They'll install emacs, try to use it, throw keyboards out
windows and mice through monitors, say "What? Huh? WTF is this shit!?
AAGH!" and then run out of standard curse words and resort to
"sweet crobdonker!". And then go play around in Java or C++ and curse
your name every morning until their dying day.

How about making the main suggestion be clooj instead, with emacs,
eclipse, netbeans in the list of alternative options? :)

> Under 3), guides to setting up web programming (+ ClojureScript now?),
> Incanter, and any other killer apps---but not an infinite list by any
> means.  Less common applications again would be relegated to links
> (which may link within dev.clojure of course).

Maybe start with helloworld? :)

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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

Re: better community docs: getting started

[László Török]

+1, as I went through the same process. Emacs should be the option for the
brave ones who already wrote their first helloworld.clj.

sent from my mobile device

On Jul 25, 2011 6:14 AM, "Ken Wesson"  wrote:
> On Sun, Jul 24, 2011 at 10:28 PM, nchurch  wrote:
>>
>>> The community getting started page could be much better. In particular,
people have opined that there should be a clear, no-choices-
>>> to-make path "For Newbies" section.Help welcome!
>>
>> I just got edit privileges on dev.clojure and am eager work on it.
>> How do people want to see Getting Started on dev.clojure organized?
>> Right now there are 12 (!) headings right under Getting Started.  How
>> about reducing it to four:
>>
>> 1) Getting Clojure
>> 2) Editing Clojure
>> 3) Using Clojure
>> 4) Tools
>>
>> This is the order in which newcomers need to do things.
>>
>> Under 1) would be a guide for setting up Lein with the Lein REPL.  At
>> the end would be a list of links for alternative options.
>> Under 2) would be a guide for setting up Emacs (immediately divided
>> into Mac, Windows, Linux).  At the end would be a list of alternative
>> options: Eclipse, Netbeans, IntelliJ, etc.
>
> No.
>
> No, no, no, no, no!
>
> That will kill 90% of the people that try it as potential future
> Clojurians. They'll install emacs, try to use it, throw keyboards out
> windows and mice through monitors, say "What? Huh? WTF is this shit!?
> AAGH!" and then run out of standard curse words and resort to
> "sweet crobdonker!". And then go play around in Java or C++ and curse
> your name every morning until their dying day.
>
> How about making the main suggestion be clooj instead, with emacs,
> eclipse, netbeans in the list of alternative options? :)
>
>> Under 3), guides to setting up web programming (+ ClojureScript now?),
>> Incanter, and any other killer apps---but not an infinite list by any
>> means.  Less common applications again would be relegated to links
>> (which may link within dev.clojure of course).
>
> Maybe start with helloworld? :)
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: better community docs: getting started

[Ambrose Bonnaire-Sergeant]

On Mon, Jul 25, 2011 at 12:14 PM, Ken Wesson  wrote:
>
> How about making the main suggestion be clooj instead, with emacs,
> eclipse, netbeans in the list of alternative options? :)
>
>
+1! I'd be embarrassed trying to sell clojure to a newbie with anything
else.

Clean and simple, and not a toy.

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

Re: better community docs: getting started

[pmbauer]

+1 on clooj.
One click and you have a working build environment, REPL, and REPL-aware 
editor.

https://github.com/downloads/arthuredelstein/clooj/clooj-0.1.5-standalone.jar

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

Re: Leiningen on OpenBSD

[Phil Hagelberg]

On Sun, Jul 24, 2011 at 8:39 PM, scitesy  wrote:
> On Jul 24, 6:21 pm, Aaron Bedra  wrote:
>> It appears that the ports tree does offer a sun jdk now that you can
>> build, but it is 1.7.  If you are running 4.9 and are using the jdk from
>> the ports tree, this could also be the source of your problem.
>
> Thanks for your help!
> I'm running OpenBSD 5.0 beta with jdk 1.7.  Does Leiningen not run on
> 1.7 yet?

I would like to support 1.7 but haven't tried it myself. I have heard
reports of it working OK on Linux systems. If you could try the same
thing with 1.7 on Linux, it would be helpful so we know whether it's
OpenBSD or 1.7.

thanks,
Phil

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

Re: ClojureScript

[FL]

On Jul 24, 1:44 pm, Peter Taoussanis  wrote:
>
...
> I am, literally, deploying this to my web app right now. I've got a
> Compojure route setup for a the resulting output of memoized
> ClojureScript compile call. I can work on the ClojureScript directly
> from my project. When something changes, I re-evaluate the memoized fn
> on my dev box (or on the production server through an SSH tunnel) and
> boom: I have a fully-optimized script going out to users. Add in a
> content-hash of the compiled script to automatically expire the old
> resource, and I have a workflow that I couldn't imagine being much
> better.
...
> --Peter

Could you describe your setup in some more detail? (I'd like to use
clojure+clojurescript for a netCDF-compatible web mapping server.)

-F

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

Re: Leiningen on OpenBSD

[pmbauer]

FWIW, lein and JDK 1.7 play fine together on both my linux systems (Ubuntu 
10.10 and 11.04).

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

ClojureScript Questions

[cljneo]

Hi,
I have started reading about ClojureScript and Closure and had some
questions which I am sure will eventually be answered as I move along.
But I am too eager to know now so I thought of asking instead of
waiting.
- On page 2 of the Closure book, there is a workflow figure on using
the Closure tools, how would ClojureScript change this workflow? It
would be great to post such a modified diagram to the closure wiki.
- Clojure itself has web development stack (ring, compojure,
enlive,...). Will some of these libraries be redundant in
ClojureScript and will be useful only for web development in Clojure
proper? Or they will still be useful but we will see ClojureScript
versions of them.
- Are there any cases where using the current Clojure web development
libraries would be better than using ClojureScript?

Thanks

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

Re: better community docs: getting started

[Sean Corfield]

On Sun, Jul 24, 2011 at 9:14 PM, Ken Wesson  wrote:
>> Under 2) would be a guide for setting up Emacs (immediately divided
>> into Mac, Windows, Linux).  At the end would be a list of alternative
>> options: Eclipse, Netbeans, IntelliJ, etc.
>
> No.
>
> No, no, no, no, no!
>
> That will kill 90% of the people that try it as potential future
> Clojurians. They'll install emacs, try to use it, throw keyboards out
> windows and mice through monitors, say "What? Huh? WTF is this shit!?

For once I'm in complete agreement with Ken - trying to push Emacs as
the recommended editor for Clojure would be a disaster!

We need to be very clear that pretty much whatever IDE / editor you
use today can be used for Clojure.

Having the Getting Clojure section focus on Leiningen to handle
dependencies, run a REPL and run Clojure scripts (with a -main
function) is a great way to get people started.

I do not think we should attempt a recommended IDE (not even Clooj).
We should offer a path for all existing IDEs / editors. If you're an
Eclipse user, try CCW. If you're an existing Emacs user, here's how to
configure it for Clojure. If you're a TextMate user, here's the
Clojure bundle. And so on. Use an editor not listed here? Try Clooj
(i.e., use this as a simple catch-all if we haven't covered what you
already used today).

Sean

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

Re: clojure.contrib.profile crashes

[Sunil S Nandihalli]

Hi Aaron Bedra,
 Thanks for your quick response. Sorry I could not get back to you with the
information you asked for sooner..

 I am using

user> *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier ""}

My project.clj is as follows...

(defproject bitvector "1.0.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.2.1"]
 [org.clojure/clojure-contrib "1.2.0"]
 [clj-iterate "0.95-SNAPSHOT"]]
  :dev-dependencies [[swank-clojure "1.4.0-SNAPSHOT"]
 [clojure-source "1.2.1"]]
  :main bitvector.core)

do you have any idea why I am getting this out of range thing when I use
clojure.contrib.profile?

Thanks again,
Sunil.

On Fri, Jul 22, 2011 at 4:51 AM, Aaron Bedra  wrote:

> **
> What version of Clojure are you running?
>
> Cheers,
>
> Aaron Bedra
> --
> Clojure/core
> http://clojure.com
>
>
> On 07/21/2011 06:12 PM, Sunil S Nandihalli wrote:
>
> The reason I am not posting the code is because I am not able to reproduce
> this on a simple case. I was just hoping some of you may have some insight
> with out the code..
> Thanks,
> Sunil.
>
>  On Fri, Jul 22, 2011 at 3:29 AM, Sunil S Nandihalli <
> sunil.nandiha...@gmail.com> wrote:
>
>> Hello everybody,
>>  I have used the profiler successfully in the past. But some how it is
>> repeatedly crashing with the following stack trace.
>>
>>  Value out of range for int: 17069635385
>>
>>
>>   [Thrown class java.lang.IllegalArgumentException]
>>
>>
>>
>>
>>
>> Restarts:
>>
>>
>>  0: [QUIT] Quit to the SLIME top level
>>
>>
>>
>>
>>
>> Backtrace:
>>
>>
>>   0: clojure.lang.RT.intCast(RT.java:950)
>>
>>
>>   1: clojure.lang.RT.intCast(RT.java:922)
>>
>>
>>   2: clojure.contrib.profile$summarize$fn__3252.invoke(profile.clj:88)
>>
>>
>>   3: clojure.core$r.invoke(core.clj:799)
>>
>>
>>   4: clojure.contrib.profile$summarize.invoke(profile.clj:85)
>>
>>
>>   5: bitvector.core$eval4530.invoke(NO_SOURCE_FILE:1)
>>
>>
>>   6: clojure.lang.Compiler.eval(Compiler.java:5424)
>>
>>
>>   7: clojure.lang.Compiler.eval(Compiler.java:5391)
>>
>>
>>   8: clojure.core$eval.invoke(core.clj:2382)
>>
>>
>>   9: swank.core$eval650$fn__651.invoke(core.clj:409)
>>
>>
>>  10: clojure.lang.MultiFn.invoke(MultiFn.java:163)
>>
>>
>>  .
>> .
>>  .
>> .
>>
>>  Before I bother you all with actual code which might get messy, does
>> anybody have any suggestion as to why this is happening..?
>> Thanks,
>> Sunil.
>>
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: clojure.contrib.profile crashes

[Sunil S Nandihalli]

here is the list of jar files in my lib directory

github@eagle ~/bitvector/lib#tree
.
|-- clj-iterate-0.95-20110417.030036-2.jar
|-- clojure-1.2.1.jar
|-- clojure-contrib-1.2.0.jar
`-- dev
|-- cdt-1.2.6.1-20110417.030036-6.jar
|-- clojure-1.2.1.jar
|-- clojure-contrib-1.2.0.jar
|-- clojure-source-1.2.1.jar
|-- debug-repl-0.3.1.jar
`-- swank-clojure-1.4.0-20110601.165758-9.jar

1 directory, 9 files


On Mon, Jul 25, 2011 at 12:10 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hi Aaron Bedra,
>  Thanks for your quick response. Sorry I could not get back to you with the
> information you asked for sooner..
>
>  I am using
>
> user> *clojure-version*
> {:major 1, :minor 2, :incremental 1, :qualifier ""}
>
> My project.clj is as follows...
>
> (defproject bitvector "1.0.0-SNAPSHOT"
>   :description "FIXME: write description"
>   :dependencies [[org.clojure/clojure "1.2.1"]
>  [org.clojure/clojure-contrib "1.2.0"]
>  [clj-iterate "0.95-SNAPSHOT"]]
>   :dev-dependencies [[swank-clojure "1.4.0-SNAPSHOT"]
>  [clojure-source "1.2.1"]]
>   :main bitvector.core)
>
> do you have any idea why I am getting this out of range thing when I use
> clojure.contrib.profile?
>
> Thanks again,
> Sunil.
>
> On Fri, Jul 22, 2011 at 4:51 AM, Aaron Bedra wrote:
>
>> **
>> What version of Clojure are you running?
>>
>> Cheers,
>>
>> Aaron Bedra
>> --
>> Clojure/core
>> http://clojure.com
>>
>>
>> On 07/21/2011 06:12 PM, Sunil S Nandihalli wrote:
>>
>> The reason I am not posting the code is because I am not able to reproduce
>> this on a simple case. I was just hoping some of you may have some insight
>> with out the code..
>> Thanks,
>> Sunil.
>>
>>  On Fri, Jul 22, 2011 at 3:29 AM, Sunil S Nandihalli <
>> sunil.nandiha...@gmail.com> wrote:
>>
>>> Hello everybody,
>>>  I have used the profiler successfully in the past. But some how it is
>>> repeatedly crashing with the following stack trace.
>>>
>>>  Value out of range for int: 17069635385
>>>
>>>
>>>   [Thrown class java.lang.IllegalArgumentException]
>>>
>>>
>>>
>>>
>>>
>>> Restarts:
>>>
>>>
>>>  0: [QUIT] Quit to the SLIME top level
>>>
>>>
>>>
>>>
>>>
>>> Backtrace:
>>>
>>>
>>>   0: clojure.lang.RT.intCast(RT.java:950)
>>>
>>>
>>>   1: clojure.lang.RT.intCast(RT.java:922)
>>>
>>>
>>>   2: clojure.contrib.profile$summarize$fn__3252.invoke(profile.clj:88)
>>>
>>>
>>>   3: clojure.core$r.invoke(core.clj:799)
>>>
>>>
>>>   4: clojure.contrib.profile$summarize.invoke(profile.clj:85)
>>>
>>>
>>>   5: bitvector.core$eval4530.invoke(NO_SOURCE_FILE:1)
>>>
>>>
>>>   6: clojure.lang.Compiler.eval(Compiler.java:5424)
>>>
>>>
>>>   7: clojure.lang.Compiler.eval(Compiler.java:5391)
>>>
>>>
>>>   8: clojure.core$eval.invoke(core.clj:2382)
>>>
>>>
>>>   9: swank.core$eval650$fn__651.invoke(core.clj:409)
>>>
>>>
>>>  10: clojure.lang.MultiFn.invoke(MultiFn.java:163)
>>>
>>>
>>>  .
>>> .
>>>  .
>>> .
>>>
>>>  Before I bother you all with actual code which might get messy, does
>>> anybody have any suggestion as to why this is happening..?
>>> Thanks,
>>> Sunil.
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>

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

Re: Clojure number crunching win ! was Re: Needing type hinting help for number crunching

[Tassilo Horn]

Sean Corfield  writes:

Hi Sean,

> If you specify the Sonatype snapshots repository, you can pull nightly
> builds:
>
>   :repositories { "sonatype" { :url
> "https://oss.sonatype.org/content/repositories/snapshots"; } }
>   :dependencies [[org.clojure/clojure "1.3.0-master-SNAPSHOT"]]
>
> That just pulled clojure-1.3.0-master-20110622.000355-98.jar which is
> the most recent nightly build according to build.clojure.org.

Hey, great.  Until now, I've built my own snapshots, because the
official snapshots are out of date.  The only issue is that with the
repo above, version ranges don't work.  If I say

  :dependencies [[org.clojure/clojure "[1.3.0-master-SNAPSHOT,)"]]

aka 1.3.0 snapshot or better, "lein deps force" tries getting a
org.clojure:clojure:jar:1.3.0-testbuild9-SNAPSHOT and fails checksuming
(at least that is what maven wants to tell me...):

[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'88bbc831eaafdd9895f27debc95446618ac82a79'; remote =
'92472231000f7b66ebf43cb412c74b4ba3cd7277' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'88bbc831eaafdd9895f27debc95446618ac82a79'; remote =
'92472231000f7b66ebf43cb412c74b4ba3cd7277' - IGNORING

Bye,
Tassilo

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

Re: better community docs: getting started

[pmbauer]

>
> I do not think we should attempt a recommended IDE (not even Clooj).
> We should offer a path for all existing IDEs / editors. 
>
... 

> Use an editor not listed here? Try Clooj
> (i.e., use this as a simple catch-all if we haven't covered what you
> already used today).
>

That's one way of organizing it.

The slightly serious explorer will of course pick setup documentation for 
their favorite IDE/editor, and that should be provided.

But think of the casual dev wanting to know what Clojure and a typical 
Clojure toolchain can do for her ASAP.
Most Java devs have never used a repl-aware edit buffer, something most of 
us take for granted.
No common IDE/editor setup can expose her to a lisp-style toolchain in a 
single click.  None.

For usability, nothing beats the single-click.  In seconds, Clooj gives her 
a one-stop-shop.
So I see Clooj as something worth putting right along with try-clojure.org.
It not only showcases Clojure, but is rapid exposure to the lisp-style 
toolchain.

That's why I would give Clooj some prominence rather than burying it at the 
bottom of the decision tree.
Anyone knowing what they're looking for will of course move on to the setup 
of their preference (emacs,vi,eclipse), so they don't lose anything.
But the neophyte who doesn't know what they're looking for should have the 
lowest barrier to entry possible - usability.

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

Re: Why is this code so slow?

[Oskar]

On Jul 23, 4:06 pm, Dmitry Gutov  wrote:
> Ahem.
>
> Here is a more idiomatic version that runs under half a second, no
> annotations required.

I did that from the beginning, but as I really needed 4e6 and not 1e5
elements, that map got very big. And I didn't remember the argument to
give java more memory. Also I was just curious to see what arrays did
to the performance. However, my code that looked like that was slow
too. I used Clojure 1.2.0. Are you using 1.3.0?


> (def vs (atom {}))
>
> (defn sk [k]
>   (if (@vs k)
>       (@vs k)
>       (let [ans (if (< k 56)
>                   (- (mod (+ 13 (- (* k 23)) (* 37 k k k))
>                           100) 50)
>                   (- (mod (+ (sk (- k 24))
>                              (sk (- k 55))) 100)
>                      50))]
>         (do (swap! vs assoc k ans)
>             ans
>
> user> (reset! vs {})
> {}
> user> (time (dorun (map sk (range 10
> "Elapsed time: 155.082351 msecs"
> nil
>
> I guess the moral is that the built-in data structures are quite fast,
> and reflection is evil.

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

Re: better community docs: getting started

[Ken Wesson]

On Mon, Jul 25, 2011 at 12:28 AM, pmbauer  wrote:
> +1 on clooj.
> One click and you have a working build environment, REPL, and REPL-aware
> editor.
> https://github.com/downloads/arthuredelstein/clooj/clooj-0.1.5-standalone.jar

This URL is somewhat unfortunate. For some reason, both

https://github.com/downloads/arthuredelstein/clooj/

and

https://github.com/downloads/arthuredelstein/

give 404 pages, so it's not possible to use ".. walking" to get to the
"parent node" -- i.e., Edelstein's Clooj page as a whole, and then
Edelstein's everything-including-Clooj page. That's poor URL design,
but it's probably not Edelstein's fault, but rather github's.

I'd argue that this is another reason for having separate sites for
projects, sites hosted away from places like sourceforge and github
(but linking to those); a generic web host will let you use a better
URL structure so people who, say, only see your download link posted
somewhere and want to read more before committing to downloading
anything can just chop the last segment off your URL and read away.

-- 
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.

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