Re: Libraries and build management hell

[Michal B]

Leiningen definitely alleviates the hairiness of library management. But I 
wish people won't settle for a lein like solution for simple projects. As 
much as it helps, it is still an unnecessary burden and an obstacle to 
adoption, in my opinion and experience.

-- 
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: Code structure/design problems

[msappler]

Yes. This game was me starting to learn clojure a year ago and I just
made it sequential. So I used atoms :)

So for making it run in parallel I would have to change the atoms to
refs.

For example movement-update would need to synchronize the grid-cells
and the position of an entity as one atomic action.



On Jul 29, 8:50 am, Laurent PETIT  wrote:
> Hi,
>
> 2011/7/29 msappler 
>
> > I am also developing a clojure rpg and have open sourced the last
> > alpha version:
>
> >https://code.google.com/p/clojure-rpg/
>
> > ~
>
> > Basically I am using an atom for every entity in the game (monster,
> > player, projectiles, explosions...) and for every cell in the grid of
> > the map.
>
> Without too much thinking about it, I would have thought monsters, players,
> etc. need to be changed in a same "transaction", so would have by default
> implemented them as refs instead of atoms.
>
> Could you elaborate more on the choice of atoms as design decisions ?
>
>
>
>
>
>
>
>
>
> > There are a lot of functions with many side-effects like deal-damage
> > for example:
>
> >https://code.google.com/p/clojure-rpg/source/browse/trunk/src/game/co...
>
> > ---
> >  I use also pure functions for example when applying item boni:
>
> >https://code.google.com/p/clojure-rpg/source/browse/trunk/src/game/it...
>
> > For example an item has 3 boni: movement, +damage, +hp then I update
> > the state and apply the three pure functions on the entity.
>
> > --
> > 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: Are they scared of us yet?

[Ken Wesson]

On Fri, Jul 29, 2011 at 2:48 AM, Laurent PETIT  wrote:
> So they decided to go the route of adding a .getSuppressed() (Exceptions)
> method in Throwable, thus behaving differently from other finally clauses
> ...
>
> ... so now we have a (with-open) whose semantics are not aligned with those
> semantics of Java 7' try-with-resources statement, wrt exception shadowing
> from the "finally" block ... :-/

Easily fixed. We already wrap everything in RuntimeException, right?
And it's already been suggested elsewhere that we should probably use
a specialized subclass, say ClojureRuntimeException.

So, just implement ClojureRuntimeException, add some fields and
getShadowed and appendShadowed methods to this, and redefine with-open
so that it catches any exception, stuffs it into a
ClojureRuntimeException as the cause exception if it's not already a
ClojureRuntimeException, and now it's holding a
ClojureRuntimeException, closes open resources and appends any thrown
exceptions to the ClojureRuntimeException's shadowed list. Then throws
that. For one resource, something like this should be emitted:

