Re: ClojureQL: consistent select queries?

[Sean Corfield]

On Fri, Jul 29, 2011 at 11:56 PM, László Török  wrote:
> thanks for the pointer, I thought clojure.java.jdbc is 1.3 only. :)

I suspect a lot of ppl think the new contrib libraries are 1.3 only
but Clojure/core made it clear to me that new contrib libraries are
all supposed to be 1.2 compatible. That's part of the migration plan:
everyone can use new contrib _today_ which will make migration to
Clojure 1.3 easier (as well as meaning you don't need to pull in the
whole of contrib 1.2 when you only need a few pieces).
-- 
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?

[Alexander Yakushev]

The moment I saw the previous controversial topic - about "yes
language" push - I realized that Clojure has become mature. When the
people who do not agree with some choices appear not just outside but
in the community itself - it means that the language matters to them
despite the parts they don't like. Matters enough not to just say "Ah,
screw it, I'll just switch to FooLanguage".
So, sit back, get involved in head-punching and just enjoy Clojure
being a grown-up.

-- 
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: Defrecord and Interfaces..

[Andreas Liljeqvist]

Thanks, that was very informative.

I got no technical reason to expect that implementing an interface would
define a function, lets just say that it felt right :/

2011/7/29 Aaron Cohen 

> On Fri, Jul 29, 2011 at 3:18 PM, Andreas Liljeqvist wrote:
>
>> Is this a bug?
>>
>>
> Nope, expectation dissonance.
>
>
>> (defprotocol Notcloseable (dosomething [this]))
>>
>>
> This is what actually defines the function "dosomething". Once this
> definition happens, the function exists and can be called. If you try to
> call it before there are any implementations though you'll get:
>
> user=> (dosomething 1)
> java.lang.IllegalArgumentException: No implementation of method:
> :dosomething of protocol: #'user/Notcloseable found for class:
> java.lang.Integer (NO_SOURCE_FILE:0)
>
> It _also_ for interop purposes defines a Java interface, which classes that
> implement the protocol may or may not implement. If you use extend-type,
> they will not. If you use deftype or defrecord to create a new class that
> implements the protocol, it will also implement the interface. This is the
> basis for the performance advantage of protocols.
>
>
>> (defrecord Archive []
>>   java.io.Closeable
>> (close [_] (print "closeable"))
>>
>>   Notcloseable
>> (dosomething [_] (print "something")))
>>
>>
>> user> (def a (Archive.))
>>
>> user> (.close a)
>> closeable
>>
>
> Uses interop to call through the Closeable interface.
>
>
>> user> (close a)
>>
>> Unable to resolve symbol: close in this context
>>   [Thrown class java.lang.Exception]
>>
>
> No such function exists.
>
>
>> user> (dosomething a)
>> something
>>
>
> Uses the protocol function, and calls the implementation you've provided.
>
>
>> user> (.dosomething a)
>> something
>>
>>
> Uses the interop support to call the Protocol's interface method.
>
>
>> Implementing a protol creates both java function and a clojure function.
>> Implementing an interface only creates the java function.
>>
>
> I'm not sure why you expect that implementing an interface would create a
> function?
>
> --Aaron
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 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

[Laurent PETIT]

2011/7/30 nchurch 

>
> > But my question is : is it ready yet ?
>
> As a quick and simple way to get a REPL and edit code it seems to work
> fine.  I added a sentence about its newness just so people would be
> aware of it...


OK. I can really see it fill in the gaps, as I said above, it has indeed a
great potential. I'm glad one full JDK+Clojure solution finally gets it !


> if the author prefers no tutorial so far, then of course
> it should be taken down.
>
> --
> 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: Libraries and build management hell

[Michal B]

This discussion is getting a lot of "What are you talking about? Leiningen 
is what you're looking for!" replies. I know. I'm a happy lein user, and use 
it and clojars frequently with some of my larger projects. I'm very grateful 
for the work Phil and the other 
contributorsdid. It helped me 
tremendously. There's no need to get defensive. As I tried 
to emphasize several times in my post, this was not an attack on lein or 
other build tools - they certainly have their place in the development 
process. I was trying to get a discussion going on the current library 
situation, which I think if everyone took back a step they'd agree is far 
from ideal. Lein is a remedy, but not a solution. Is lein as good as it 
gets?

Instead of iterating what's available today and how much better it makes 
things (I know), I hope we can question our assumptions about how things are 
and get a discussion going on how to make things better. If not for 
simplicity, do it for the new users who today when visiting the Getting 
Started pages are overwhelmed by rampant choice and endless technical 
procedures.

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

[Brian McKenna]

In JavaScript, the `this` identifier gets "bound" when a function is
called. Determining what to bind is from either:

* Looking up the object that the function was called from

* An explicit parameter in these functions:
  * `Function.prototype.apply`
  * `Function.prototype.call`

So the following two lines are identical:

field.getEditableIframe();
field.getEditableIframe.call(field);

Problem is that ClojureScript does something special. Function calls
always bind `null`.

For example, a call in ClojureScript:

(def iframe ((.getEditableIframe field)))

Emits something like this:

iframe = field.getEditableIframe.call(null);

This problem is breaking quite a few things in Google Closure. In the
above example, Field.prototype.getEditableIframe relies on `this`
being bound properly.

My current work around is:

(defn call [o f] (js* "~{f}.call(~{o})"))

(def iframe (call field (.getEditableIframe field)))

Which generates something like:

iframe = field.getEditableIframe(field);

Obviously emitting raw JavaScript is less than ideal. Am I missing
something built-in to ClojureScript or are there any ideas for a
better work around?

Thanks,
Brian McKenna

-- 
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: Possible Issue with Listing 11.5 from the "Joy of Clojure"

[Julien Chastang]

Thanks for your in-depth analysis.

In conclusion, the 11.5 listing is broken specifically with the
reification of the seq function. The problem is that the seq function
allows the array reference to escape in an unsafe manner. The issue is
concurrency as well as visibility. As you suggest, the only fix is to
safely copy (via the locking function, i.e. synchronized block) the
contents of the array into a data structure that would be passed back
to the calling code.

By the way, I still think you need a lock in the count function in the
case where the caller tries to invoke the count function on a
partially constructed object. You may be able to reason otherwise, but
it is simply confusing to do so. Just access shared mutables in a safe
manner and you will be OK.

On Jul 29, 3:38 pm, Ken Wesson  wrote:
> On Fri, Jul 29, 2011 at 3:19 PM, Julien  wrote:
> > This listing is an attempt to make the function safe for concurrent
> > modification. My claim is that count and seq should also be locking
> > around "a" for exactly same reason as aget and aset. In particular,
> > locking is not only ensuring mutual exclusion but also *visibility*.
> > The danger is that count and seq may be accessing stale values of "a".
>
> In the case of "count" that danger doesn't exist; Java arrays are of
> fixed size from creation, so the "count" value cannot change.
>
> The case of "seq" is trickier: the array can indeed change contents
> midway through iteration. But there's no simple fix. One could write
> something like
>
> (let [cnt (dec (count a))
>       step (fn step [i]
>              (lazy-seq
>                (if (> i cnt)
>                  (do (monitorexit a) nil)
>                  (cons x (step (inc i))]
>   (monitorenter a)
>   (step 0))
>
> to hold a lock all the way through seq traversal, but if the seq is
> only partially traversed (either deliberately, or because of a thrown
> exception) the lock will never get released.
>
> More complicatedly, you could create a CloseableSeq defprotocol that
> extends ISeq and Closeable and create closeable seqs (line-seq could
> benefit from this as well); for the above the close operation would be
> (monitorexit a) (and for line-seq (.close rdr)). Closeable seqs could
> then be created in (with-open ...) and handled in an exception-safe
> manner -- so long as you made sure to consume or doall the seq before
> the end of the with-open scope. In the array seq case, the seq would
> still seem to work after the scope exited, but it would show an array
> in a possible state of flux again instead of a fixed state.
>
> Given all this complication, easiest might be
>
> (seq [this]
>   (locking a
>     (seq (into [] a
>
> which has the downside of copying the array into a vector but the
> upside of being thread- and exception-safe; the seq is backed by a
> fixed snapshot of the array. And can be traversed lazily and at
> leisure without holding onto a lock the whole time; the lock's held
> only during the copying. If you're worried about seeing inconsistent
> cell values during a traversal of a short array this is what you ought
> to use.
>
> But you should probably prefer to avoid arrays for the most part. :)
>
> Note: you will still potentially see *stale* values; the array can
> change after the snapshot is made. To avoid that you'd always have to
> lock during the operation where you want to be seeing the most up to
> date values. But you wouldn't see *inconsistent* values. If the array
> contains all 1s, and then someone else locks it, changes each cell to
> 2, and unlocks, and you are traversing the seq given above, you might
> get back (1 1 1 1 2 2 2 ...) which violates the intended invariant of
> all-the-same-number. With the snapshot you'll possibly see all-1s even
> after it's been updated to all-2s but you will never see a mixture.
> With locking the array the whole time you're working with the seq,
> you'll see all-2s if the array was ever updated to all-2s and
> otherwise the thing that will eventually update it to all-2s will
> block until you're done with the seq.
>
> > See Java Concurrency in Practice, Section 3.1 for more of a
> > discussion. My reasoning is based on the assumption that locking is
> > simply an abstraction for the Java synchronized keyword. That
> > assumption may or may not be correct.
>
> It is correct, though Clojure exposes the lower-level monitorenter and
> monitorexit; both Java synchronized and Clojure locking boil down to
> (the bytecode emitted by)
>
> (try
>   (monitorenter foo)
>   ...
>   (finally (monitorexit foo)))
>
> so as to ensure the lock is released even if an exception is thrown
> out of the critical section. Java just doesn't let you get at the
> separate lock and unlock operations for normal objects (but there are
> the java.util.concurrent lock object classes).
>
> --
> 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

Including additional js in clojurescript compilation

[David Powell]

The closure-template tools let you take a template, and pre-process it to
something like:

hello3.soy.js:

goog.provide('example.templates');
goog.require('soy');
goog.require('soy.StringBuilder');
[...]
example.templates.welcome = function(opt_data, opt_sb) {
[...]


In my clojurescript, I can put:

(:require [example.templates :as temp])

...but when I compile the clojurescript with optimizations, I get an error
from the closure compiler because it doesn't know where to find the
example.templates.

Is there any way of specifying additional javascript files or paths for
clojurescript to pass to the closure compiler?

-- 
Dave

-- 
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: dynamically generated let bindings

[Sam Aaron]

Hi Ken,
On 29 Jul 2011, at 22:02, Ken Wesson wrote:

>> P.S. Thanks everyone for your help so far. My brain is overheating but I am 
>> learning a lot.
> 
> You're welcome.
> 
> To do what you're proposing you will probably need the emitted
> function to look like:
> 
> (fn [& args]
>  (let [foo (some logic goes here)
>bar (some logic goes here)
>...]
>(body goes here)))
> 
> where the first logic checks the args for containing the value for
> foo, if it does evaluates to that value, and if not evaluates to foo's
> default; the second does likewise for bar; and so on.

I just finished implementing a solution and it looks exactly like this. You're 
absolutely right - this is precisely the pattern I was looking for.

What I didn't do, and I think the biggest lesson I've learned from these early 
macro-fighting days, is to do exactly what you propose: sketch out what the 
macro should expand to *before* working on the macro itself.

Thanks everyone once again,

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: Defrecord and Interfaces..

[Andreas Liljeqvist]

On a related note...

If I have something like this:

(defn make-archive [] (Archive. ))

(defrecord Archive []
  java.io.Closeable
(close [_] (print "first try")))

user> (.close (make-archive))
first try

(defrecord Archive []
  java.io.Closeable
(close [_] (print "second try")))

user> (.close (make-archive))
first try

user> (.close (Archive.))
second try

Apparently "make-archive" keeps a reference to the old class.
Should I just learn to evalute all my constructor functions when the
implementation changes?


2011/7/30 Andreas Liljeqvist 

> Thanks, that was very informative.
>
> I got no technical reason to expect that implementing an interface would
> define a function, lets just say that it felt right :/
>
> 2011/7/29 Aaron Cohen 
>
>> On Fri, Jul 29, 2011 at 3:18 PM, Andreas Liljeqvist wrote:
>>
>>> Is this a bug?
>>>
>>>
>> Nope, expectation dissonance.
>>
>>
>>> (defprotocol Notcloseable (dosomething [this]))
>>>
>>>
>> This is what actually defines the function "dosomething". Once this
>> definition happens, the function exists and can be called. If you try to
>> call it before there are any implementations though you'll get:
>>
>> user=> (dosomething 1)
>> java.lang.IllegalArgumentException: No implementation of method:
>> :dosomething of protocol: #'user/Notcloseable found for class:
>> java.lang.Integer (NO_SOURCE_FILE:0)
>>
>> It _also_ for interop purposes defines a Java interface, which classes
>> that implement the protocol may or may not implement. If you use
>> extend-type, they will not. If you use deftype or defrecord to create a new
>> class that implements the protocol, it will also implement the interface.
>> This is the basis for the performance advantage of protocols.
>>
>>
>>> (defrecord Archive []
>>>   java.io.Closeable
>>> (close [_] (print "closeable"))
>>>
>>>   Notcloseable
>>> (dosomething [_] (print "something")))
>>>
>>>
>>> user> (def a (Archive.))
>>>
>>> user> (.close a)
>>> closeable
>>>
>>
>> Uses interop to call through the Closeable interface.
>>
>>
>>>  user> (close a)
>>>
>>> Unable to resolve symbol: close in this context
>>>   [Thrown class java.lang.Exception]
>>>
>>
>> No such function exists.
>>
>>
>>> user> (dosomething a)
>>> something
>>>
>>
>> Uses the protocol function, and calls the implementation you've provided.
>>
>>
>>> user> (.dosomething a)
>>> something
>>>
>>>
>> Uses the interop support to call the Protocol's interface method.
>>
>>
>>> Implementing a protol creates both java function and a clojure function.
>>> Implementing an interface only creates the java function.
>>>
>>
>> I'm not sure why you expect that implementing an interface would create a
>> function?
>>
>> --Aaron
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> 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: Good book on migrating from (Java) OO to FP

[Kenny Stone]

Dean gave a talk at Windy City Rails a few years ago that opened this (ruby)
programmer's eyes to functional programming.  I haven't read the book, but
he's a very good educator.

Kenny

On Sat, Jul 30, 2011 at 12:03 AM, Sean Corfield wrote:

> On Fri, Jul 29, 2011 at 5:03 AM, Colin Yates 
> wrote:
> > Not sure whether this is good etiquette or not, but I wanted to
> > praise http://oreilly.com/catalog/0636920021667.  I found it pretty
> useful
> > in bridging the gap between OO and FP.  It isn't Clojure specific, but as
> a
> > (well established) Java/OO guy, this helped me "get FP".
>
> I think it's very helpful to see recommendations for books that help
> people "get FP"!
>
> One of the problems for folks who've been "doing it" for a long time
> (regardless of which "it" is under discussion) is that it can be
> really hard to figure out how helpful a given book is for those who
> are going thru the learning phase... (unless, perhaps, you are an
> author targeting that audience!).
> --
> 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

-- 
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: Libraries and build management hell

[David Nolen]

On Sat, Jul 30, 2011 at 5:31 AM, Michal B  wrote:

>
> Instead of iterating what's available today and how much better it makes
> things (I know), I hope we can question our assumptions about how things are
> and get a discussion going on how to make things better. If not for
> simplicity, do it for the new users who today when visiting the Getting
> Started pages are overwhelmed by rampant choice and endless technical
> procedures.


It's not clear what problem you want to solve. What kinds of projects are
"small" to you? What's the process that you'd rather have? Is that tproposal
a discernible net improvement to others besides yourself for "small"
projects with lein.

You can't complain much about the answers when your complaint is so vague.

People love to go on and on about the Getting Started pages with little
empirical evidence that's it's a barrier of entry for anyone. Compare to
Python's Getting Started page: http://www.python.org/about/gettingstarted/

Looks like "rampant choice and endless technical procedures".

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: Libraries and build management hell

[Mark Rathwell]

I'm all for a better, easier solution that is better in most ways.  What I'm
saying is:

1. I don't want to go back to downloading jar files from the websites of all
of the libraries I want to use in a project and tracking different versions,
no matter how large or small the project is, as suggested in your OP.  I
think the centralized lein/clojars/github is an improvement over that in
almost every way.

2. I, personally, cannot think of another solution that does not have trade
offs, does not mean I am against it if there is one.  And, as I said, there
are good arguments for and against those trade offs, but to me, personally,
I prefer the trade offs of lein over the environment wide solutions a la
Perl, Python and Ruby (most of the time).

I really think incremental improvements to lein/cake/etc, over time, will
yield better results than going back to square one.

One thing, though, is new users coming from Python/Ruby/etc really do seem
to have a hard time adjusting to the fact the standard is not to have a
Clojure installation, with a clj executable that you run scripts through,
and with globally installed libraries.  Maybe a Clojure installer for
Mac/Windows/Linux, that installs a clj executable on the path, and that has
its own directory that it adds to the classpath when it is run, where you
could install jars (maybe using a lein plugin) that would be available
globally, and not interfere with the current standard.  But that is yet more
choice to overwhelm user, so I don't know.

 - Mark


On Sat, Jul 30, 2011 at 5:31 AM, Michal B  wrote:

> This discussion is getting a lot of "What are you talking about? Leiningen
> is what you're looking for!" replies. I know. I'm a happy lein user, and use
> it and clojars frequently with some of my larger projects. I'm very grateful
> for the work Phil and the other 
> contributorsdid. It helped me 
> tremendously. There's no need to get defensive. As I tried
> to emphasize several times in my post, this was not an attack on lein or
> other build tools - they certainly have their place in the development
> process. I was trying to get a discussion going on the current library
> situation, which I think if everyone took back a step they'd agree is far
> from ideal. Lein is a remedy, but not a solution. Is lein as good as it
> gets?
>
> Instead of iterating what's available today and how much better it makes
> things (I know), I hope we can question our assumptions about how things are
> and get a discussion going on how to make things better. If not for
> simplicity, do it for the new users who today when visiting the Getting
> Started pages are overwhelmed by rampant choice and endless technical
> procedures.
>
>  --
> 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?

[daly]

Try to see the situation from the lead developer perspective
(e.g. Rich's perspective). I have been through the "head-punching",
as you call it and I don't want to put words in Rich's mouth but
I do see things differently.

To lead a project you need to make design choices.
To make those design choices you have to take a lot of factors
into account.
Those factors are optimized based on a lot of considerations,
most of which are stated in the project goal or justification.




As you say, "people who do not agree with the choices appear".
When they do, they generally advocate a particular position that
is in conflict with the project goals or justification. Or they
advocate for a new direction that gets rejected.

These "advocates" are of two varieties. Either they are casual
contributors (posters to the mailing list) or developers who have
invested a lot of time and effort going against the goals.

The "posters" who disagree tend to choose particular topics that 
they find familiar (e.g. autoconf, eclipse, emacs, maven, etc.).
These lead to mini-flame wars (head-punching, bike-shedding).

The developers who disagree tend to choose particular topics that
they have invested time and effort to develop code. These lead to
forks.

In either case, as the lead developer, you constantly have to 
justify your choices. The design space has a lot of freedom so
you have to make choices based on your best judgement. Not everyone
will agree, as you can see. This causes a great deal of stress
on the lead developer, which you DON'T see. Defending every choice
from every poster and developer takes a lot of time and effort.

What is particularly frustrating is the people who ignore your
effort to communicate. If you justify using Google Closure (as
Rich has), if you justify leaving out eval (as Rich has), if you
justify changing certain language features (as Rich has), then
it seems reasonable to expect that people pay attention to the
goals and choices. It is very tiring to keep repeating "the choice
has already been made", especially when code is being written to
support that choice.




As you say, "the language matters to them". Of course it does.
It also matters to Rich. The reason it "matters" is that Rich
is doing an excellent job navigating the design space based on
his considerable experience. He is solving deep problems, like
the expression problem, in novel and creative ways. He is making
tradeoffs based on a lot of factors (unlike the posters) which
take into account project goals such as important performance 
questions.

Posting emails about "who's unhappy with ..." is not constructive
criticism. And when it ignores already stated goals or justifications
it can only result in anger. As a Common Lisper, I see that Rich is
dancing all over my religious beliefs, but that seems to be my
problem, not his. If it makes me unhappy that's also my problem.
Being unhappy with design choices is NOT Rich's problem. So why
would I use Rich's mailing list to complain?

While it is fine to say "get involved in head-punching" I think
it is important to realize that it is Rich's head being punched.

Tim Daly


On Sat, 2011-07-30 at 01:26 -0700, Alexander Yakushev wrote:
> The moment I saw the previous controversial topic - about "yes
> language" push - I realized that Clojure has become mature. When the
> people who do not agree with some choices appear not just outside but
> in the community itself - it means that the language matters to them
> despite the parts they don't like. Matters enough not to just say "Ah,
> screw it, I'll just switch to FooLanguage".
> So, sit back, get involved in head-punching and just enjoy Clojure
> being a grown-up.
> 


-- 
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: Libraries and build management hell

[Mark Engelberg]

On Sat, Jul 30, 2011 at 7:58 AM, Mark Rathwell  wrote:
> One thing, though, is new users coming from Python/Ruby/etc really do seem
> to have a hard time adjusting to the fact the standard is not to have a
> Clojure installation, with a clj executable that you run scripts through,
> and with globally installed libraries.  Maybe a Clojure installer for
> Mac/Windows/Linux, that installs a clj executable on the path, and that has
> its own directory that it adds to the classpath when it is run, where you
> could install jars (maybe using a lein plugin) that would be available
> globally, and not interfere with the current standard.  But that is yet more
> choice to overwhelm user, so I don't know.

I think Mark Rathwell's post is on the right track.  The notion of a
directory for globally installed libraries that you can set once and
automatically have all Clojure tools respect them would be a valuable
one.  The issue I have with the build tools is that they all presume
you want to *build* something.  95% of the time, I just want to open a
file, write some Clojure code, and interactively test it in a REPL.
And yes, there are certain libraries I tend to use, and I want them to
always be available.  Right now, for every file I want to tinker with,
I have to do lein new make-up-some-project-name.  Then I have to go in
and edit the project.clj, trying to remember the names and version
numbers of every library I might use (and this has gotten harder to
remember now that contrib is split into separate modules), add some
development dependencies so I can connect from slime.  Or I can copy
over the project structure from another lein project and go through
and delete all the irrelevant things.  Then I have to lein deps and
wait 10 minutes for it to download the universe.  Then I can lein
swank, and connect to it from emacs, all so that I can start editing a
file with the right classpaths, and play around with it in the REPL.

In Python, I pop open IDLE, start typing some code.  Save it anywhere
I want, and hit F5, and then I'm in a a REPL where I can interact with
the code I just wrote.  Any libraries I've downloaded are available.

In Racket, the story is much like Python, but even a bit better.  Any
library from Racket's Planet repository (sort of analogous to
Clojars), you can refer to in your code, and it will automatically
download and install if you don't have it -- no need to install
libraries ahead of time, and you can email your Racket script to a
friend and trust that it will work on his system regardless of
dependencies.

I would love to have a more streamlined way in Clojure for my personal
common case -- writing a short script and using it interactively.

-- 
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: Libraries and build management hell

[Lee Spector]

On Jul 30, 2011, at 11:24 AM, Mark Engelberg wrote:
> I would love to have a more streamlined way in Clojure for my personal
> common case -- writing a short script and using it interactively.

+1 on the whole perspective presented here, most of which I cut.

 -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: Java object field access

[.Bill Smith]

Oh sorry, I saw the title and thought "bean access" rather than "field 
access".  Obviously the code I posted relies on the presence of setters 
rather than fields.

-- 
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: Libraries and build management hell

[Michal B]

On Saturday, July 30, 2011 6:24:50 PM UTC+3, puzzler wrote:
>
> The issue I have with the build tools is that they all presume
> you want to *build* something.  95% of the time, I just want to open a
> file, write some Clojure code, and interactively test it in a REPL.
>
Exactly what I'm talking about.

> I would love to have a more streamlined way in Clojure for my personal
> common case -- writing a short script and using it interactively.
>
Maybe the next step should involve directly mapping namespaces to libraries 
on a central repository rather than using explicit dependencies. You can 
start your clojure with a namespace defined in init.clj or something 
similar, and as you change namespaces by loading or by other means library 
fetching is done automatically.

One problem with this approach is versions. Maybe a namespace should refer 
to a library's API version instead of referring a "versionless" library. I'm 
not sure if that's really an improvement, though.

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

[Brenton]

The problems with paths on Windows have been fixed and ClojureScript
now has batch files for cljsc, repl, and repljs. There is also a page
in the wiki to help Windows users get started.

https://github.com/clojure/clojurescript/wiki/Windows-Setup

Support for Windows will come from the community so if you care about
this then please do pitch in and help.

On Jul 25, 10:59 am, Timothy Baldridge  wrote:
> Is there a documented way to get ClojureScript working on Windows?
> While I'm familiar with Linux, and use it in several server
> environments, all my development is on Windows, so I don't really have
> access to a Linux box for development.
>
> Timothy
>
> --
> “One of the main causes of the fall of the Roman Empire was
> that–lacking zero–they had no way to indicate successful termination
> of their C programs.”
> (Robert Firth)

-- 
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: Good book on migrating from (Java) OO to FP

[Matthias Cords]

not sure wheret it applies to your requirements: www.gigamonkeys.com/book



On 29 July 2011 14:03, Colin Yates  wrote:

> Hi all,
>
> Not sure whether this is good etiquette or not, but I wanted to praise
> http://oreilly.com/catalog/0636920021667.  I found it pretty useful in
> bridging the gap between OO and FP.  It isn't Clojure specific, but as a
> (well established) Java/OO guy, this helped me "get FP".
>
> (not connected in anyway with the book or author other than through
> appreciation :))
>
> --
> 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 Presentation - video

[Bill Robertson]

blip.tv is still wrapped around a tree.  I've tried several times over
the last several days. I tried a few random other videos too, but no
luck.

Trying to get the avi to play on the mac...


-- 
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: Libraries and build management hell

[Sean Corfield]

On Sat, Jul 30, 2011 at 7:58 AM, Mark Rathwell  wrote:
> Maybe a Clojure installer for
> Mac/Windows/Linux, that installs a clj executable on the path

This was actually how I started with Clojure on Mac OS X (I think the
project was Clojure-MacOSX or something like that) but I quickly found
it was clunky and actually did _not_ match my normally way of working.

FWIW, Leiningen is essentially a central install with all the basic
scripts built in.

On Sat, Jul 30, 2011 at 8:24 AM, Mark Engelberg
 wrote:
> 95% of the time, I just want to open a
> file, write some Clojure code, and interactively test it in a REPL.

Really? Genuine question.

I spend 95% of my time maintaining a 70kloc project (of which ~1,500
is currently Clojure but that's growing and the overall project line
count is shrinking as the amount of Clojure grows). I always have the
project's REPL running in my IDE so I can interactively test code
anyway. The other 5% I work in one of the various REPLs I keep open in
terminal windows (at least one for each of Clojure 1.2 and 1.3).

> And yes, there are certain libraries I tend to use, and I want them to
> always be available.

Once you've used a library, it'll be in your local repo so just adding
the dependency to a scratch project - even if it ends up with a slew
of dependencies - is a quick edit and a very quick lein deps and
you're good to go.

> Then I have to lein deps and
> wait 10 minutes for it to download the universe.

Most new libraries download in a few seconds and once they're local
there's no download overhead (unless you're using snapshots and the
latest version check has to be performed).

> Then I can lein
> swank, and connect to it from emacs, all so that I can start editing a
> file with the right classpaths, and play around with it in the REPL.

I can only attest to Eclipse/CCW but running a REPL with the right
classpath is pretty straightforward.

I hear what folks are saying and I wonder if this all comes down to
expectations based on whether folks come from a JVM background? After
working on the JVM for about 14 years, Clojure, Leiningen and
Eclipse/CCW is about the simplest development setup I've ever had.
Perhaps this is just the price we pay for living on the JVM?

Michal, what's your language background? I see Mark R and Mark E
referring to Python so I can see their point of view on that
comparison.
-- 
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)



> its own directory that it adds to the classpath when it is run, where you
> could install jars (maybe using a lein plugin) that would be available
> globally, and not interfere with the current standard.  But that is yet more
> choice to overwhelm user, so I don't know.
>  - Mark
>
> On Sat, Jul 30, 2011 at 5:31 AM, Michal B  wrote:
>>
>> This discussion is getting a lot of "What are you talking about? Leiningen
>> is what you're looking for!" replies. I know. I'm a happy lein user, and use
>> it and clojars frequently with some of my larger projects. I'm very grateful
>> for the work Phil and the other contributors did. It helped me tremendously.
>> There's no need to get defensive. As I tried to emphasize several times in
>> my post, this was not an attack on lein or other build tools - they
>> certainly have their place in the development process. I was trying to get a
>> discussion going on the current library situation, which I think if everyone
>> took back a step they'd agree is far from ideal. Lein is a remedy, but not a
>> solution. Is lein as good as it gets?
>>
>> Instead of iterating what's available today and how much better it makes
>> things (I know), I hope we can question our assumptions about how things are
>> and get a discussion going on how to make things better. If not for
>> simplicity, do it for the new users who today when visiting the Getting
>> Started pages are overwhelmed by rampant choice and endless technical
>> procedures.
>>
>> --
>> 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: ClojureScript Presentation - video

[Jeff Heon]

I've subscribe to the Blip.tv itunes feed and it makes it really easy
to download the blip.tv videos in iTunes and transfer them to iPod/
iPad.

You can search for Clojure on the iTunes store Podcasts section and
subscribe.

Or you can go in iTunes Advances Menu / Subscribe to Podcast and use
this link:
http://blip.tv/clojure/rss/itunes

On Jul 26, 12:01 pm, Olek  wrote:
> Agree, the same for ipod/ipad devs.
> Youtube is defacto standard for contet publishing, due to wide support.

-- 
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: Including additional js in clojurescript compilation

[Brenton]

Any Google Closure compliant JavaScript can be pulled into the build
process by using the :libs option.

For example:

(build src {:libs ["/foo/bar"]})

would include any JavaScript files under /foo/bar in the build
process.

On Jul 30, 7:02 am, David Powell  wrote:
> The closure-template tools let you take a template, and pre-process it to
> something like:
>
> hello3.soy.js:
>
> goog.provide('example.templates');
> goog.require('soy');
> goog.require('soy.StringBuilder');
> [...]
> example.templates.welcome = function(opt_data, opt_sb) {
> [...]
>
> In my clojurescript, I can put:
>
> (:require [example.templates :as temp])
>
> ...but when I compile the clojurescript with optimizations, I get an error
> from the closure compiler because it doesn't know where to find the
> example.templates.
>
> Is there any way of specifying additional javascript files or paths for
> clojurescript to pass to the closure compiler?
>
> --
> Dave

-- 
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: Libraries and build management hell

[Phil Hagelberg]

On Sat, Jul 30, 2011 at 8:24 AM, Mark Engelberg
 wrote:
> And yes, there are certain libraries I tend to use, and I want them to
> always be available.  Right now, for every file I want to tinker with,
> I have to do lein new make-up-some-project-name.  Then I have to go in
> and edit the project.clj, trying to remember the names and version
> numbers of every library I might use (and this has gotten harder to
> remember now that contrib is split into separate modules), add some
> development dependencies so I can connect from slime.  Or I can copy
> over the project structure from another lein project and go through
> and delete all the irrelevant things.

That sounds like a lot of unnecessary steps. Why delete the irrelevant
things? Or better yet, why start a new project at all? What you're
asking for seems to be "a collection of dependencies that's not
attached to a location on disk", but I fail to see why having it exist
in a certain place on disk is a problem to begin with. If you want a
scratch-pad, why not just re-use the same project?

> Then I have to lein deps and wait 10 minutes for it to download the universe.

If they actually are dependencies that you've used with other
projects, then they'll all be cached; no downloads necessary.

> I would love to have a more streamlined way in Clojure for my personal
> common case -- writing a short script and using it interactively.

On the other hand, maybe you don't want Leiningen at all. Why not use
Jark or cljr instead?

-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: Possible Issue with Listing 11.5 from the "Joy of Clojure"

[pmbauer]

"Please post all Errors and Corrections here"
http://www.manning-sandbox.com/thread.jspa?threadID=41321&tstart=0

On Friday, July 29, 2011 9:10:00 PM UTC-7, Julien Chastang wrote:
>
> Thanks for your in-depth analysis. 
>
> In conclusion, the 11.5 listing is broken specifically with the 
> reification of the seq function. The problem is that the seq function 
> allows the array reference to escape in an unsafe manner. The issue is 
> concurrency as well as visibility. As you suggest, the only fix is to 
> safely copy (via the locking function, i.e. synchronized block) the 
> contents of the array into a data structure that would be passed back 
> to the calling code. 
>
> By the way, I still think you need a lock in the count function in the 
> case where the caller tries to invoke the count function on a 
> partially constructed object. You may be able to reason otherwise, but 
> it is simply confusing to do so. Just access shared mutables in a safe 
> manner and you will be OK. 
>
> On Jul 29, 3:38 pm, Ken Wesson  wrote: 
> > On Fri, Jul 29, 2011 at 3:19 PM, Julien  wrote: 
> > > This listing is an attempt to make the function safe for concurrent 
> > > modification. My claim is that count and seq should also be locking 
> > > around "a" for exactly same reason as aget and aset. In particular, 
> > > locking is not only ensuring mutual exclusion but also *visibility*. 
> > > The danger is that count and seq may be accessing stale values of "a". 
> > 
> > In the case of "count" that danger doesn't exist; Java arrays are of 
> > fixed size from creation, so the "count" value cannot change. 
> > 
> > The case of "seq" is trickier: the array can indeed change contents 
> > midway through iteration. But there's no simple fix. One could write 
> > something like 
> > 
> > (let [cnt (dec (count a)) 
> >   step (fn step [i] 
> >  (lazy-seq 
> >(if (> i cnt) 
> >  (do (monitorexit a) nil) 
> >  (cons x (step (inc i))] 
> >   (monitorenter a) 
> >   (step 0)) 
> > 
> > to hold a lock all the way through seq traversal, but if the seq is 
> > only partially traversed (either deliberately, or because of a thrown 
> > exception) the lock will never get released. 
> > 
> > More complicatedly, you could create a CloseableSeq defprotocol that 
> > extends ISeq and Closeable and create closeable seqs (line-seq could 
> > benefit from this as well); for the above the close operation would be 
> > (monitorexit a) (and for line-seq (.close rdr)). Closeable seqs could 
> > then be created in (with-open ...) and handled in an exception-safe 
> > manner -- so long as you made sure to consume or doall the seq before 
> > the end of the with-open scope. In the array seq case, the seq would 
> > still seem to work after the scope exited, but it would show an array 
> > in a possible state of flux again instead of a fixed state. 
> > 
> > Given all this complication, easiest might be 
> > 
> > (seq [this] 
> >   (locking a 
> > (seq (into [] a 
> > 
> > which has the downside of copying the array into a vector but the 
> > upside of being thread- and exception-safe; the seq is backed by a 
> > fixed snapshot of the array. And can be traversed lazily and at 
> > leisure without holding onto a lock the whole time; the lock's held 
> > only during the copying. If you're worried about seeing inconsistent 
> > cell values during a traversal of a short array this is what you ought 
> > to use. 
> > 
> > But you should probably prefer to avoid arrays for the most part. :) 
> > 
> > Note: you will still potentially see *stale* values; the array can 
> > change after the snapshot is made. To avoid that you'd always have to 
> > lock during the operation where you want to be seeing the most up to 
> > date values. But you wouldn't see *inconsistent* values. If the array 
> > contains all 1s, and then someone else locks it, changes each cell to 
> > 2, and unlocks, and you are traversing the seq given above, you might 
> > get back (1 1 1 1 2 2 2 ...) which violates the intended invariant of 
> > all-the-same-number. With the snapshot you'll possibly see all-1s even 
> > after it's been updated to all-2s but you will never see a mixture. 
> > With locking the array the whole time you're working with the seq, 
> > you'll see all-2s if the array was ever updated to all-2s and 
> > otherwise the thing that will eventually update it to all-2s will 
> > block until you're done with the seq. 
> > 
> > > See Java Concurrency in Practice, Section 3.1 for more of a 
> > > discussion. My reasoning is based on the assumption that locking is 
> > > simply an abstraction for the Java synchronized keyword. That 
> > > assumption may or may not be correct. 
> > 
> > It is correct, though Clojure exposes the lower-level monitorenter and 
> > monitorexit; both Java synchronized and Clojure locking boil down to 
> > (the bytecode emitted by) 
> > 
> > (try 
> >   (monitorenter foo) 
> 

Re: ClojureScript on Windows

[Benny Tsai]

Brenton, thank you for your efforts!

I noticed that in the current .bat files, CLASSPATH is directly modified and 
over-written.  Perhaps they should instead use CLJSC_CP like the sh scripts?

On Saturday, July 30, 2011 10:10:03 AM UTC-6, Brenton wrote:
>
> The problems with paths on Windows have been fixed and ClojureScript 
> now has batch files for cljsc, repl, and repljs. There is also a page 
> in the wiki to help Windows users get started. 
>
> https://github.com/clojure/clojurescript/wiki/Windows-Setup 
>
> Support for Windows will come from the community so if you care about 
> this then please do pitch in and help. 
>

-- 
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: Libraries and build management hell

[Mark Engelberg]

On Sat, Jul 30, 2011 at 10:43 AM, Sean Corfield  wrote:
> On Sat, Jul 30, 2011 at 8:24 AM, Mark Engelberg
>  wrote:
>> 95% of the time, I just want to open a
>> file, write some Clojure code, and interactively test it in a REPL.
>
> Really? Genuine question.

You're probably right that by *time*, I'm mostly working in large
projects that I've already set up (although most of my work is at the
REPL, rather than with the focus of building a jar).  I guess what I'm
thinking of is that 95% of the time when I go to start something new,
it ends up being for a short-lived task, so psychologically, the extra
hassle associated with creating a project infrastructure makes me want
to reach for something other than Clojure.

Phil makes a reasonable point that it is possible to create a single
"project" for one-off tasks.  I'm not sure how well that would work
with the way I have things organized, and with my source control, but
it's something I can look into.

-- 
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: Possible Issue with Listing 11.5 from the "Joy of Clojure"

[Ken Wesson]

On Sat, Jul 30, 2011 at 12:10 AM, Julien Chastang
 wrote:
> By the way, I still think you need a lock in the count function in the
> case where the caller tries to invoke the count function on a
> partially constructed object.

I don't think that's possible in this case. As far as code running on
the JVM is concerned, either the array does not exist or it does and
already has its length field set correctly; you can't be holding a
reference to a Java array that is "partially constructed" in such a
manner as to allow data races with the length field. And I don't think
Clojure allows holding a reference to a partially constructed
type/record either, as you can't put custom code into the constructor
that (MyRecord. x y z) calls, just call it and get back a reference to
a fully constructed MyRecord. The code above uses reify and actually
creates the array *before* calling reify, so I don't think we need to
worry about calling count with a somehow still being null, either.

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

Twitter: From Ruby On Rails To The JVM + Clojure at Twitter, the new kid on the block

[Alen Ribic]

I thought this would be an interesting video to share with those who
haven't seen it yet.
Raffi Krikorian, the head of the Application Services Group at
Twitter, talks about the move from Ruby on Rails to the JVM. He also
briefly talks about running Clojure at Twitter, the new kid on the
block.

O’Reilly OSCON Java 2011, Raffi Krikorian, “Twitter: From Ruby On
Rails To The JVM”
http://ontwik.com/rails/oreilly-oscon-java-2011-raffi-krikorian-twitter-from-ruby-on-rails-to-the-jvm/

-Alen

--
Science is what you know, philosophy is what you don't know.
-- Bertrand Russell

-- 
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: dynamically generated let bindings

[Ken Wesson]

On Sat, Jul 30, 2011 at 7:29 AM, Sam Aaron  wrote:
>> (fn [& args]
>>  (let [foo (some logic goes here)
>>        bar (some logic goes here)
>>        ...]
>>    (body goes here)))
>
> I just finished implementing a solution and it looks exactly like this. 
> You're absolutely right - this is precisely the pattern I was looking for.
>
> What I didn't do, and I think the biggest lesson I've learned from these 
> early macro-fighting days, is to do exactly what you propose: sketch out what 
> the macro should expand to *before* working on the macro itself.

That's generally good advice when macro-writing.

> Thanks everyone once again,

You're welcome.

-- 
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: dynamically generated let bindings

[Alan Malloy]

On Jul 29, 2:02 pm, Ken Wesson  wrote:
> (fn [& args]
>   (let [argmap__5673__auto (#'some-ns/parse-args args)
>         foo (or (:foo argmap__5673__auto) 42)
>         bar (or (:bar argmap__5673__auto) nil)
>         ...]
>     (body goes here)))
> where you define a private parse-args function in your namespace to
> turn an argument seq into a map of argument name keywords to values,
> with some omissions, and 42 and nil are the defaults which the macro
> builds right into the function.
>
> Of course, this has the slight issue that arguments whose values are
> false or nil will be changed to their defaults. You may need some
> trickier handling, e.g.
>
> (let [...
>       foo (:foo argmap__5673__auto)
>       foo (if (:foo argmap__5673__auto) foo 42)
>       ...]
>   ...)

(get :foo argmap__5673__auto 42) is the right way to solve this
problem.

Or if, as in the current example, you want to destructure a map with
lots of defaults, simply:

(let [{:keys [foo bar] :or {foo 42}} (parse-whatever)]
  ...body...)

>
> or
>
> (let [...
>       foo (find argmap__5673__auto :foo)
>       foo (if foo (val foo) 42)
>       ...]
>   ...)
>
> --
> 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: Clojure 1.3 Beta 1

[Mark Engelberg]

On Fri, Jul 29, 2011 at 10:09 AM, abedra  wrote:
> Can you provide a couple of concrete examples for this?  I will make
> the ticket in JIRA and start working on it, but I am spread thin on
> quite a few things at the moment and these examples will help a lot.
>
> Cheers,
>
> Aaron Bedra

Sure, let me elaborate on what I mean with a short but somewhat
contrived example.

Consider the following definition of factorial:
(defn fact [n]
  (loop [n n result 1]
(if (zero? n) result
(recur (dec n) (* result n)

factorial overflows as soon as you get to (fact 21).  Now, let's say
you don't know exactly at what point factorial overflows.  So to be on
the safe side, the recommended procedure is to pass a bigint to the
factorial function and rely on contagion to make this work, i.e.:
(fact 21N)

The problem is that (fact 21N) in 1.3 is slower than (fact 21) in 1.2.
 We're paying a big performance by relying on contagion.

Here's why:
In Clojure 1.2, the first 20 multiplications are done with longs, and
only when it overflows then the last multiplication is done with
bigints.
In Clojure 1.3, all the multiplications are done with bigints which are slow.

When this issue was first raised back when Rich floated the idea of
primitive ops with bigint contagion, he created the stub class saying
that eventually the plan would be to come up with a better version of
bigint than Java's BigInteger class in the sense that it would reduce
and compute with longs (and maybe ints) when in that range.

Now, factorial is contrived because overflow happens fairly early in
the process, yet the difference is still measurable.  For many of the
statistics I compute in my work project, a substantial number of the
computations happen within the long range, but sometimes they
overflow.  1.3 kills performance for me if I try to leverage
contagion; I must convert everything to the overflow ' operators.

I was thinking about this recently because I was rewriting my
clojure.contrib.math to support 1.3.  One of the things I had to think
about was how the expt function should behave.  It would be most
compatible with 1.3's "outlook" if
(expt primitive-long primitive-long) returned a primitive-long or
generated an overflow error.  But to implement expt in this way, I
also have to think about the fact that for many cases, exponentiation
will overflow.  So what should users do?  One option is I could also
provide a expt' function.  But I ruled this out because then I get
caught up in a proliferation of two versions (regular and ') of nearly
every math function.  It might be feasible to provide a single version
of expt that supports primitive math and then allow users to use
contagion (e.g., (expt 2N 100)), but this contagion will hurt
performance.  So the only viable option I see is to implement expt
with boxed numbers and the *' operator, maintaining the same
performance profile as 1.2, but missing out on the possibility of
making the primitive math people happy.

Does this explanation help?

-- 
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 tracking it down and doing the legwork, Anthony :)

On Thursday, July 28, 2011 5:50:37 PM UTC-6, Anthony Grimes wrote:
>
> Oh! I apologize. I was replying via the google interface and didn't realize 
> it wasn't quoting. Here is a link to the topic for context: 
> https://groups.google.com/d/topic/clojure/ZyVrCxmOFTM/discussion
>
> I've also filed a bug here: http://dev.clojure.org/jira/browse/CLJS-43
>
> Sorry. :)
>
> On Thursday, July 28, 2011 6:40:39 PM UTC-5, Rich Hickey wrote:
>>
>> Could you please use quoting in your messages? Otherwise they have no  
>> context.
>>
>> Thanks,
>>
>> Rich
>>
>> On Jul 28, 2011, at 7:10 PM, Anthony Grimes wrote:
>>
>> > Actually, it seems to be caused by this commit: 
>> https://github.com/clojure/clojurescript/commit/954e8529b1ec814f40af77d6035f90e93a9126ea
>> >
>> > If I checkout before that, everything is peachy. I guess I'll submit  
>> > a bug report.
>> >
>>
>>

-- 
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: dynamically generated let bindings

[Ken Wesson]

On Sat, Jul 30, 2011 at 9:07 PM, Alan Malloy  wrote:
> (get :foo argmap__5673__auto 42) is the right way to solve this
> problem.

Is another way to solve it, yes, and a good one.

> Or if, as in the current example, you want to destructure a map with
> lots of defaults, simply:
>
> (let [{:keys [foo bar] :or {foo 42}} (parse-whatever)]
>  ...body...)

Or

(let [{:keys [foo bar]} (merge {:foo 42} (parse-whatever))]
  ...body...)

The defaults map can be a literal emitted by the macro and must be on
the left of the map-returning (parse-whatever) call.

-- 
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: Alright, fess up, who's unhappy with clojurescript?

[Luc Prefontaine]

On Sat, 30 Jul 2011 11:02:13 -0400
+1

I would add that I want to see Rich maintain is grip on the Clojure wheel for a 
very long time.

Consensual decisions are most of the time not the best. They are the result
of compromises not based on technical arguments but on people's feelings or 
political issues.

I would rather rely on someone who has invested a significant time in evaluating
several options after collecting the maximum input than on loose canons coming 
up with ideas
that do not fit well with Clojure.

Another thing that Rich does very well is to postponed decisions because he 
feels
he did not find the good solution yet and needs to think again about it.
How many of us in our professional life can demonstrate such independence ?
How many told their boss "I am not ready yet to take a decision on this matter" 
?

We have a leader here that has a very good track record decision wise + an 
astounding achievements.

Stop hammering on him and if you are not happy with Clojure, find another 
language
that matches your aspirations. They are plenty out there.

Luc P.


daly  wrote:

> 
> 
> Try to see the situation from the lead developer perspective
> (e.g. Rich's perspective). I have been through the "head-punching",
> as you call it and I don't want to put words in Rich's mouth but
> I do see things differently.
> 
> To lead a project you need to make design choices.
> To make those design choices you have to take a lot of factors
> into account.
> Those factors are optimized based on a lot of considerations,
> most of which are stated in the project goal or justification.
> 
> 
> 
> 
> As you say, "people who do not agree with the choices appear".
> When they do, they generally advocate a particular position that
> is in conflict with the project goals or justification. Or they
> advocate for a new direction that gets rejected.
> 
> These "advocates" are of two varieties. Either they are casual
> contributors (posters to the mailing list) or developers who have
> invested a lot of time and effort going against the goals.
> 
> The "posters" who disagree tend to choose particular topics that 
> they find familiar (e.g. autoconf, eclipse, emacs, maven, etc.).
> These lead to mini-flame wars (head-punching, bike-shedding).
> 
> The developers who disagree tend to choose particular topics that
> they have invested time and effort to develop code. These lead to
> forks.
> 
> In either case, as the lead developer, you constantly have to 
> justify your choices. The design space has a lot of freedom so
> you have to make choices based on your best judgement. Not everyone
> will agree, as you can see. This causes a great deal of stress
> on the lead developer, which you DON'T see. Defending every choice
> from every poster and developer takes a lot of time and effort.
> 
> What is particularly frustrating is the people who ignore your
> effort to communicate. If you justify using Google Closure (as
> Rich has), if you justify leaving out eval (as Rich has), if you
> justify changing certain language features (as Rich has), then
> it seems reasonable to expect that people pay attention to the
> goals and choices. It is very tiring to keep repeating "the choice
> has already been made", especially when code is being written to
> support that choice.
> 
> 
> 
> 
> As you say, "the language matters to them". Of course it does.
> It also matters to Rich. The reason it "matters" is that Rich
> is doing an excellent job navigating the design space based on
> his considerable experience. He is solving deep problems, like
> the expression problem, in novel and creative ways. He is making
> tradeoffs based on a lot of factors (unlike the posters) which
> take into account project goals such as important performance 
> questions.
> 
> Posting emails about "who's unhappy with ..." is not constructive
> criticism. And when it ignores already stated goals or justifications
> it can only result in anger. As a Common Lisper, I see that Rich is
> dancing all over my religious beliefs, but that seems to be my
> problem, not his. If it makes me unhappy that's also my problem.
> Being unhappy with design choices is NOT Rich's problem. So why
> would I use Rich's mailing list to complain?
> 
> While it is fine to say "get involved in head-punching" I think
> it is important to realize that it is Rich's head being punched.
> 
> Tim Daly
> 
> 
> On Sat, 2011-07-30 at 01:26 -0700, Alexander Yakushev wrote:
> > The moment I saw the previous controversial topic - about "yes
> > language" push - I realized that Clojure has become mature. When the
> > people who do not agree with some choices appear not just outside
> > but in the community itself - it means that the language matters to
> > them despite the parts they don't like. Matters enough not to just
> > say "Ah, screw it, I'll just switch to FooLanguage".
> > So, sit back, get involved in head-punching and just enjoy Clojure
> > being a grown-up.
> > 
> 
> 



-- 
Luc P.

=

Re: Libraries and build management hell

[Ken Wesson]

On Sat, Jul 30, 2011 at 10:58 AM, Mark Rathwell  wrote:
>
> I'm all for a better, easier solution that is better in most ways.  What I'm
> saying is:
> 1. I don't want to go back to downloading jar files from the websites of all
> of the libraries I want to use in a project and tracking different versions,
> no matter how large or small the project is, as suggested in your OP.  I
> think the centralized lein/clojars/github is an improvement over that in
> almost every way.

"Almost" being the operative word. One distinct disadvantage is that
it makes building your project require a working network connection
and depends on single points of failure in Clojars and Github. So,
network or site outages can delay your own work. Also, development
under this model would be difficult on a mobile platform (such as a
netbook) whose internet connection is flaky (e.g., up only when there
is a free WiFi hotspot within range) or expensive enough to turn off
most of the time (cellular data networks). (And both WiFi and cellular
are subject to flaky signal strength depending on local conditions,
too.)

> I really think incremental improvements to lein/cake/etc, over time, will
> yield better results than going back to square one.

This is probably true, even given the above issues that can arise with
a build process that presumes reliable 24/7 network connectivity.

-- 
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: Alright, fess up, who's unhappy with clojurescript?

[Ken Wesson]

On Sat, Jul 30, 2011 at 10:22 PM, Luc Prefontaine
 wrote:
> I would add that I want to see Rich maintain is grip on the Clojure wheel for 
> a very long time.
>
> Consensual decisions are most of the time not the best. They are the result
> of compromises not based on technical arguments but on people's feelings or 
> political issues.

And the result of them tends most often to be something like Java at
best, and often closer to C++.

> Stop hammering on him and if you are not happy with Clojure, find another 
> language
> that matches your aspirations. They are plenty out there.

There is something of an issue here, though: where, exactly, should
the line be drawn between "thou shalt not question this on the mailing
list!" and "fair game for discussion", presuming as you do that it
isn't "everything is fair game for discussion if it's not entirely
unrelated to Clojure". You seem to feel that major, already-made
design decisions that would require a fork and massive effort to do
differently lie on the "shalt not question" side. What about more
minor choices -- for example, which of the three kinds of primitive
math overflow behaviors, throwing, auto-promoting, or wrap-around,
should be the default? I assume not-yet-made choices and
easily-tweaked, recentish (still in alpha or beta) things that won't
break a lot of existing code fall under "fair game".

Also, what should the policy be for responding if someone questions a
"shalt not question" anyway? Currently, there's an unfortunate
tendency to assume the worst motives and to employ namecalling,
particularly the word "troll", against possibly-well-intentioned
transgressors. I'd suggest that such threads should get a single
response, saying "that decision's already been made; if you want to
make your own fork that does it differently go ahead, and if you want
to discuss it there's the clojure-misc google group, but please don't
clutter *this* group with it", and otherwise the post should be
ignored. Followups by the OP should be ignored. Oh, and there should
probably be a pointer to a FAQ of some sort in that initial response
answering any likely "but why?" type questions the OP might have,
including "what other topics will bring this kind of response?".

-- 
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: Clojurescript - Javascript constructor and namespace with the same name problem

[Chris Granger]

FWIW, one work around for this is to include the sub-namespace as well
and reference it from that one. So in your example:

(ns notepad
  (:require
 [goog.dom :as dom]
 [goog.ui :as ui]
 [goog.ui.Zippy :as Zippy]))

(ui/Zippy. "ttt" "sss")


On Jul 28, 7:41 am, Marko Kocić  wrote:
> Hi all,
>
> When dealing with ClojureScript and Closure library it happens pretty often
> that Closure namespace is in the same time constructor for some object.
>
> Take a look for this example:
>
> (ns notepad
>   (:require
>      [goog.dom :as dom]
>      [goog.ui.Zippy :as Zippy]))
>
> First, require forces me to require goog.ui.Zippy as Zippy and later in the
> code I have to use fully qualified name instead of provided one.
>
> This works
> (goog.ui.Zippy. headerElement contentElement)
>
> This doesn't work, since Zippy is namespace declaration
> (Zippy. headerElement contentElement)
>
> I know that we can't have both namespace and function with the same name,
> but this is pretty frequent situation in Closure library, and is a bit
> awkward.
> One solution would be that namespace :as symbol is specialcased so that
> without namespace prefix Zippy and Zippy. works like a regular function, and
> when in place of namespace prefix, it works as a namespace prefix. That
> would be pretty in line with Closure library itselfi.
>
> Then we would be able to use
> (require [goog.ui.Zippy :as Zippy])
> (def z (Zippy. "ttt" "sss")) ;; same as calls goog.ui.Zippy.
> (Zippy/someMethod x) ;; same as goog.ui.Zippy
>
> What would be your proposal for 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: Libraries and build management hell

[Sean Corfield]

On Sat, Jul 30, 2011 at 5:27 PM, Mark Engelberg
 wrote:
> I guess what I'm
> thinking of is that 95% of the time when I go to start something new,
> it ends up being for a short-lived task

Sounds like both Phil and I tackle that by having one or more scratch
projects that we just add new dependencies to as needed. Anything that
becomes longer-lived is "promoted" into its own project if/when it
makes sense.

> I'm not sure how well that would work
> with the way I have things organized, and with my source control, but
> it's something I can look into.

I guess our definitions of "one-off" might be different? If I'm just
doing a one-off experiment in the REPL, it's not likely to end up
under version control. If it's long-lived enough to go under version
control, it's probably worth a project :)

I definitely agree that compared to certain scripting languages,
there's more ceremony with Clojure (or any other JVM language) because
you can't just drop a source file in any old folder and run it. If you
don't mind a compilation step, ClojureScript -> JavaScript and then
running it with Node.js allows you to have scripts "anywhere" and
easily run them...
-- 
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