(let [x the-resource]
  (try
... body that works with x ...
(catch Throwable t
  (let [t (if (instance? ClojureRuntimeException t)
t
(ClojureRuntimeException. (.getMessage t) t))]
(try
  (.close x)
  (catch Throwable tt (.appendShadowed t tt)))
(throw t
  (.close x))

There's a couple of tiny leaks (.getMessage could throw something, and
(ClojureRuntimeException. ...) could throw OOME, plus the
infinitesimal chance of a random VMError cropping up) but it looks
solid enough for production use and gives Java 7ish semantics.

The exception wrapping code elsewhere can do something similar in
terms of wrapping in ClojureRuntimeException and only if it's not
already wrapped. It'd be nice to be able to differentiate wrapped
exceptions from "natural" RuntimeExceptions, and not to have the same
one get rewrapped umpteen times so that you have a cause chain of half
a dozen RuntimeExceptions before the cause exception.

Then we can also have

(defn unwrap [x]
  (if (instance? ClojureRuntimeException x)
(recur (.getCause x))
x))

and it will unwrap all Clojure's wrapping, and stop right there even
if the exception originally caught and wrapped inside Clojure already
had a cause exception.

-- 
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: format and printf can't be used with BigInt

[Sean Corfield]

On Thu, Jul 28, 2011 at 10:52 PM, Meikel Brandmeyer (kotarak)
 wrote:
> I think this is one of the misunderstandings or points of disagreements (or
> whatever you want to name it) in this whole discussion: this code is *not*
> broken.

Code that runs on 1.2 but throws an exception on 1.3 is "broken" on
1.3 by definition. The fact that it can be easily "unbroken" is good
to know but it still means working code can stop working if you move
from Clojure 1.2 to 1.3. That's what I mean by 1.3 "breaks" code.

Some people are more upset by this than others (I'm not upset by it at
all, just for the record - I think the decision is the right one for
the future of Clojure).

Besides, after what I (and many others) experienced in the Scala 2.7 /
2.8 upgrade, the incompatibilities between Clojure 1.2 and 1.3 are
positively minor by 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)

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

On 29 Jul 2011, at 07:22, Ken Wesson wrote:

> On Fri, Jul 29, 2011 at 12:49 AM, Jeff Rose  wrote:
>> I don't think it's very typical to pass a form to a function, unless
>> you plan on using eval at runtime.
> 
> Or it's a function called by a macro to do some processing of forms.

Yep, this is precisely what I was considering. I should have explicitly made 
mk-dynamically-bound-fn a macro in my example - a miscommunication on my part.


On 29 Jul 2011, at 02:12, Alan Malloy wrote:

> 
> It's not clear how much of this is relevant to your actual problem, vs
> the simple version you're posting here. 

Sorry, I was just trying to simplify things to try and get directly to the meat 
of the problem. 

> If you want something more general, that implicitly binds things for
> you based on some code somewhere else (ew ew ew), then you need a
> macro. This implementation is pretty gross; I suspect it could be
> better, but you're trying to do something that seems weird to me.
> 
> (defn binding-vec []
>  ['size '(count args)])
> 
> (defmacro magic-fn
>  [& forms]
>  `(fn [& ~'args]
> (let ~(binding-vec)
>   ~@forms)))
> 
> 
> user> ((magic-fn (+ size 10)) 1 2)
> 12

Very cool, although it's not quite what I'd like. I'd like binding-vec to be a 
function of the resulting magic-fn's args. 

I'm aiming for something like this, but can't get it to quite work:

(defn binding-vec [foos]
  '[size (count ~foos)])

(defmacro magic-fn
 [& forms]
 `(fn [& ~'args]
(let ~(binding-vec ~'args)
  ~@forms)))

((magic-fn (+ size 10)) 1 2) ;=> BOOM

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

[Sam Aaron]

On 29 Jul 2011, at 00:46, Kent wrote:

> I'm not sure what you're trying to do with this and, based on that
> ignorance, I'm not sure I think it's a great idea. Maybe you are being
> a bit crazy, and maybe your a genius.  Who am I to say?
> 
> Here is a function that does what you want.  The only difference is
> that my function also takes the "binding-vec" function as an argument.
> 
> 
> (defn mdbf [form binding-func]
>  (fn [& args]
>(eval `(let ~(binding-func args) ~form
> 
> Here it is used in your example.
> 
> (defn binding-vec
>  [args]
>   ['size (count args)]
> 
> (def a (mdbf '(+ size 10) binding-vec))
> 
> (a 1 2 3 4) => 14


Very nice, thanks for this. However, using eval feels a bit too scary even for 
a crazy guy like myself!

Perhaps I need to take a different angle to solving my problem…

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

[Alan Malloy]

On Jul 29, 1:49 am, Sam Aaron  wrote:
> On 29 Jul 2011, at 07:22, Ken Wesson wrote:
>
> > On Fri, Jul 29, 2011 at 12:49 AM, Jeff Rose  wrote:
> >> I don't think it's very typical to pass a form to a function, unless
> >> you plan on using eval at runtime.
>
> > Or it's a function called by a macro to do some processing of forms.
>
> Yep, this is precisely what I was considering. I should have explicitly made 
> mk-dynamically-bound-fn a macro in my example - a miscommunication on my part.
>
> On 29 Jul 2011, at 02:12, Alan Malloy wrote:
>
>
>
> > It's not clear how much of this is relevant to your actual problem, vs
> > the simple version you're posting here.
>
> Sorry, I was just trying to simplify things to try and get directly to the 
> meat of the problem.

No apologies needed - reducing to a simple case is great. But here,
the simplification was probably too severe.

> > If you want something more general, that implicitly binds things for
> > you based on some code somewhere else (ew ew ew), then you need a
> > macro. This implementation is pretty gross; I suspect it could be
> > better, but you're trying to do something that seems weird to me.
>
> > (defn binding-vec []
> >  ['size '(count args)])
>
> > (defmacro magic-fn
> >  [& forms]
> >  `(fn [& ~'args]
> >     (let ~(binding-vec)
> >       ~@forms)))
>
> > user> ((magic-fn (+ size 10)) 1 2)
> > 12
>
> Very cool, although it's not quite what I'd like. I'd like binding-vec to be 
> a function of the resulting magic-fn's args.
>
> I'm aiming for something like this, but can't get it to quite work:
>
> (defn binding-vec [foos]
>   '[size (count ~foos)])
>
> (defmacro magic-fn
>  [& forms]
>  `(fn [& ~'args]
>     (let ~(binding-vec ~'args)
>       ~@forms)))
>
> ((magic-fn (+ size 10)) 1 2) ;=> BOOM

(defn binding-vec [foos]
  ['size `(count ~foos)])

(defmacro magic-fn
  [& forms]
  (let [args (gensym 'args)]
`(fn [& ~args]
   (let ~(binding-vec args)
 ~@forms

((magic-fn (+ size 10)) 1 2) ;=> 12

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

On 29 Jul 2011, at 10:05, Alan Malloy wrote:
>> 
>> Sorry, I was just trying to simplify things to try and get directly to the 
>> meat of the problem.
> 
> No apologies needed - reducing to a simple case is great. But here,
> the simplification was probably too severe.
> 

Sorry, I'm English - apologies are just part of normal discourse ;-)

> 
> (defn binding-vec [foos]
>  ['size `(count ~foos)])
> 
> (defmacro magic-fn
>  [& forms]
>  (let [args (gensym 'args)]
>`(fn [& ~args]
>   (let ~(binding-vec args)
> ~@forms
> 
> ((magic-fn (+ size 10)) 1 2) ;=> 12
> 


Fantastic! I believe this is exactly what I'm looking for. Thank-you so much.

Out of interest, are you able to briefly describe (or able to direct me at some 
relevant literature that does) why your original solution used ~'args and why 
this version uses (gensym 'args). These subtle macro compile-time/runtime 
syntax tricks are something I'm clearly yet to master.

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

[Davi Santos]

Hello,
I am absolutely new to Clojure and Intellij.
I just installed the La Clojure plugin and everything is working.
This has been relevant in my decision of which JVM functional language to
use.

Maybe the over-engineering is indirect Haskell influence (despite being ML
descendant):
you have to learn a whole world to do a simple program (cabal, hackage, ghc
...).

I don't understand what the Leiningen Intellij plugin is for.
And I hope I don't need to.

Davi

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

[josh rotenberg]

On Thu, Jul 28, 2011 at 2:23 PM, Michal B  wrote:
> Why does it have to be so complicated to use libraries?

Heh. My current project is C/C++, and we are using gnu autotools for
the build. A few dependencies use pkgconfig, some have m4 macros (that
are out of date), one has its own backtick-config kind of thing, and
another has no real handy way to find its dependencies. In addition,
to get everything to play nice via unit tests takes our own fragile
voodoo. So for me, right now Leiningen, clojars, and even cloning
something from github is basically nirvana.

Josh

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

Question regarding structural sharing, records, and maps

[Trenton Strong]

Hi all, this is my first post.

I'm currently building a tree data structure (quadtree to be exact)
while doing some exploratory game server programming using Clojure.
This tree will end up with a lot of "entities" stored in the nodes,
whose positions determine which node they end up in.  As game state
progresses, updates will come from player and AI controlled entities
which need to be reflected in the tree.

Since player updates will come from any number of external clients,
the tree will need some form of concurrency management.  So far, I
have settled on just using a single ref wrapping the root node of the
tree with all update functions acting on that ref via dosync.

My question is one of implementation, as I don't yet have a good
feeling how different approaches to storing data will affect memory
usage and performance in the long run and I'm trying to better my
intuition for designing applications with Clojure.  I am currently
using maps to represent the nodes of the tree, with the hypothesis
being that new versions of the tree will save memory and do less
thrashing this way.  I'm aware that Clojure's persistent data
structures have some method of structural sharing between different
states of the same identity, which is what leads me to that guess.  I
haven't found anything that conclusively says that structures defined
with defrecord do not perform this sort of sharing, but from what I
can tell it seems like they do not, which makes sense given that they
provide accessors and expose a Java class.

So, some trade-off questions would be:

1.) Does structural sharing play well with nested structures? With a
tree whose nodes are represented by nested maps, if a leaf node is
updated with new data, will structural sharing efficiently represent
the new version of the tree as "all the rest of the tree" + modified
node?

2.) If one were to use nested records instead, I assume producing a
new version of the tree will result in a cloning operation over the
nodes of the tree, less the nodes we are modifying ourselves.  If
updates were being performed very frequently, is there a possibility
of adverse interaction with a GC?  I know that GC implementations
differ, but it seems like this could put a lot of pressure on a
typical GC.

3.) Are there alternatives to a single ref around the root node of the
tree that are worth exploring?  I've considered wrapping each node in
a ref and performing updates that way, or possibly taking the async
route and dispatching cals using agents, but my experience there is
nil.  Any insight there?

As an aside, I am not looking for specific answers as without numbers
or hard data there really can't be any right now.  I will end up
measuring the performance of these approaches, but I do want to have
some understanding of how the variables are related when trying to
understand the empirical data.

Thanks,

Trent


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

On 29 Jul 2011, at 10:05, Alan Malloy wrote:
> 
> (defn binding-vec [foos]
>  ['size `(count ~foos)])
> 
> (defmacro magic-fn
>  [& forms]
>  (let [args (gensym 'args)]
>`(fn [& ~args]
>   (let ~(binding-vec args)
> ~@forms
> 
> ((magic-fn (+ size 10)) 1 2) ;=> 12

Actually, sadly, this still quite doesn't do what I want - and definitely 
highlights the perils of over-simplifying the question!

I'd like binding-vec to generate the binding vector entirely from foos, i.e. 
both the binding name and value. Imagine that there's a var names:

(def names ['size 'foo 'bar 'baz])

To continue in the context of the (over-simplified) question, I'd like 
binding-vec to dynamically generate me a vec of:

['size `(count ~foos)
 'foo  `(count ~foos)
 'bar  `(count ~foos)
 'baz  `(count ~foos)]

However, something like the following doesn't work:

(defn binding-vec [foos]
  `(vec (interleave ~names ~(take (count names) (repeat '`(count ~foos))

A, because the above code is probably incorrect (I just cobbled it together for 
the example) and more importantly:
B, because the code doesn't return a vec, it returns code that returns a vec. 

I really seem to be getting my brain in a knot over this. :-( Any illumination 
would be really appreciated


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

[Ken Wesson]

On Fri, Jul 29, 2011 at 6:57 AM, Sam Aaron  wrote:
> However, something like the following doesn't work:
>
> (defn binding-vec [foos]
>  `(vec (interleave ~names ~(take (count names) (repeat '`(count ~foos))
>
> A, because the above code is probably incorrect (I just cobbled it together 
> for the example) and more importantly:
> B, because the code doesn't return a vec, it returns code that returns a vec.
>
> I really seem to be getting my brain in a knot over this. :-( Any 
> illumination would be really appreciated

Why not just (vec (interleave names (take (count names) (repeat
`(count ~foos)?

Of course I assume you eventually want something more complex than
just (count foos) as the value for every variable, or why have more
than one variable?

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

[Sam Aaron]

On 29 Jul 2011, at 12:11, Ken Wesson wrote:
> 
> Why not just (vec (interleave names (take (count names) (repeat
> `(count ~foos)?
> 

That seems to blow up:


(defn binding-vec [foos]
  (vec (interleave names (take (count names) (repeat `(count ~foos))

(defmacro magic-fn
 [& forms]
 (let [args (gensym 'args)]
   `(fn [& ~args]
  (let ~(binding-vec args)
~@forms

((magic-fn (+ size 10)) 1 2) ;=> 12


> Of course I assume you eventually want something more complex than
> just (count foos) as the value for every variable, or why have more
> than one variable?

Yes, of course :-)

The actual end goal is to be able to define a macro (or whatever) passing in a 
body containing symbols which are yet to be defined. The macro will then return 
me function which has variable arity. When I call this function I'd like the 
values of the args be bound to a specified list of symbols (which happen to be 
the arg names) so that the original body can execute correctly. The interesting 
part is that I'd like to be able to specify defaults interleaved with the arg 
names. 

For example:

(def yo (with-arg-params [foo 0 bar 1 baz 2]
(+ foo bar baz)

a would now be bound to a fn which I could call:

(yo 1 2 3) ;=> 6

I could also call it with fewer args than expected:

(yo 1 2) ;=> 5

this works because bad has a default of 2.

There's a bunch of other neat tricks I can do here which would probably only 
serve to complicate this example, but this is the general gist of things.

I assume for this to work I have to dynamically create a let binding over the 
original form, so the first call would execute code like:

(let [foo 1 bar 2 baz 3] (+ foo bar baz))

and the second example would execute code like:

(let [foo 1 bar 2 baz 2] (+ foo bar baz)

this would therefore mean that this let statement's vec needs to be a function 
of the args passed to yo and the initial set of defaults.  Unfortunately I'm 
currently unable to figure out how to achieve this.

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: Question regarding structural sharing, records, and maps

[Ken Wesson]

On Thu, Jul 28, 2011 at 11:59 PM, Trenton Strong
 wrote:
> 1.) Does structural sharing play well with nested structures? With a
> tree whose nodes are represented by nested maps, if a leaf node is
> updated with new data, will structural sharing efficiently represent
> the new version of the tree as "all the rest of the tree" + modified
> node?

Yes. In fact this should work with records, too -- all the "native"
fields of the record need to be copied for each version, but most will
typically be pointers and most of those will typically be to existing
objects. Only the ones that were changed will point to new nested
objects. So unless your records have huge numbers of predefined fields
there shouldn't be much time or memory cost in copying them.

> 3.) Are there alternatives to a single ref around the root node of the
> tree that are worth exploring?

Probably. Any two changes to the tree will cause one to retry in the
single-ref case, unless you're sure all the changes will commute.
(Changes to distinct fields where one change doesn't depend on what
the other changes will commute, and changes to the same field that
don't matter as to sequencing, such as inc and dec, will commute, but
otherwise no.)

You will probably want something structured more like a database, with
"tables" that are maps and "rows" that are records or more complex,
nested structures, such that most concurrent changes will not affect a
common row. The "tables" can then be refs of maps of refs, with most
changes operating on the row-refs. The table refs only need to change
if rows are inserted or deleted; those could be bottlenecks, though if
all objects have GUIDs as keys in these tables then row insertions and
deletions will commute, leaving only the GUID generators for each
table.

Unfortunately, (let [new-id (commute table-x-guid-counter inc)])
sounds nice but might result in new-id taking on the same value in two
concurrent transactions, so you'll need to use alter and GUID
generation may be a bottleneck. But it may be much faster than your
other, more complex transactions. Be sure to do it separately, e.g.:

(let [new-id (dosync (alter table-x-guid-counter inc))]
  (dosync
(commute table-x assoc new-id some-thingy)))

You can even use atoms for the guid counters instead of refs, and then
the ! in swap! will remind you to get the ID before entering a
transaction. Do as much of what's needed to generate some-thingy
before the transaction, too -- though if it depends on other refs'
values, and those values should be current rather than it being
acceptable for them to be values that were there recently but might
have changed, then some of the work will need to be done in the
transaction.

> I've considered wrapping each node in
> a ref and performing updates that way, or possibly taking the async
> route and dispatching cals using agents, but my experience there is
> nil.  Any insight there?

I'd avoid having refs nesting more than two deep. Complex arrangements
of cross-references among nodes can create a giant headache in
combination with refs and transactions, so using a "database" approach
with "table" maps, ID token keys, and cross-references to ID tokens
rather than objects is often sensible. In particular, complex objects
with nested refs effectively have mutable state inside them, which is
usually not desired in Clojure. (One can argue, though, that the ref
object is not different in principle from the ID token and removes a
layer of indirection, and possibly obviates the need to generate IDs
from counters that act as bottlenecks -- though, really, the Java new
operator's allocation of memory now takes the role of ID generator.
I'm given to understand modern VMs do some clever things to make new
able to be fairly concurrent, though, such as giving each thread its
own subset of the eden generation to allocate in.)

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

ClojureQL: consistent select queries?

[László Török]

Hi,

is there a way to execute multiple select queries on a table using clojureql
in a transaction?

sg. like

   (with-results [res1 query1
res2 query2]
   .. do sg)

and res1 and res2 would be taken from a same consistent snapshot.

p.s. by looking at lau's repository it's not currently possible, maybe one
of the forks?



-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

-- 
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 Fri, Jul 29, 2011 at 7:35 AM, Sam Aaron  wrote:
>
> On 29 Jul 2011, at 12:11, Ken Wesson wrote:
>>
>> Why not just (vec (interleave names (take (count names) (repeat
>> `(count ~foos)?
>>
>
> That seems to blow up

How so?

> The actual end goal is to be able to define a macro (or whatever) passing in 
> a body containing symbols which are yet to be defined. The macro will then 
> return me function which has variable arity. When I call this function I'd 
> like the values of the args be bound to a specified list of symbols (which 
> happen to be the arg names) so that the original body can execute correctly. 
> The interesting part is that I'd like to be able to specify defaults 
> interleaved with the arg names.
>
> For example:
>
> (def yo (with-arg-params [foo 0 bar 1 baz 2]
>    (+ foo bar baz)
>
> a would now be bound to a fn which I could call:
>
> (yo 1 2 3) ;=> 6
>
> I could also call it with fewer args than expected:
>
> (yo 1 2) ;=> 5
>
> this works because bad has a default of 2.

(defmacro with-arg-params [bindings & body]
  (let [bindings (apply array-map bindings)]
`(fn
  ~@(for [i (range (inc (count bindings)))]
  `(~(vec (take i (keys bindings)))
 (let ~(vec (mapcat identity (drop i bindings)))
   ~@body))

=> (def x (with-arg-params [foo 1 bar 2 baz 3] (+ foo bar baz)))
#'user/x
=> (x 4 5 6)
15
=> (x 4 5)
12
=> (x 4)
9
=> (x)
6

=> (macroexpand-1 '(with-arg-params [foo 1 bar 2 baz 3] (+ foo bar baz)))
(clojure.core/fn ([] (clojure.core/let [foo 1 bar 2 baz 3] (+ foo bar
baz))) ([foo] (clojure.core/let [bar 2 baz 3] (+ foo bar baz))) ([foo
bar] (clojure.core/let [baz 3] (+ foo bar baz))) ([foo bar baz]
(clojure.core/let [] (+ foo bar baz

=

(fn
  ([] (let [foo 1 bar 2 baz 3] (+ foo bar baz)))
  ([foo] (let [bar 2 baz 3] (+ foo bar baz)))
  ([foo bar] (let [baz 3] (+ foo bar baz)))
  ([foo bar baz] (let [] (+ foo bar baz

Note that array-map cannot be changed to hash-map here because the
order must be preserved.

-- 
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: ClojureQL: consistent select queries?

[Ken Wesson]

On Fri, Jul 29, 2011 at 7:41 AM, László Török  wrote:
> Hi,
>
> is there a way to execute multiple select queries on a table using clojureql
> in a transaction?
>
> sg. like
>
>    (with-results [res1 query1
>     res2 query2]
>    .. do sg)
>
> and res1 and res2 would be taken from a same consistent snapshot.

If you run two separate queries, I expect the database server will see
them as two separate transactions, and may interleave some other,
mutating transaction between them, so they won't in that case be taken
from a consistent snapshot.

You'd need to have a single query to the DB, which will run as a
single transaction, generate both res1 and res2. I'm not sure if that
will always be possible; my SQL-fu is a little rusty.

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

Good book on migrating from (Java) OO to FP

[Colin Yates]

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

Re: ClojureQL: consistent select queries?

[László Török]

Hi

2011/7/29 Ken Wesson 

> On Fri, Jul 29, 2011 at 7:41 AM, László Török  wrote:
> > Hi,
> >
> > is there a way to execute multiple select queries on a table using
> clojureql
> > in a transaction?
> >
> > sg. like
> >
> >(with-results [res1 query1
> > res2 query2]
> >.. do sg)
> >
> > and res1 and res2 would be taken from a same consistent snapshot.
>
> If you run two separate queries, I expect the database server will see
> them as two separate transactions, and may interleave some other,
> mutating transaction between them, so they won't in that case be taken
> from a consistent snapshot.
>
> You'd need to have a single query to the DB, which will run as a
> single transaction, generate both res1 and res2. I'm not sure if that
> will always be possible; my SQL-fu is a little rusty.
>

Thanks, I mean I know how to do it with raw sql, was just wondering how to
do it with clojureql, if possible at all.

I'll probably resort to clojure.contrib.sql for now.



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




-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

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

[Alex Osborne]

Michal B  writes:

> To use libraries, you need to learn how to operate half a dozen build
> tools and git because each library author distributes their library
> differently. 

There is a simple de facto standard, which in typical Clojure-style
we've inherited from the Java community for the sake of
interoperability.  Library authors publish a jar file (which is just a
zip of the Clojure source code) to a HTTP repository which has a
directory structure following the Maven repository conventions.

People don't necessarily have to use Maven, often they use Leiningen or
Cake and sometimes they don't use a build tool at all.  You can
certainly do it by hand or with a shell script easily enough.

A popular repository for open source community libraries is Clojars,
although some projects like to host their own or use Maven Central.

Often companies will have an internal repository which could just be
on a directory on a network share somewhere.  Some use repository
software like Nexus or a local instance of the Clojars webapp, but
that's strictly optional.

> If figuring out how to install an IDE with clojure wasn't bad enough,
> now you need to figure out how to install and use each of the tools
> with it.

No you don't.  Let's suppose we want to add the robert.hooke library to
our project without any build tools.

1. Goto http://clojars.org/.

2. Click "browse the repository" (down the bottom).

3. Click "robert".

4. Click "hooke".

5. Click "1.1.2".

6. Click "hooke-1.1.2.jar" and save the jar file to your project.

The repository is really nothing more than a bunch of directories
each containing a jar files and another file containing a list of
dependencies.  I'm not sure how you could make it any simpler.

Admittedly Clojars' is not perfectly user-friendly and the search and
browse could do with improving.  I'm not currently motivated to do this
work myself (due to lack of time, UI design not being my passion and
that it's currently "good enough" for me personally to live with) but
the code is open source and I'm happy to take patches that do so.

I'm actually kind of hoping that eventually someone with time and vision
will come along and slowly take it over.  I created Clojars to scratch
an itch: I was just really unhappy with the existing options.  I
maintain it in the sense of keeping it running, but it really is pretty
neglected.

I really hate thinking about build tools and dependencies, I just want
them to work and get out of my way.  Unfortunately that means at work I
often end up being the "build/deployment guy" just because I'm the
first one to gets sufficiently annoyed to go and do something about it.

> Instead of having a complicated installation guide for your library,
> have a Download section in your site. Have there a link to the latest
> stable version of your library as a jar file or, if necessary, a zip
> file with your jar and and all the necessary dependency jars (sane
> library authors won't mind). For a zip, shortly describe what's in it
> - library names and versions, and links to their sites. That's it.

This actually is exactly how most Clojure libraries were distributed
before the creation of Leiningen.  Maven of course existed and some
people who had a strong Java background were using it but many were
quickly put off by its verbosity, steep learning curve, poor
documentation and lack of transparency.

So what you describe is exactly what you'd get: ad-hoc heterogeneously
structured downloads with an accompanying zip or tarball full of jar
dependencies if you were lucky.

Said zip files could vary wildly, but could contain something like:

clojure.jar
contrib.jar
clj-http-2011.jar

Too bad if you want to know what version a dependency is.  Often the
clojure and contrib jars were just some random snapshot of SVN (this was
before the move to Github).  Maybe the library author even modified them
themselves so they didn't match a mainline version at all.

Even for small projects I would argue this is not simpler, it's more
complicated.

Now you could argue that it would be quite handy for people who want to
avoid tools and configuration files if there was a web site that
automatically generated a zip containing a jar and all of its
dependencies for download in one go.  I can see myself using such a
thing from time to time but not for my primary programming.

There are some minor security and legal issues (eg license
compatibility), but I would be happy take a patch to Clojars that added
or integrated with it.  It really is just moving the dependency
management tool from being client-side to server-side though.

> Instead of managing libraries inside a dependencies file, you do it
> directly with the jar files. If the project gets too big, bring in the
> build tools.
>
> What are your thoughts on this issue?

I think automated dependency management is a necessary evil unless you
basically don't reuse code.  I don't particularly like dependency
management.  I don't partic

Re: protocols and records -- use when?

[Alex Osborne]

Jeff Heon  writes:

> I'm puzzled when we say that Clojure is not particularly OO, but using
> protocols and datatypes feel OO to me,
> except that the namespace of the protocol method implementations is
> decoupled from the namespace of the type.
>
> Perhaps my definition of OO is too loose and I should think of
> protocols as "just" abstraction & polymorphism.

When people use the term OO they usually specifically mean traditional
imperative class-based OO as implemented by popular languages like Java
and C++.  They might also count imperative prototype-based OO like
JavaScript.

To quote the Wikipedia page on OOP:

Benjamin C. Pierce and some other researchers view as futile any
attempt to distill OOP to a minimal set of features. He nonetheless
identifies fundamental features that support the OOP programming
style in most object-oriented languages:

* Dynamic dispatch
* Encapsulation
* Subtype polymorphism
* Object inheritance
* Open recursion

Clojure has some of those features, but it is sufficiently different
from the traditional model that I would consider "not particularly OO" a
valid, if not particularly useful description.  There are certainly
similarities though, after all Clojure tries to solve similar problems.

If you consider idiomatic Clojure code to be strongly OO then you would
definitely have to classify idiomatic Haskell and maybe even idiomatic
Scheme similarly.  In which case the distinction starts to become not
very useful and basically just devolves to "has some sort of
user-definable data type system" and there are very few general-purpose
programming languages which lack one.

-- 
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.command-line

[octopusgrabbus]

On Jul 28, 7:24 pm, Anthony Grimes  wrote:
> command-line is deprecated in favor of tools.cli 
> now.http://github.com/clojure/tools.cli

Where is the repository located?

(ns addr-verify
  (:gen-class)
  (:require [clojure.tools.cli :only (cli optional)])
 .
 .
 .
results in this error:

 clojure.lang.Compiler$CompilerException:
java.io.FileNotFoundException: Could not locate clojure/tools/
cli__init.class or clojure/tools/cli.clj on classpath:

-- 
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: protocols and records -- use when?

[Jeff Heon]

Thanks for the clarification. I see I was mixing up various concepts
in my head.

On Jul 29, 8:19 am, Alex Osborne  wrote:
> Clojure has some of those features, but it is sufficiently different
> from the traditional model that I would consider "not particularly OO" a
> valid, if not particularly useful description.  There are certainly
> similarities though, after all Clojure tries to solve similar problems.

-- 
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: protocols and records -- use when?

[Oskar]

Thank you everyone. I now have a much better understanding of
protocols aed records. This video helped too http://vimeo.com/11236603

On Jul 29, 3:01 pm, Jeff Heon  wrote:
> Thanks for the clarification. I see I was mixing up various concepts
> in my head.
>
> On Jul 29, 8:19 am, Alex Osborne  wrote:
>
>
>
>
>
>
>
> > Clojure has some of those features, but it is sufficiently different
> > from the traditional model that I would consider "not particularly OO" a
> > valid, if not particularly useful description.  There are certainly
> > similarities though, after all Clojure tries to solve similar problems.

-- 
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.command-line

[gaz jones]

it lives on github: http://github.com/clojure/tools.cli
like all the new contrib libs, to use it in a project you need to add
it to your dependencies:

:dependencies [[org.clojure/clojure "1.2.1"]
  [org.clojure/tools.cli "0.1.0"]]


On Fri, Jul 29, 2011 at 7:56 AM, octopusgrabbus
 wrote:
>
>
> On Jul 28, 7:24 pm, Anthony Grimes  wrote:
>> command-line is deprecated in favor of tools.cli 
>> now.http://github.com/clojure/tools.cli
>
> Where is the repository located?
>
> (ns addr-verify
>  (:gen-class)
>  (:require [clojure.tools.cli :only (cli optional)])
>  .
>  .
>  .
> results in this error:
>
>  clojure.lang.Compiler$CompilerException:
> java.io.FileNotFoundException: Could not locate clojure/tools/
> cli__init.class or clojure/tools/cli.clj on classpath:
>
> --
> 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.command-line

[gaz jones]

> Well, README and tests are very good.
> I withdrew into REPL and overlooked them stupidly. I'm very sorry.
>

no worries, glad they help.

> BTW some functions seems not to be public API though they are public.
> Why they are not separated by defn- or specific namespace like
> clojure.tools.cli.internals?

no reason other than its a small lib with a handful of functions...

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

On 29 Jul 2011, at 12:56, Ken Wesson wrote:
>>> 
>> 
>> That seems to blow up
> 
> How so?

(defn binding-vec [foos]
 (vec (interleave names (take (count names) (repeat `(count ~foos))

(defmacro magic-fn
[& forms]
(let [args (gensym 'args)]
  `(fn [& ~args]
 (let ~(binding-vec args)
   ~@forms

((magic-fn (+ size 10)) 1 2) ;=> Unable to resolve symbol: size in this context

> 
> (defmacro with-arg-params [bindings & body]
>  (let [bindings (apply array-map bindings)]
>`(fn
>  ~@(for [i (range (inc (count bindings)))]
>  `(~(vec (take i (keys bindings)))
> (let ~(vec (mapcat identity (drop i bindings)))
>   ~@body))
> 
> => (def x (with-arg-params [foo 1 bar 2 baz 3] (+ foo bar baz)))
> #'user/x
> => (x 4 5 6)
> 15
> => (x 4 5)
> 12
> => (x 4)
> 9
> => (x)
> 6

Ah, very neat :-)

However... (apologies, there always seems to be a however from me in this 
thread!)

This totally satisfies the "general gist" part of my description but doesn't 
allow for the "bunch of other neat tricks I can do here" part. The behaviour of 
with-arg-params needs to match the behaviour of other functions in my system 
for consistency. The other tricks are keyword args and even a combination of 
keyword args and normal args. I have the majority of code to implement all this 
behaviour - I can generate the correct vector of bindings given a list of 
supplied args and some defaults. However, it's the ability to dynamically 
create a let binding within a function for which the bindings themselves are a 
function of the actual function's args (and some constant(s)) which is evading 
me.

This seems the closest I can get to a solution:

(defn binding-vec [foos]
 (fn-which-returns-a-vec-of-alternating-symbols-and-vals foos)

(defmacro magic-fn
[& forms]
(let [args (gensym 'args)]
  `(fn [& ~args]
 (let ~(binding-vec args)
   ~@forms

((magic-fn (+ size 10)) 1 2)

I just don't have the magic skills to get it to actually work :-(

Sam

P.S. Thanks everyone for your help so far. My brain is overheating but I am 
learning a lot.

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

Building cli

[octopusgrabbus]

I have downloaded the source to tools.cli and built it with maven.
I've put the jar out in /usr/share/java, and created a link to it:

sudo ln -s /usr/share/java/tools.cli-0.1.0.jar /usr/share/java/
tools.cli.jar.

I am getting this error on compile

Caused by: clojure.lang.Compiler$CompilerException:
java.io.FileNotFoundException: Could not locate clojure/tools/
cli__init.class or clojure/tools/cli.clj on classpath:
(addr_verify.clj:2)

(ns addr-verify
  (:gen-class)
  (:require [clojure.string :as cstr])
  (:require [clojure.contrib.str-utils :as ustr])
  (:require [clj-http.client :as client])
  (:use clojure-csv.core)
  (:use [clojure.tools.cli])
  (:import java.util.Date)
  (:import java.lang.Thread)
  )

I've looked at how this is "included' in both cli's test directory and
on the internet, and I'm still getting the error.
Any help would be appreciated.
tnx
cmn

-- 
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: Building cli

[octopusgrabbus]

This fixed it. Thanks Gaz Jones:

:dependencies [[org.clojure/clojure "1.2.1"]
  [org.clojure/tools.cli "0.1.0"]]

On Jul 29, 10:01 am, octopusgrabbus  wrote:
> I have downloaded the source to tools.cli and built it with maven.
> I've put the jar out in /usr/share/java, and created a link to it:
>
> sudo ln -s /usr/share/java/tools.cli-0.1.0.jar /usr/share/java/
> tools.cli.jar.
>
> I am getting this error on compile
>
> Caused by: clojure.lang.Compiler$CompilerException:
> java.io.FileNotFoundException: Could not locate clojure/tools/
> cli__init.class or clojure/tools/cli.clj on classpath:
> (addr_verify.clj:2)
>
> (ns addr-verify
>   (:gen-class)
>   (:require [clojure.string :as cstr])
>   (:require [clojure.contrib.str-utils :as ustr])
>   (:require [clj-http.client :as client])
>   (:use clojure-csv.core)
>   (:use [clojure.tools.cli])
>   (:import java.util.Date)
>   (:import java.lang.Thread)
>   )
>
> I've looked at how this is "included' in both cli's test directory and
> on the internet, and I'm still getting the error.
> Any help would be appreciated.
> tnx
> cmn

-- 
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.command-line

[octopusgrabbus]

Thanks. This fixed it.

On Jul 29, 9:45 am, gaz jones  wrote:
> it lives on github:http://github.com/clojure/tools.cli
> like all the new contrib libs, to use it in a project you need to add
> it to your dependencies:
>
> :dependencies [[org.clojure/clojure "1.2.1"]
>                       [org.clojure/tools.cli "0.1.0"]]
>
> On Fri, Jul 29, 2011 at 7:56 AM, octopusgrabbus
>
>
>
>
>
>
>
>  wrote:
>
> > On Jul 28, 7:24 pm, Anthony Grimes  wrote:
> >> command-line is deprecated in favor of tools.cli 
> >> now.http://github.com/clojure/tools.cli
>
> > Where is the repository located?
>
> > (ns addr-verify
> >  (:gen-class)
> >  (:require [clojure.tools.cli :only (cli optional)])
> >  .
> >  .
> >  .
> > results in this error:
>
> >  clojure.lang.Compiler$CompilerException:
> > java.io.FileNotFoundException: Could not locate clojure/tools/
> > cli__init.class or clojure/tools/cli.clj on classpath:
>
> > --
> > 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

Clojure and Incanter Talk 3 August in London

[Bruce Durling]

Fellow Clojurians,

Ben Evans of the LJC and JCP will be giving a talk on how much he
loves and what he does with Clojure and Incanter at Skillsmatter in
London.

The talk is on 3 August. Doors open at 18.30! I hope to see you there!

The sign up page is here:

http://skillsmatter.com/event/java-jee/development-strategies

cheers,
Bruce

-- 
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: ClojureQL: consistent select queries?

[Michael Wood]

On 29 July 2011 14:01, Ken Wesson  wrote:
> On Fri, Jul 29, 2011 at 7:41 AM, László Török  wrote:
>> Hi,
>>
>> is there a way to execute multiple select queries on a table using clojureql
>> in a transaction?
>>
>> sg. like
>>
>>    (with-results [res1 query1
>>     res2 query2]
>>    .. do sg)
>>
>> and res1 and res2 would be taken from a same consistent snapshot.
>
> If you run two separate queries, I expect the database server will see
> them as two separate transactions, and may interleave some other,
> mutating transaction between them, so they won't in that case be taken
> from a consistent snapshot.

Well, I suppose it you use SELECT FOR UPDATE/SHARE it should not allow
changes between them, but I've never used SELECT FOR UPDATE or SHARE,
so perhaps I'm wrong or I'm misunderstanding your point.

e.g.

http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-FOR-UPDATE-SHARE

http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html

So, I think this should work:

BEGIN;
SELECT ... FOR SHARE;
SELECT ...;
COMMIT;

Whether it's possible to do that with ClojureQL I have no idea.

> You'd need to have a single query to the DB, which will run as a
> single transaction, generate both res1 and res2. I'm not sure if that
> will always be possible; my SQL-fu is a little rusty.

-- 
Michael Wood 

-- 
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: Apply holding onto the head of lazy seqs nested within args; .invoke weirdness

[abedra]

It seems like the behavior has changed a little in Clojure 1.3, but
still warrants some additional discussion.  Here's what I saw

(count (range 1))
user=> 1

(apply count [(range 1)])
user=> 1

(apply + (range 1))
user=> 49995000

(. count (applyTo (seq [(range 1)])))
user=> OutOfMemoryError GC overhead limit exceeded clojure.core/range
(core.clj:2599)

(clojure.lang.AFn/applyToHelper count (seq [(range 1)]))
user=> 1

(clojure.lang.RT/boundedLength (seq [(range 1)]) 20)
user=> 1

(let [x (range 1)]
  (clojure.lang.RT/boundedLength (seq [x]) 20) (count x))
user=> 1

(count (clojure.lang.Util/ret1 (.first (seq [(range 1)]))
nil))
user=> 1

(.invoke count (clojure.lang.Util/ret1 (.first (seq [(range
1)])) nil))
user=> OutOfMemoryError GC overhead limit exceeded
clojure.lang.ChunkedCons.next (ChunkedCons.java:42)

(.invoke count (range 1))
user=> OutOfMemoryError GC overhead limit exceeded  clojure.core/chunk-
cons (core.clj:646)

(let [c #^clojure.lang.AFunction count]
  (.invoke c (clojure.lang.Util/ret1 (.first (seq [(range
1)])) nil)))
user=> 1

This leads me to believe that there may be a bug here, but I am going
to take a closer look.  If that is the case I will file an issue in
JIRA.

Cheers,

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


On May 18, 11:50 pm, Ken Wesson  wrote:
> In Clojure 1.2.0:
>
> => (count (range 1))
> 1
> => (applycount [(range 1)])
> # exceeded (NO_SOURCE_FILE:0)>
>
> I'm not sure why this is happening, but it seemsapplyis causing theheadof the 
> range to be held somewhere.
>
> This:
>
> => (apply+ (range 1))
> 49995000
>
> indicates that it does not do so if the enormous seq is applied to a
> rest argument of the fn; with count, it should just be passing the
> (unrealized!) seq as a parameter to count. But apparently it's
> internally hangingontoa reference to that seq.
>
> Tracking it down:
>
> => (. count (applyTo (seq [(range 1)])))
> #
>
> => (clojure.lang.AFn/applyToHelper count (seq [(range 1)]))
> #
>
> => (clojure.lang.RT/boundedLength (seq [(range 1)]) 20)
> 1 ; No kablooey there
>
> => (let [x (range 1)] (clojure.lang.RT/boundedLength (seq [x])
> 20) (count x))
> 1 ; And again no kaboom; boundedLength isn't causing this
>
> => (count (clojure.lang.Util/ret1 (.first (seq [(range 1)])) nil))
> 1 ; Looks like ret1 isn't the cause either.
>
> => (.invoke count (clojure.lang.Util/ret1 (.first (seq [(range
> 1)])) nil))
> #
>
> ; Er, aren't those last two supposed to be *synonymous*?!
>
> ; And finally
>
> => (.invoke count (range 1))
> #
>
> ; Now here is something really weird:
>
> => (let [c #^clojure.lang.AFunction count] (.invoke c (range 1)))
> 1
>
> ; No kaboom!
>
> As near as I can tell, I've found 2 separate buggy behaviors here.
>
> 1: If an interop call uses reflection and passes a lazy seq, theheadgets
>    heldontosomewhere.
>
> 2: A non-reflection-using (.invoke count (range 1)) does not blow
>    up in the REPL, but invoke(count, huge_seq); does when
> applyToHelper calls it.
>
> => (let [c #^clojure.lang.AFunction count]  (.invoke c
> (clojure.lang.Util/ret1 (.first (seq [(range 1)])) nil)))
> 1
>
> Nope, still not ret1 (which is in fact supposed to prevent this sort of 
> thing).
>
> And theapplyfunction hints the function argument as IFn so it isn't
> caused by reflection inapply.
>
> What the devil is going on here???
>
> --
> 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: ClojureQL: consistent select queries?

[László Török]

Hi

2011/7/29 Michael Wood 

> On 29 July 2011 14:01, Ken Wesson  wrote:
> > On Fri, Jul 29, 2011 at 7:41 AM, László Török 
> wrote:
> >> Hi,
> >>
> >> is there a way to execute multiple select queries on a table using
> clojureql
> >> in a transaction?
> >>
> >> sg. like
> >>
> >>(with-results [res1 query1
> >> res2 query2]
> >>.. do sg)
> >>
> >> and res1 and res2 would be taken from a same consistent snapshot.
> >
> > If you run two separate queries, I expect the database server will see
> > them as two separate transactions, and may interleave some other,
> > mutating transaction between them, so they won't in that case be taken
> > from a consistent snapshot.
>
> Well, I suppose it you use SELECT FOR UPDATE/SHARE it should not allow
> changes between them, but I've never used SELECT FOR UPDATE or SHARE,
> so perhaps I'm wrong or I'm misunderstanding your point.
>
I'm not sure SELECT FOR UPDATE/SHARE is very portable and whether it maps to
relational algebra primitives which are the underpinnings of ClojureQL, if I
am correct.

It also introduces a lock which is not my intention.

I need to make sure the when I'm done with the operation I can insert a new
row into the table and be sure certain invariants still hold.

My approach is to define a uniqueness constraint on a sequence_no coloumn.
If an insert with MAX(sequence_no)+1 succeeds, I guess I can be sure
nothing  changed while I was busy computing the result.

Anyway, to be clear, I'm ok with my approach, I just didn't know how to do
it in ClojureQL. :)

>
> e.g.
>
>
> http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-FOR-UPDATE-SHARE
>
> http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
>
> So, I think this should work:
>
> BEGIN;
> SELECT ... FOR SHARE;
> SELECT ...;
> COMMIT;
>
> Whether it's possible to do that with ClojureQL I have no idea.
>
> > You'd need to have a single query to the DB, which will run as a
> > single transaction, generate both res1 and res2. I'm not sure if that
> > will always be possible; my SQL-fu is a little rusty.
>
> --
> Michael Wood 
>
> --
> 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
>



-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

-- 
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: Code structure/design problems

[Michael Gardner]

On Jul 29, 2011, at 1:50 AM, Laurent PETIT wrote:

> Without too much thinking about it, I would have thought monsters, players, 
> etc. need to be changed in a same "transaction", so would have by default 
> implemented them as refs instead of atoms.
> 
> Could you elaborate more on the choice of atoms as design decisions ?

Not to hijack the question, but in my game I used a single atom containing the 
state of the entire game world as a hash. This is not too inefficient thanks to 
Clojure's structure-sharing, and has certain advantages: saving or printing the 
world state becomes trivial, and you can simplify argument lists for functions 
that need to use multiple world objects (though some would object to passing 
the entire world to a function that uses only certain parts of it).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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

[Jonah Benton]

Re:

>
> Hopefully some bright spark will come along and revolutionise dependency
> management, like how Rich revolutionised the notion of state in
> programming.  As far as I'm aware nobody has so far, for any programming
> language (or OS distro), I'm not completely happy with any of them.
>
> It needs more hammock time.

What golang has done is interesting, insofar that a more complete
lifecycle is supported with the out of the box tools.

-- 
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: Question regarding structural sharing, records, and maps

[Michael Gardner]

On Jul 28, 2011, at 10:59 PM, Trenton Strong wrote:

> So far, I
> have settled on just using a single ref wrapping the root node of the
> tree with all update functions acting on that ref via dosync.

An atom would be more appropriate, unless you're coordinating updates to the 
tree with updates to some other ref.

-- 
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: Question regarding structural sharing, records, and maps

[Trenton Strong]

On Jul 29, 8:58 am, Michael Gardner  wrote:
>
> An atom would be more appropriate, unless you're coordinating updates to the 
> tree with updates to some other ref.

Ah, for some reason that didn't occur to me, thanks.  Since the tree
in this case acts as a supporting index on spatial data, it pretty
much defers to the outcome of any updates to the original entities.

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

[abedra]

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
--
Clojure/core
http://clojure.com

On Jun 24, 12:47 pm, Mark Engelberg  wrote:
> One of the main changes to1.3is that arithmetic operations on longs
> do not automatically overflow.
>
> In the early discussions of this new feature, it was pointed out that
> people who want overflow capability can use the special "prime"
> operators, but that the preferred way to do things would be to write
> functions in such a way that you can pass in bigints if you want
> overflow.
>
> But it was also pointed out that passing in bigints to ensure overflow
> would be a huge performance hit over 1.2 for cases where overflow only
> happens sometimes, because this forces bigint math to happen all the
> time, which is substantially slower thanClojure'sexisting strategy
> of doing math on longs and only switching to slower bigint math when
> overflow actually occurs.
>
> To resolve this, it was proposed thatClojurewould use its own BigInt
> class rather than Java's built-in.  It would start off as a stub that
> forwarded everything to Java's implementation, but would eventually be
> converted to a more intelligent interpretation that works more 
> likeClojure'sexisting system -- numbers small enough to be represented as
> Ints or Longs would be represented that way and benefit from faster
> computation.
>
> As far as I know, the stub class was indeed implemented to preserve
> the option to make these optimizations, but no one has actually
> refined the BigInt class.  I propose that these optimizations should
> be done beforeClojure1.3goes final, because this is a really
> important part of ensuring good numeric performance for applications
> that were previously taking advantage ofClojure'sability to handle
> overflows.  If this isn't done byClojure1.3final, we're going to
> end up with a body of code that, by necessity, uses the prime
> operators, because the preferred strategy of passing in bigints will
> be impractically slow.  If we want to get people to use the idiom of
> using non-prime operators and passing in bigints, we need to make sure
> this approach performs well for the final release.

-- 
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: protocols and records -- use when?

[Lee Spector]

On Jul 28, 2011, at 8:19 PM, Alex Osborne wrote:
> The main use cases for the old structs feature on the other hand are
> completely replaced by records and it is recommended that new code use
> defrecord instead of defstruct.

I had some code using structs and, following advice like this, replaced it with 
code using records. 

The result was more complicated, uglier and not noticeably faster. 

I reverted to the struct version.

I like structs, and I hope they are retained!

 -Lee

PS for anyone who is curious the struct version of the code in question is as 
follows (with push-types having a value like '(:exec :integer :float :code 
:boolean :auxiliary :tag :zip)):

(defmacro define-push-state-structure []
  `(defstruct push-state ~@push-types))

(define-push-state-structure)

(defn make-push-state
  "Returns an empty push state."
  []
  (struct-map push-state))

The record version that I came up with is:

(defn keyword->symbol [kwd]
  "Returns the symbol obtained by removing the : from a keyword."
  (read-string (name kwd)))

(defmacro define-push-state-record-type []
  "Defines the pushstate record type. The odd trick with read-string was a hack 
to 
avoid namespace qualification on the pushstate symbol."
  `(defrecord ~(read-string "pushstate") [~@(map keyword->symbol push-types)]))

(define-push-state-record-type)

(defmacro make-push-state
  "Returns an empty push state."
  []
  `(pushstate. ~@(map (fn [_] nil) push-types)))

Maybe there's a better way -- I wouldn't doubt it -- but the struct version was 
simple and worked exactly like I wanted it to, so I decided to stop tinkering.

-- 
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 7 is out!

[cassiel]

On Jul 29, 1:18 am, Ken Wesson  wrote:
> On the one hand, assuming that Java 7 doesn't outright break anything, [...]

Like loops?

http://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/

-- 
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 7 is out!

[Aaron Bedra]

On 07/28/2011 11:54 AM, Daniel Gagnon wrote:

So, what does it means for Clojure?

Faster execution? Some new interesting stuff in the standard Java library?

And I remember there was something about forkjoin that would be good 
for Clojure, what about that?

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


The short answer here is that the new platform features in Java 7 will 
not get any attention for quite some time.  There is a lot of 
stabilization and maturity that has to happen here before we jump into 
implementation.  There is also the story of the backports.  Since 
Clojure still targets 1.5, this is walking the line of a non-starter.  
This can eventually change, but the benefit that we would see versus the 
impact to the language doesn't make sense right now.


That being said, given other benefits like the new garbage collector and 
more hotspot optimizations, it is very likely that Clojure sees 
performance improvements without doing anything.  We will be taking the 
time to make sure that Clojure runs on Java 7 and address issues that 
come up, but the invoke dynamic and method handle stuff is not in the 
immediate pipeline.  Neither is adding the Java language bits like 
Diamond, try-with-resources, or the rest of them into the Java parts of 
Clojure.


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

[James Reeves]

On 29 July 2011 08:01, Michal B  wrote:
> Leiningen definitely alleviates the hairiness of library management. But I
> wish people won't settle for a lein like solution for simple projects. As
> much as it helps, it is still an unnecessary burden and an obstacle to
> adoption, in my opinion and experience.

Why is it a burden?

Let's take a step back and consider a simple library with a few lines
of code and a couple of dependencies.

With Leiningen or Cake, the process would be:

1. lein new foobar
2. cd foobar
3. Add :dependencies to project.clj
4. Add :main namespace to project.clj
4. Write the code
5. lein run

I'm having trouble seeing how this could be much simpler, unless the
dependencies were somehow resolved automatically.

So what about if we forgo a build tool? Then the process would be:

1. mkdir foobar
2. cd foobar
3. Download dependencies manually as jars, including Clojure itself
4. mkdir lib
5. Place all dependencies in lib
6. mkdir -p src/foobar
7. Write code
8. java -cp 'lib/*.jar:src' foobar.core

I'm not seeing how this is any simpler. The act of going around and
downloading dependencies manually also seems particularly time
consuming.

And once you've written your application, how do you publish it? With
Leiningen and the Clojars plugin, it's:

1. lein push

But manually, it would be:

1. cd src
2. jar cf foobar-1.0.0.jar */*.clj
3. cd ..
4. mv src/foobar-1.0.0.jar lib
5. cd lib
6. zip cf foobar-1.0.0-standalone.zip *.jar
7. Upload resulting zip file to your project website

As far as I can see, even with the simplest of projects, there is no
reason not to use Cake or Leiningen. You'll have to do much more work
without them.

- James

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

Defrecord and Interfaces..

[Andreas Liljeqvist]

Is this a bug?

(defprotocol Notcloseable (dosomething [this]))

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

  Notcloseable
(dosomething [_] (print "something")))


user> (def a (Archive.))

user> (.close a)
closeable

user> (close a)

Unable to resolve symbol: close in this context
  [Thrown class java.lang.Exception]

user> (dosomething a)
something

user> (.dosomething a)
something

Implementing a protol creates both java function and a clojure function.
Implementing an interface only creates the java function.

Seems kind of strange.

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

Possible Issue with Listing 11.5 from the "Joy of Clojure"

[Julien]

Hi Everyone.

I have been reading the "Joy of Clojure" with great interest, but I
may have noticed a possible problem with listing 11.5. For those of
you who don't have the book, here is the listing:

(defn make-safe-array [ t sz]
  (let [a (make-array t sz)]
(reify
  SafeArray
  (count [ _] ( clj/count a))
  (seq [_] (clj /seq a))
  (aget [_ i]
( locking a
  (clj /aget a i)))
  (aset [ this i f]
( locking a
  (clj /aset a i (f ( aget this i

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

-- 
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: Pair Coding over Skype

[Jeremy Heiler]

On Thu, Jul 28, 2011 at 5:37 PM, nil  wrote:
> Until you find someone, one site you can look at is the clojure euler
> site. It has some math examples written by folks who know clojure to
> varying degrees. You can see different ways of tackling a given
> problem.

Is this the site you are talking about?

http://clojure-euler.wikispaces.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: Libraries and build management hell

[Lee Spector]

On Jul 29, 2011, at 8:14 AM, Alex Osborne wrote:
> 
> 6. Click "hooke-1.1.2.jar" and save the jar file to your project.
> 
> The repository is really nothing more than a bunch of directories
> each containing a jar files and another file containing a list of
> dependencies.  I'm not sure how you could make it any simpler.

FWIW for some JVM newcomers (like me when I started) #6 involves some mysteries 
related to where exactly the jar should be saved and how exactly the other code 
can be told to find it. It varies depending on how you run your code (e.g. 
whether you have to figure out how to construct a -cp argument or do other 
non-obvious things in a complex IDE, etc.) and then there's the hierarchical 
namespace/directory structure correspondence, which I found initially 
surprising and confusing.

Bottom line is that I agree that leiningen makes all of this simpler, assuming 
that your editor and other tools play nice with leiningen. I'm just pointing 
out that the manual method is actually a little worse than you've implied, for 
people new to JVM programming.

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

[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

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

[Tal Liron]

Lars,

Yes, they are different things. :) Ext Core is probably close in scope
to jQuery by itself. But you can really build Ext JS modularly and use
only what you want. Also, jQuery + plugins ends being just as full-
featured as the complete Ext JS (though the quality of jQuery plugins
tends to be very spotty, IMO.)

Praki, the short answer is that:

1) Ext JS uses the flyweight design pattern throughout, which saves a
lot of resources (it means far less instances are created). Everything
in jQuery is heavyweight.
2) Ext JS has a template-based widget rendering pipeline.
3) Both the above have very real-world performance improvements. I
moved one of my applications from jQuery to Ext Core and had a 400%
performance gain.
4) Ext JS has a very nice class system. I'm not a huge fan of object
orientation, but admit that it makes a lot of sense in widget/
component environments.
5) jQuery plugin architecture is very incoherent. Try to design your
plugin and see!

On Jul 28, 9:40 pm, Praki Prakash  wrote:
> On Thu, Jul 28, 2011 at 5:20 PM, Tal Liron  wrote:
> > jQuery is not so much an elephant as it is a mammoth. It was one of
> > the first clientside-JS frameworks to reach a broad audience, but it
> > also one of the worst. It incorporates so many terrible JS practices,
> > performs miserably, and really can make anyone dislike JS. People have
> > mentioned other clientside frameworks. Let me mention also Ext JS,
> > which I believe knocks the socks off the rest. It is crafted with a
> > real appreciation of JS, and that love may rub off you a little as you
> > work with it.
>
> I am not a front-end developer but I am currently stuck prototyping using
> JQuery. I am
> also not a JS expert. I am curious: can you list JQuery's issues and how it
> uses JS badly?
> Or, provide some references?
> --
> (praki)

-- 
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: Question regarding structural sharing, records, and maps

[Trenton Strong]

On Jul 29, 4:38 am, Ken Wesson  wrote:
> Yes. In fact this should work with records, too -- all the "native"
> fields of the record need to be copied for each version, but most will
> typically be pointers and most of those will typically be to existing
> objects. Only the ones that were changed will point to new nested
> objects. So unless your records have huge numbers of predefined fields
> there shouldn't be much time or memory cost in copying them.

Thanks for clearing that up.  I wasn't exactly sure how the memory
model of records worked.  The semantics that records provide seem like
a good fit for applications like this.

> Probably. Any two changes to the tree will cause one to retry in the
> single-ref case, unless you're sure all the changes will commute.
> (Changes to distinct fields where one change doesn't depend on what
> the other changes will commute, and changes to the same field that
> don't matter as to sequencing, such as inc and dec, will commute, but
> otherwise no.)

Yeah, tree updates are pretty much strictly non-commutative.  The
retry overhead will probably grow quite fast with the number of
concurrent updates.

>
> You will probably want something structured more like a database, with
> "tables" that are maps and "rows" that are records or more complex,
> nested structures, such that most concurrent changes will not affect a
> common row. The "tables" can then be refs of maps of refs, with most
> changes operating on the row-refs. The table refs only need to change
> if rows are inserted or deleted; those could be bottlenecks, though if
> all objects have GUIDs as keys in these tables then row insertions and
> deletions will commute, leaving only the GUID generators for each
> table.

I think I understand the structure here, but just to be clear, you're
proposing flattening
of the tree structure from something like this:

(ref
{
  :contents (some stuff),

  :child-node1 {
:contents (other things)
:child-node1 ...
  },

  :child-node2 {
:contents (thingy1 thingy2)
...
  }
  ...
})

into something like this?

(ref
{
  :some-guid  (ref {<<< could be a map, record, or what have
you
:contents (some stuff)
:child-node1 :another-guid
:child-node2 :and-another-guid
  })

  :another-guid (ref {
:contents (other things)
...
  })

  :and-another-guid (ref {
:contents (thingy1 thingy2)
...
  })
}

Interesting.  I feel like I should have thought of this since I've
done something similar in more object oriented code, but riddled with
lots of fine grained locking.  Here if updating one row references
another
the transaction is going to handle the snapshotting.  I begin to
see...

>
> Unfortunately, (let [new-id (commute table-x-guid-counter inc)])
> sounds nice but might result in new-id taking on the same value in two
> concurrent transactions, so you'll need to use alter and GUID
> generation may be a bottleneck. But it may be much faster than your
> other, more complex transactions. Be sure to do it separately, e.g.:
>
> (let [new-id (dosync (alter table-x-guid-counter inc))]
>   (dosync
>     (commute table-x assoc new-id some-thingy)))
>
> You can even use atoms for the guid counters instead of refs, and then
> the ! in swap! will remind you to get the ID before entering a
> transaction. Do as much of what's needed to generate some-thingy
> before the transaction, too -- though if it depends on other refs'
> values, and those values should be current rather than it being
> acceptable for them to be values that were there recently but might
> have changed, then some of the work will need to be done in the
> transaction.
>
> > I've considered wrapping each node in
> > a ref and performing updates that way, or possibly taking the async
> > route and dispatching cals using agents, but my experience there is
> > nil.  Any insight there?
>
> I'd avoid having refs nesting more than two deep. Complex arrangements
> of cross-references among nodes can create a giant headache in
> combination with refs and transactions, so using a "database" approach
> with "table" maps, ID token keys, and cross-references to ID tokens
> rather than objects is often sensible. In particular, complex objects
> with nested refs effectively have mutable state inside them, which is
> usually not desired in Clojure. (One can argue, though, that the ref
> object is not different in principle from the ID token and removes a
> layer of indirection, and possibly obviates the need to generate IDs
> from counters that act as bottlenecks -- though, really, the Java new
> operator's allocation of memory now takes the role of ID generator.
> I'm given to understand modern VMs do some clever things to make new
> able to be fairly concurrent, though, such as giving each thread its
> own subset of the eden generation to allocate in.)

Makes sense.  I need to look into generating GUIDs quickly in a
concurrent manner for other parts
of the application anyways.  I'm sure if this become

Re: Question regarding structural sharing, records, and maps

[Ken Wesson]

On Fri, Jul 29, 2011 at 4:33 PM, Trenton Strong
 wrote:
> Thanks for clearing that up. ...

> Thanks for taking the time to craft such a thoughtful reply, it is
> really helpful.

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

[Ken Wesson]

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

Alternatively, if that might result in a lot of inefficient duplication,

(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)
  ...]
  ...)

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

[ax2groin]

Can you provide a more detailed review? How did it help you? What
area(s) that it focused on did you find most useful?

I've been playing with Clojure for nearly a year now, but it has just
been on my own. At work, however, it is just Java and C#. Of course,
I've also got several computer books waiting to be read, so
essentially I'm asking you to convince me to let this book jump the
queue. :^)


On Jul 29, 5:03 am, Colin Yates  wrote:
> Hi all,
>
> Not sure whether this is good etiquette or not, but I wanted to 
> praisehttp://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

Re: Good book on migrating from (Java) OO to FP

[Colin Yates]

It is only 80 or so pages which made it jump to the top of my queue
:).  There wasn't really any one thing, it just made lots of things
click.  He describes a FP construct or principle and then shows the
Java implementation.

I am currently in hammock time before I jump in with both feet, and My
roadblock is seeing how I can implement things in a functional way.
This book helped bridged that gap for me.

My only criticism is that it was a bit too lightweight and short :)

Sent from my iPad

On 29 Jul 2011, at 22:04, ax2groin  wrote:

> Can you provide a more detailed review? How did it help you? What
> area(s) that it focused on did you find most useful?
>
> I've been playing with Clojure for nearly a year now, but it has just
> been on my own. At work, however, it is just Java and C#. Of course,
> I've also got several computer books waiting to be read, so
> essentially I'm asking you to convince me to let this book jump the
> queue. :^)
>
>
> On Jul 29, 5:03 am, Colin Yates  wrote:
>> Hi all,
>>
>> Not sure whether this is good etiquette or not, but I wanted to 
>> praisehttp://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: better community docs: getting started

[nchurch]

Here's a tutorial on getting started with Clooj:

http://dev.clojure.org/display/doc/getting+started+with+Clooj

If this looks good to people, I'll try to get permission to reorganize
the Getting Started docs a little.

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

[Laurent PETIT]

2011/7/29 Colin Yates 

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

Wow, this seems pretty cool. 80 pages is a bonus for introductory material.
And the table of content really seems appealing from a java developer
perspective, indeed (it's well marketed !).

I think I'm gonna buy one book (not saving trees this time) and let it on my
table for my co-workers to go through "oh so inadvertantly ;-)"

Cheers,

-- 
Laurent


>
> (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: better community docs: getting started

[Laurent PETIT]

Sorry to make things look different than the apparent consensus of the
participants to this thread, but isn't it a little bit too prematurate to
put that pressure on Clooj ?

I understand the desire to have Clooj for "filling the gap".

But my question is : is it ready yet ?

2011/7/29 nchurch 

> Here's a tutorial on getting started with Clooj:
>
> http://dev.clojure.org/display/doc/getting+started+with+Clooj
>
> If this looks good to people, I'll try to get permission to reorganize
> the Getting Started docs a little.
>
> --
> 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: Possible Issue with Listing 11.5 from the "Joy of Clojure"

[Ken Wesson]

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

[Ken Wesson]

On Fri, Jul 29, 2011 at 5:33 PM, Laurent PETIT  wrote:
> Sorry to make things look different than the apparent consensus of the
> participants to this thread, but isn't it a little bit too prematurate to
> put that pressure on Clooj ?
> I understand the desire to have Clooj for "filling the gap".
> But my question is : is it ready yet ?

>From what I've heard, the only thing missing I'd consider really
important is a way to auto-reindent one or more lines. (Others might
consider syntax highlighting to be crucial as well; I don't know.)

-- 
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.contrib.command-line

[OGINO Masanori]

> no reason other than its a small lib with a handful of functions...
I see. Thanks.

-- 
Name:  OGINO Masanori (荻野 雅紀)
E-mail: masanori.og...@gmail.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: Pair Coding over Skype

[nil]

Yes

On Jul 29, 3:24 pm, Jeremy Heiler  wrote:
>
> Is this the site you are talking about?
>
> http://clojure-euler.wikispaces.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: Libraries and build management hell

[octopusgrabbus]

On Jul 28, 10:06 pm, Mark Rathwell  wrote:
> The problem with jar downloads as the default distribution method is that
> non-Java people, and even plenty of Java people, seem to have problems
> consistently setting classpaths correctly.  Seems much more straightforward
> to just have lein take care of that for you.

So far, my problems have not been related to CLASSPATH, but instead
revolve around understanding the differences in how different packages
are built.

Also, the structure of different library's build directories that I
have seen on github varies quite a bit.

I am building an application and only need my source in ./project_name/
src/project_name.clj, but some libraries I have seen have a
project_name/project_name.clj under source.

For beginners, it is a roadblock. But because of this group, the
roadblock, at least for me, is temporary.



>
> As for complicated installation instructions, libraries meant to be used in
> lein have installation instructions that generally look like this:
>

> [compojure "0.6.4"]
>
> The other alternative is to have environment package managers like Python
> with easy_install and Ruby with gems.  Then you need to bring virtualenv or
> Ruby version manager into the picture to use different versions of the same
> library in different apps.  The Java world has tended towards dependencies
> being coupled with the application, rather than the environment.  There are
> good arguments for both sides, but either way, I don't think it can get much
> easier than lein.
>
>  - Mark
>
> On Thu, Jul 28, 2011 at 5:23 PM, Michal B  wrote:
> > Why does it have to be so complicated to use libraries?
>
> > To use libraries, you need to learn how to operate half a dozen build tools
> > and git because each library author distributes their library differently.
> > If figuring out how to install an IDE with clojure wasn't bad enough, now
> > you need to figure out how to install and use each of the tools with it.
>
> > I'm not saying build tools are useless, on the contrary. It's just that
> > most of the time, we want to sling two or three libraries together and code.
> > Right? There is no need to start a project with a bunch of template files
> > and an elaborate directory structure and to start configuring dependencies
> > and to rely on some magic happening that makes your program run.
>
> > I think we over-engineered the build process to support the big projects
> > and forgot the common case. Most projects are simple.
>
> > Let's remove this incidental complexity by returning to simplicity. Keep
> > the build tools for the heavyweights and get back in touch with your
> > libraries.
>
> > Instead of having a complicated installation guide for your library, have a
> > Download section in your site. Have there a link to the latest stable
> > version of your library as a jar file or, if necessary, a zip file with your
> > jar and and all the necessary dependency jars (sane library authors won't
> > mind). For a zip, shortly describe what's in it - library names and
> > versions, and links to their sites. That's it.
>
> > I think most JVM users know or can quickly figure out how to take jars and
> > put them in their project's classpath. It's simple to do with all IDEs (or
> > without one) and there is no need to learn or install additional software or
> > edit configuration files. Starter scripts should include in the classpath
> > all jars in the current directory or jars/ directory by default.
>
> > Instead of managing libraries inside a dependencies file, you do it
> > directly with the jar files. If the project gets too big, bring in the build
> > tools.
>
> > What are your thoughts on this issue?
>
> >  --
> > 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: Pair Coding over Skype

[cej38]

I am not your man for being a tutor, but what type of math libraries?


On Jul 28, 1:26 pm, Jay Vyas  wrote:
> Hi guys (and hello to my beloved london-clojurians) : My name is jay and I
> want to pair program some Clojure scripts against REPL  with a moderate to
> good clojure tutor.  If anyone is intersted I'd be willing to pay an hourly
> fee.  Want to work on some mathematical libraries  for my Phd Thesis.
> Thanks !
>
> Jay

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

[Lee Spector]

On Jul 29, 2011, at 5:39 PM, Ken Wesson wrote:

> On Fri, Jul 29, 2011 at 5:33 PM, Laurent PETIT  
> wrote:
>> Sorry to make things look different than the apparent consensus of the
>> participants to this thread, but isn't it a little bit too prematurate to
>> put that pressure on Clooj ?
>> I understand the desire to have Clooj for "filling the gap".
>> But my question is : is it ready yet ?
> 
> From what I've heard, the only thing missing I'd consider really
> important is a way to auto-reindent one or more lines. (Others might
> consider syntax highlighting to be crucial as well; I don't know.)

Considering how very young it is, it's probably not realistic to consider it 
ready quite yet.

That said, I'm a clooj cheerleader because I think that it, when combined with 
lein or cake, hits the ease/completeness sweet spot in a way that no other tool 
currently does.

THAT said, I've just begun to try to work in it seriously, and I just sent 
three messages raising new issues to the clooj list.

*THAT* said, the improvements have been coming fast, and particularly if others 
pitch in I think it could be "real good" "real soon".

 -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

[ANN] (first phoenix-clojure-user-group-meetings)

[pmbauer]

Announcement Link, details: 
https://groups.google.com/d/topic/clj-phx/l_S4qcOSuaY/discussion

August 30th, 6:30 PM
Food provided.
Please use the group mailing list for replies, RSVPs (
http://groups.google.com/group/clj-phx)

Hosted by *Shutterfly *.

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

[Stefan Kamphausen]

inc

IMHO there are three types of people coming to Clojure


   1. Java Programmers
   2. Old-school lispers
   3. all the other, who just want to try (and possibly follow the examples 
   in a tutorial or book)

For the first two groups the obstacles and interest can probably be sorted 
out and the third groups just needs some basic setup, which may be presented 
using Clooj (or lein repl or a virtual machine download or even just 
clojure.main, or ...).

To me it seems important to get the common misunderstandings and problems 
out of the way for groups 1 and 2.  The Java-programmers will need more help 
to get going with REPL-oriented programming an to integrate Clojure in their 
(existing) Java-programs, whereas the old-school lispers (OSPs? ;-) need a 
hand getting around in the Java ecosystem (mvn, jar, war, classpath, etc).

Kind regards,
Stefan

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

[Stefan Kamphausen]

Hi,

On Thursday, July 28, 2011 11:23:58 PM UTC+2, Michal B wrote:
>
> Why does it have to be so complicated to use libraries?
>

because it is a complicated topic.

Maybe I can compare it to other ecosystems.

* CPAN for Perl is a paradise for functionality.  However, trying to use 
CPAN together (or against) the means of the operating system (sax Linux) is 
embarrassing (with Gentoo being the only exception I know of - different 
story).  After 10+ years of professional programming in this field I only 
use standard installation plus pure Perl implementation libraries without 
dependencies for production today.  Sucks.

* Ruby Gems?  No way for a newcomer to understand this quickly. Used it 
primarily for Rails and gave up with setups for Rails 3.0 and 2.something on 
differents OSes.

* Python Eggs?  A little less involved than Gems in my experience, but what 
do I know?  Only used a few libs either for one-shot programs on my machine 
or slowly moving targets elsewhere.

* Emacs Lisp libraries?  I've been doing this for 15+ years and it kinda 
works.  But Clojure itself is a nice example, where it doesn't, what with 
the SLIME incompatibilities.

* Common Lisp?  This community worked ages on trying to get past the "CL is 
cool, but libraries suck"-stage and only recently quicklisp came around, 
which may help (unless it gets to the stage of conflicting with the OS; see 
CPAN above).

* Java? Ho, humm-- as treebeard may say-- ho, humm, Java is ugly, Maven is 
even uglier, but in a way ... it works.

IMHO that's one big selling point of Clojure: you can use the 
Java-ecosystem.  It's not nice, but it is definitely a huge success story. 
And thus, it is worth getting into it.  Even more so, if Leiningen will help 
you for the first time.


Kind regards
Stefan

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

[Jeff Heon]

In the vein of FP for Java programmers, these two libraries might be
of interest.

Sequence-like operations on collection using annotations. Nice and
small.
http://jedi.codehaus.org/

More advanced and Scalaish. Benefits from a bigger community.
http://functionaljava.org/

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

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

Re: Libraries and build management hell

[Alex Osborne]

Lee Spector  writes:

> FWIW for some JVM newcomers (like me when I started) #6 involves some
> mysteries related to where exactly the jar should be saved and how
> exactly the other code can be told to find it. It varies depending on
> how you run your code (e.g. whether you have to figure out how to
> construct a -cp argument or do other non-obvious things in a complex
> IDE, etc.) and then there's the hierarchical namespace/directory
> structure correspondence, which I found initially surprising and
> confusing.
>
> Bottom line is that I agree that leiningen makes all of this simpler,
> assuming that your editor and other tools play nice with
> leiningen. I'm just pointing out that the manual method is actually a
> little worse than you've implied, for people new to JVM programming.

Oh I totally agree.  Perhaps I was being misleading there.  I was
replying to Mikal's hypothesis that if library authors used a manual
release process instead of version control and build tools everything
would be considerably simpler for library consumers who know how to feed
jars to the JVM.  It's definitely worth questioning your assumptions
from time to time and I'm glad he brought it up, it is giving me some
ideas.  I don't think it's a good solution though because the tools at
the very least give us consistency.

I don't think the maven standard is perfect.  The whole "group id" thing
in my opinion is confusing and not quite right (which is why with
Clojars I deviated from how Maven Central uses it).  But at least we
have a way that all the tools (and people) can interoperate with each
other and I'm willing to live with some warts in order to get that.

The JVM does not make things fun.  It was only in Java 6 that the
ability to use wildcards in the classpath (-cp lib/*) was added for
example, in earlier versions you had to specify every single jar file
one by one.  But that's not the fault of build tools, the tools exist
precisely because the JVM does not ship with a good solution to this
problem.

Tools with a system install model like RubyGems and ez_install seem
deceptively easier when you're a beginner.   I think they do work
well in a highly structured and well curated ecosystem (eg Debian) but
that takes serious commitment.  Unfortunately once you get past the
beginner stage and start dealing with multiple versions of libraries and
such it quickly turns into a huge headache and you end up with awful
workarounds like RVM.

I work at a shop that uses both Ruby and Java.  For our Ruby projects
after much frustration we've just resorted to chucking all the gems for
a project into the project's version control and pointing at them with
GEM_HOME.  Some of our developers try to use Bundler but I find it to be
more trouble than it's worth (particularly when deploying to JRuby).
It's amazing how much time someone can waste messing around trying to
get Bundler to behave right.

Compared to that the Leiningen model as a default is downright blissful.

Clojure/core are pushing a third model.  Get all the good stuff into
contrib.  I guess you could compare that to something like FreeBSD and
in a sense the way the Linux kernel project works.  Ultimately that
very likely will result in higher quality output and is not bad for
beginner users.  But to get that quality it necessarily means a bigger
commitment and a higher barrier to entry for authors.

http://groups.google.com/group/clojure/browse_thread/thread/c40ff3e876b4b370

I'm glad to see that core are trying to make contrib model more
accessible.  For a long time with Rich as the sole gatekeeper it was
a pretty select club.  Even now though it could be better communicated,
the references to contrib on the website are pretty vague if you don't
already know what it is.

I've been fairly heavily following Clojure for a couple of years now, I
have signed the CA and I'm still not completely sure if I'd be welcome
to contribute to contrib.  It's intimidating.  Maybe that's just
timidity on my part 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: Good book on migrating from (Java) OO to FP

[Wilson MacGyver]

for java, I use google guava quite a bit. (formerly known as google
collections).

http://code.google.com/p/guava-libraries/

there is quite a bit of FPish things in it.

On Fri, Jul 29, 2011 at 9:49 PM, Jeff Heon  wrote:
> In the vein of FP for Java programmers, these two libraries might be
> of interest.
>
> Sequence-like operations on collection using annotations. Nice and
> small.
> http://jedi.codehaus.org/
>
> More advanced and Scalaish. Benefits from a bigger community.
> http://functionaljava.org/
>
> --
> 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



-- 
Omnem crede diem tibi diluxisse supremum.

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

Online videos of Montreal Clojure User Group presentations

[Jeff Heon]

Some presentations of the Montreal Clojure User Group are now online.

http://vimeo.com/groups/bonjure/videos

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

[Petr Gladkikh]

On Tue, Jul 26, 2011 at 5:14 PM, Ken Wesson  wrote:
> On Tue, Jul 26, 2011 at 6:02 AM, Petr Gladkikh  wrote:
>> On Tue, Jul 26, 2011 at 3:28 PM, Alan Malloy  wrote:
>>> On Jul 25, 11:10 pm, Petr Gladkikh  wrote:
 I am trying to construct java object and assign it's fields from a map.
 That is given Java object of class Something { long id; String name; }
 and Clojure map {:id 12, :name "Impostor"}
 I would like to set fields of java object to respective values from map.

 Now, this works
 (let [o (Something.)]
   (set! (. o :id) 12)
   (set! (. o :name) "Impostor")
   o)

 But as soon as I use some value to get field expression compiler
 starts complaining "Invalid assignment target".
 that is
 (let [o (Something.)
        ff :id]
   (set! (. o ff) 12)
   o)
 I do not understand why this problem occurs. Any variations that I
 tried to made it work do not do the trick.
 Including weird (or ridiculous) ones like (set! (. o (symbol (str ":"
 (name ff))) 12)

 I suspect that this has something to do with compiler that needs field
 names at compile time but Clojure could use reflection for this...

 Can anyone point to what is wrong here?

 By the way is there already some function that allows to set fields of
 an object from a map?
>>>
>>> Clojure *could* use reflection to do this...unless your object had a
>>> field named ff! It has to decide at compile time how to look up a
>>> field, and at that time it doesn't know your object won't have a .ff
>>> field, so it figures, sure, I'll set the ff field.
>>>
>>> If you really want to do this (hint: you don't), you can manually deal
>>> with the reflection that the compiler would generate, as Shantanu
>>> outlines.
>>
>> Could you elaborate on this? What would you use instead in this case?
>> My motivation is need to construct list of Java objects and I would
>> like to have some concise syntax to write them. So I decided to do
>> this with maps.
>> I wrote a function that acts as constructor. But long list of
>>
>> (set! (. obj :aa) (:aa props))
>> (set! (. obj :bb) (:bb props))
>> (set! (. obj :cc) (:cc props))
>> (set! (. obj :dd) (:dd props))
>>
>> looks not very lispy. Maybe I should use macros instead?
>
> Untested! But should give a general idea how to do this sort of thing:
>
> (defmacro defsetter [class keys]
>  (let [o (gensym)
>        p (gensym)]
>    `(defn ~(symbol (str "set-" (.toLowercase (str class
>       [~o ~p]
>       ~@(map
>           (fn [k]
>             `(set! (. ~o ~k) (~k ~p)))
>           keys
>
> (defsetter Foo [:a :b])
>
> (set-foo a-foo {:a 0 :b 42})
>
> (defsetter Bar [:x :y :z])
>
> (ser-bar a-bar {:x 4 :y 8 :z 15})
>
> --
> 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.
>

I tried this since I have not used macroses for real problem so far.
And it actually works.
But I do not understand why it works.
I have class:
class Foo {
public String s;
public int v;
public String toString()  { return "{" + s + "," + v + "}"; }
}

Then in Clojure:
 (defsetter abcde [:s :v])
 (let [afoo (actialpackage.Foo.)]
   (set-abcde afoo {:s "S" :v 42})
   (println afoo))

But at the moment  (defsetter abcde [:s :v]) is expanded nothing is
known about actual class.
So it is not clear to me why this works but giving field names at
runtime does not.

Can anyone clarify this?
Maybe this wokrs because in this case compiler can infer type of java
object at compile time?

-- 
Petr Gladkikh

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

[Sean Corfield]

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

Re: ClojureQL: consistent select queries?

[Sean Corfield]

On Fri, Jul 29, 2011 at 5:07 AM, László Török  wrote:
> I'll probably resort to clojure.contrib.sql for now.

You mean clojure.java.jdbc I hope? :)

That's the updated version of c.c.sql and it's compatible with both
Clojure 1.2 and 1.3. If you hit any problems or think of any useful
enhancements, please open tickets on JIRA or let me know:

http://dev.clojure.org/jira/browse/JDBC
-- 
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: Java object field access

[Ken Wesson]

On Sat, Jul 30, 2011 at 1:00 AM, Petr Gladkikh  wrote:
> I tried this since I have not used macroses for real problem so far.
> And it actually works.
> But I do not understand why it works.
> I have class:
> class Foo {
>    public String s;
>    public int v;
>    public String toString()  { return "{" + s + "," + v + "}"; }
> }
>
> Then in Clojure:
>  (defsetter abcde [:s :v])
>  (let [afoo (actialpackage.Foo.)]
>   (set-abcde afoo {:s "S" :v 42})
>   (println afoo))
>
> But at the moment  (defsetter abcde [:s :v]) is expanded nothing is
> known about actual class.
> So it is not clear to me why this works but giving field names at
> runtime does not.
>
> Can anyone clarify this?
> Maybe this wokrs because in this case compiler can infer type of java
> object at compile time?

The macro expands into field-accessing code. If the compiler infers
the type, this becomes fast bytecode to access the fields. Otherwise
it becomes slowish reflection calls, but still works.

-- 
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: ClojureQL: consistent select queries?

[László Török]

Hi,

thanks for the pointer, I thought clojure.java.jdbc is 1.3 only. :)

Las

2011/7/30 Sean Corfield 

> On Fri, Jul 29, 2011 at 5:07 AM, László Török  wrote:
> > I'll probably resort to clojure.contrib.sql for now.
>
> You mean clojure.java.jdbc I hope? :)
>
> That's the updated version of c.c.sql and it's compatible with both
> Clojure 1.2 and 1.3. If you hit any problems or think of any useful
> enhancements, please open tickets on JIRA or let me know:
>
> http://dev.clojure.org/jira/browse/JDBC
> --
> 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




-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

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