Re: Array of primitives

2009-04-02 Thread David Nolen
you should look into float-array and friends.

On Fri, Apr 3, 2009 at 12:04 AM, Sean  wrote:

>
> I'm working with AWT, and there is a method that requires a float[]
> (The java.awt.BasicStroke constructor).  Is it possible to directly
> create an array of primitives directly in Clojure, or do I need to
> create a utility class in Java?
> >
>

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



Array of primitives

2009-04-02 Thread Sean

I'm working with AWT, and there is a method that requires a float[]
(The java.awt.BasicStroke constructor).  Is it possible to directly
create an array of primitives directly in Clojure, or do I need to
create a utility class in Java?
--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

Maven2 is atrocious for big Java projects.  Lots of people have had
the same experience you mentioned. In fact the first few lines of the
readme on my clojure pom project on github says "Dont run away with
your hair on fire" :) Give it a try. It is really simple.

I think I'll give Ant + Ivy another run tonight.  I truly am after the
best KISS dependency/package management solution  and not trying to
push maven.

On Apr 2, 3:10 pm, Korny Sietsma  wrote:
> On Fri, Apr 3, 2009 at 4:39 AM, dysinger  wrote:
> > The Java world for good or bad has rallied
> > around maven repos.  There are 10s of thousands of libs "up in there".
>
> While there are lots of Java / Maven users, there are also a lot who *don't*
> use it, and indeed many who actively avoid stuff that is locked in to Maven
> and it's associated complexity.  It's popular, yes, but I'd debate that the
> Java world has "rallied around" maven...
>
> My workplace (200-ish developers) is mostly Java based, and we used to use
> Maven 1 for a few core projects, went through some pain trying to move them
> to Maven 2, gave up, and have been quite happy since then working with Ivy
> and Ant.
>
> I'm sure maven has a lot of benefits in many workplaces, and I'm sure it's
> more stable and reliable than it was when Maven 2 was brand new :-}  But
> personally, I still get post-traumatic flashbacks whenever I see the words
> "simple" and "maven" in the same sentence :)
>
> - Korny
>
> --
> Kornelis Sietsma  korny at my surname dot com
> "Every jumbled pile of person has a thinking part
> that wonders what the part that isn't thinking
> isn't thinking of"
--~--~-~--~~~---~--~~
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
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: Fresh Clojure Tutorial

2009-04-02 Thread e
On Tue, Mar 31, 2009 at 8:17 PM, Laurent PETIT wrote:

> Yes, you're certainly right, but I'm only 35 old, and I don't want to yet
> let my dreams behind me, given that I will certainly (I hope so!) play at
> least 35 more years in this industry :-)
>
> I was thinking about an approach that would leverage the kind of separation
> one can find in the industry such as GUI stuff in one file, backend stuff in
> another, but maybe reconciled thanks to judicious use of higher order
> functions and conscienscious application of macros.
>
> Something that can be thought of as "workable specs" for the GUI, where one
> does not have to switch language from one abstraction level to the other.
>

I guess we are being warned about some kind of hunt for perpetual motion or
"cold fusion" (maybe I can't use that analogy now -
http://www.newscientist.com/article/dn16820) ...

but this doesn't seem that far fetched.  Instead of looking up the docs
while you make an application.  write the GUI code how you would want it to
work  and then fix the errors until it is legal code with the desired
result.  Then person b tries to use it, and proposes some tweaks that work
for the new app and the original app (or shows how to tweak the original
app).  etc. (in theory)

--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

I said that the java world has rallied around maven _repos_.

Ivy uses maven repos. So your 200 developers _have_ in fact embraced
maven repos like most people. It is the only package repository game
in town. :)

I think Ant + Ivy is a very nice solution for Java. If there was a DRY
way to adapt it to multi-module clojure I would try that too.  I think
"Ties" is probably closure to what I want though, if it were brought
up to date.

On Apr 2, 3:10 pm, Korny Sietsma  wrote:
> On Fri, Apr 3, 2009 at 4:39 AM, dysinger  wrote:
> > The Java world for good or bad has rallied
> > around maven repos.  There are 10s of thousands of libs "up in there".
>
> While there are lots of Java / Maven users, there are also a lot who *don't*
> use it, and indeed many who actively avoid stuff that is locked in to Maven
> and it's associated complexity.  It's popular, yes, but I'd debate that the
> Java world has "rallied around" maven...
>
> My workplace (200-ish developers) is mostly Java based, and we used to use
> Maven 1 for a few core projects, went through some pain trying to move them
> to Maven 2, gave up, and have been quite happy since then working with Ivy
> and Ant.
>
> I'm sure maven has a lot of benefits in many workplaces, and I'm sure it's
> more stable and reliable than it was when Maven 2 was brand new :-}  But
> personally, I still get post-traumatic flashbacks whenever I see the words
> "simple" and "maven" in the same sentence :)
>
> - Korny
>
> --
> Kornelis Sietsma  korny at my surname dot com
> "Every jumbled pile of person has a thinking part
> that wonders what the part that isn't thinking
> isn't thinking of"
--~--~-~--~~~---~--~~
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
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 interoperability and Clojure

2009-04-02 Thread Stuart Halloway

Hi Geoff,

You should have no trouble using setAccessible.  There are several  
demos of this in the source code for the book [1] that use  
setAccessible to check private fields in a unit test. (See lancet/test/ 
step-2-complete.clj [2], for instance).

Hope this helps,
Stu

[1] http://github.com/stuarthalloway/programming-clojure/tree/master
[2] 
http://github.com/stuarthalloway/programming-clojure/blob/401f348b53ddf8ba9b90a445981a134c5eb20783/lancet/test/step_2_complete.clj

>
> What are the limitations of Clojure and Java interoperability? Are
> they clearly stated somewhere?
>
> I have been experimenting with using Clojure to test some existing
> Java code (being able to do so makes a convincing argument to use it
> where I work) and I've noticed that there doesn't seem to be any way
> to call or access package-protected methods or fields -- either that
> or I'm doing something wrong. :)
>
> I've also been trying use the java.lang.reflect capabilities (such as
> setAccessible() in java.lang.reflect.AccessbileObject) and noticed
> that they do not have an effect. How much can be done using those
> libraries within Clojure to affect Java code?
>
> Any information provided would be most helpful.  Being able to use
> Clojure to write tests for existing Java code (that extensively
> employs package-protected methods and fields) would be a nice way to
> demonstrate Clojure's capabilities to some people I work with.
>
> >


--~--~-~--~~~---~--~~
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
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: doseq vs. map

2009-04-02 Thread Sean

Thanks for the response everyone!  I was able to get it working.  If I
understand what everyone is saying, the following statement is true:

In Clojure, laziness is the rule not the exception.



On Apr 2, 10:29 pm, Matt Revelle  wrote:
> Were you in #clojure earlier?  This came up there and pjstadig and I
> raced to implement "domap" and then slashus2 pointed out there was no
> need for it to be a macro.
>
> http://gist.github.com/89249
>
> (defn domap
>   "A map for side-effects.  The argument order is the same as map, but
> unlike map the function results are not retained.  Takes a function
> followed by any number of collections and applies the function to the
> first item in each coll, then the second etc.  Returns nil."
>   [fn & colls]
>   (let [num-colls (count colls)]
>     (doseq [args (partition num-colls (apply interleave colls))]
>       (apply fn args
>
> On Apr 2, 10:20 pm, Daniel Jomphe  wrote:
>
> > Daniel Jomphe wrote:
> > > Basically, since your map wasn't needed, it wasn't "realized"/
> > > executed. Laziness.
>
> > Better said:
>
> > Basically, since your map's results weren't used, it wasn't
> > "realized"/
> > evaluated. That's why you didn't see your expected side effects.
> > Laziness.
--~--~-~--~~~---~--~~
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
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: doseq vs. map

2009-04-02 Thread Matt Revelle

Were you in #clojure earlier?  This came up there and pjstadig and I
raced to implement "domap" and then slashus2 pointed out there was no
need for it to be a macro.

http://gist.github.com/89249

(defn domap
  "A map for side-effects.  The argument order is the same as map, but
unlike map the function results are not retained.  Takes a function
followed by any number of collections and applies the function to the
first item in each coll, then the second etc.  Returns nil."
  [fn & colls]
  (let [num-colls (count colls)]
(doseq [args (partition num-colls (apply interleave colls))]
  (apply fn args

On Apr 2, 10:20 pm, Daniel Jomphe  wrote:
> Daniel Jomphe wrote:
> > Basically, since your map wasn't needed, it wasn't "realized"/
> > executed. Laziness.
>
> Better said:
>
> Basically, since your map's results weren't used, it wasn't
> "realized"/
> evaluated. That's why you didn't see your expected side effects.
> Laziness.
--~--~-~--~~~---~--~~
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
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 interoperability and Clojure

2009-04-02 Thread Rayne

As far as I know, there is no limit.

On Apr 2, 11:22 am, Geoff Wozniak  wrote:
> What are the limitations of Clojure and Java interoperability? Are
> they clearly stated somewhere?
>
> I have been experimenting with using Clojure to test some existing
> Java code (being able to do so makes a convincing argument to use it
> where I work) and I've noticed that there doesn't seem to be any way
> to call or access package-protected methods or fields -- either that
> or I'm doing something wrong. :)
>
> I've also been trying use the java.lang.reflect capabilities (such as
> setAccessible() in java.lang.reflect.AccessbileObject) and noticed
> that they do not have an effect. How much can be done using those
> libraries within Clojure to affect Java code?
>
> Any information provided would be most helpful.  Being able to use
> Clojure to write tests for existing Java code (that extensively
> employs package-protected methods and fields) would be a nice way to
> demonstrate Clojure's capabilities to some people I work with.
--~--~-~--~~~---~--~~
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
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: doseq vs. map

2009-04-02 Thread Daniel Jomphe

Daniel Jomphe wrote:
> Basically, since your map wasn't needed, it wasn't "realized"/
> executed. Laziness.

Better said:

Basically, since your map's results weren't used, it wasn't
"realized"/
evaluated. That's why you didn't see your expected side effects.
Laziness.
--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Dmitri

yeah I definitely agree that it would be nice if constants could be
used without the parens.

On Apr 2, 11:48 am, Paul Stadig  wrote:
> Yeah that works the same as defining a function, just more explicit. I was
> looking for a way to define a constant and just use it as "my-const" without
> having to use the parens to call a function or a macro. I guess that would
> be something like a symbol macro in CL?
>
> Paul
>
> On Thu, Apr 2, 2009 at 11:08 AM, MikeM wrote:
>
>
>
> > There is definline which seems appropriate in place of the constant
> > macros.
>
> > (definline my-const [] 1)
> > (my-const) ;= 1
--~--~-~--~~~---~--~~
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
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: doseq vs. map

2009-04-02 Thread Daniel Jomphe

>From map's docstring: "Returns a lazy sequence [...]"

So I guess you applied map at the top level and wondered why side-
effects didn't happen.

Try:

  (dorun (map #(form-with-side-effects %) a-list))

Or, for fun:

  (take 1 (map #(form-with-side-effects %))

Basically, since your map wasn't needed, it wasn't "realized"/
executed. Laziness.

Sean wrote:
> What I don't understand is why the
> doseq macro is required instead of the mapping operation.  Could
> somebody explain why Clojure has this different form for functions
> that have side effects?

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Dmitri

nifty :)

On Apr 2, 5:10 pm, Raffael Cavallaro 
wrote:
> If you change the color constructor you can get some nice color
> effects:
>
> (. setColor (let [scaled (Math/round (* value color-scale))]
>                      (Color.   255 (- 255 scaled) scaled)))
>
> will give you yellow and magenta for example
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---



doseq vs. map

2009-04-02 Thread Sean

Hi everyone,
I'm working with awt to do create an image renderer.  This is
obviously an application where side effects are desired.  My first
attempt was this:

(map #(form-with-side-effects %) a-list)

This didn't do what I expected.  After a little while, I found the
doseq macro.  I re-wrote my code like this:

(doseq [atom a-list]
  (form-with-side-effects atom))

And now everything works great.  What I don't understand is why the
doseq macro is required instead of the mapping operation.  Could
somebody explain why Clojure has this different form for functions
that have side effects?

Sean


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



How do you parse xml files with different encodings?

2009-04-02 Thread Daniel Jomphe

Let's say I have this file to parse:

  
  Québécois français

I spent many hours trying different ways of doing it, but still
haven't found one. Here are probably my best attempts:

  (def n "ISO-8859-1")

  (defmacro with-out-encoded [encoding & body]
`(binding [*out* (java.io.OutputStreamWriter. System/out
~encoding)]
  ~...@body))

  (:content (clojure.xml/parse "french.xml"))
  ; ["Québécois français"]

  (with-out-encoded n
(:content (clojure.xml/parse "french.xml")))
  ; ["Québécois français"]

  (with-out-encoded n
(let [x (org.xml.sax.InputSource. (java.io.FileInputStream.
"french.xml"))]
   (do
 (.setEncoding x n)
 (:content (clojure.xml/parse x)
  ; ["Québécois français"]

Some xml files appear different when I run them through these lines;
this one does not. In all cases, though, I don't get what's really
expected.

How would go about 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
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
-~--~~~~--~~--~--~---



Lisp web book proposal for O'Reilly

2009-04-02 Thread Vladimir Sedach

Hi,

At ILC 2009, O'Reilly Media released a statement that they were
soliciting proposals for books about Lisp. This is a reversal of their
previous policy that explicitly stated that they were not interested
in publishing Lisp books. I'm planning to put together a proposal for
a book about web development in Lisp and am looking for contributors.

Here is the description of the project:

The book is going to be the "Lisp Web Development Cookbook," with many
authors contributing chapters/recipes. It makes sense to break it down
into several larger sections, for example one on using frameworks and
Hunchentoot, one on generating and transforming JavaScript, one on CPS
transformer tools, and a section on Clojure, and possibly Scheme. The
focus is going to be on advice and techniques from people who have
built public or commercial web systems in Lisp, and to demonstrate
Lisp techniques that aren't possible using other tools.

I want this book to really show how Lisp can be used to build up
abstractions to program in the problem domain directly in ways that
are not possible in other languages, with techniques and examples from
real-world Lisp web systems.

If you are interested in contributing a chapter or recipe (doesn't
matter how short it is, half a page is ok if it does something cool),
please let me know what you'd like to write about. If you know someone
who might be interested in contributing, please pass this on.

I'm going to be soliciting potential contributors for the next two
weeks. Once I have a list of prospective contributors, I'll put
together a list of the subjects covered and an outline of the sections
of the book, and send a proposal to O'Reilly.

Thank you,
Vladimir Sedach

--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Korny Sietsma
On Fri, Apr 3, 2009 at 4:39 AM, dysinger  wrote:

> The Java world for good or bad has rallied
> around maven repos.  There are 10s of thousands of libs "up in there".


While there are lots of Java / Maven users, there are also a lot who *don't*
use it, and indeed many who actively avoid stuff that is locked in to Maven
and it's associated complexity.  It's popular, yes, but I'd debate that the
Java world has "rallied around" maven...

My workplace (200-ish developers) is mostly Java based, and we used to use
Maven 1 for a few core projects, went through some pain trying to move them
to Maven 2, gave up, and have been quite happy since then working with Ivy
and Ant.

I'm sure maven has a lot of benefits in many workplaces, and I'm sure it's
more stable and reliable than it was when Maven 2 was brand new :-}  But
personally, I still get post-traumatic flashbacks whenever I see the words
"simple" and "maven" in the same sentence :)

- Korny

-- 
Kornelis Sietsma  korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"

--~--~-~--~~~---~--~~
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
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 + Terracotta Update

2009-04-02 Thread Jeffrey Straszheim
You're doing amazing work!  I look forward to the result.

On Thu, Apr 2, 2009 at 5:37 PM, Paul Stadig  wrote:

> I've been speaking with the Terracotta engineers, so here is an update on a
> couple of the issues:
>
> 1) array.clone(). It turns out this is a bug in Terracotta. They have
> acknowledged it, and will be working to resolve it. However, they mentioned
> (as I have found else where on the interweb[1][2]) that arraycopy is
> slightly faster than array.clone(), though nothing to write home about, so
> it may be worth rolling that change back into Clojure, or at least it won't
> hurt.
>
> 2) AtomicReference. They seem to think that adding support for AR in
> Terracotta is low hanging fruit for someone who wants to write a patch, and
> somehow they roped me into doing it. ;)
>
> 3) Boolean.TRUE != Boolean.TRUE across VMs. This also is a bug that they
> are working to resolve.
>
> So it looks like three of the biggest issues I had to work around in
> getting Clojure to work with Terracotta, will be resolved on the Terracotta
> side. This means that the Terracotta Integration Module that I wrote[3] will
> pretty much boil down to a configuration file.
>
> I think the only other *serious* issue is the problem with *in*, *out*, and
> *err*. Either they need to be made into "special" vars, or derefed
> specially, because their root values cannot be put into the TC cluster.
>
> That's all folks!
>
>
> Paul
>
> [1]
> http://groups.google.com/group/comp.lang.java.programmer/msg/f63fdf8da28004f0
> [2] http://www.javapractices.com/topic/TopicAction.do?Id=3
> [3] http://github.com/pjstadig/tim-clojure-1.0-snapshot/tree/master
>
>
> On Mon, Mar 30, 2009 at 7:38 PM, Rich Hickey  wrote:
>
>>
>>
>>
>> On Mar 30, 5:12 pm, Paul Stadig  wrote:
>> > I have gotten to the point in my Clojure + Terracotta experiment, where
>> I
>> > believe all of the features of Clojure are functional (Refs, Atoms,
>> > transactions, etc.). I do not have a way to extensively test the Clojure
>> > functionality, but I have run the clojure.contrib.test-clojure test
>> suites
>> > successfully, as well as some simple tests on my machine.
>> >
>> > There are still some open issues (though not necessarily deal killers),
>> and
>> > given the limited extent to which I have tested this, I would not
>> consider
>> > this production quality in the least. I would welcome help from the
>> Clojure
>> > community in testing this integration module. I'm sure there are
>> unexplored
>> > corners.
>> >
>> > Being that several of the changes are relatively trivial, they could be
>> > easily integrated back into the Clojure core. I have detailed as best as
>> > possible the changes I had to make to Clojure in this report: Clojure +
>> > Terracotta Integration Report
>> > (http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv)<
>> http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv>It
>> > is very possible that I have misunderstood things, so if there is a
>> > better way to accomplish any of the solutions, then let me know.
>> >
>> > I would welcome any comments, feedback, etc.
>> >
>>
>> Thanks for the detailed report! I'll look through it soon.
>>
>> Rich
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

It's not hard to add a pom.xml to a project that is not maven
enabled.  I did it for clojure and clojure-contrib in 2 minutes
total.  If it's a git project you can just include them in as a
submodule (or ftree in hg or svn externals in svn) and setup up multi-
module builds.

Clojure "Ties" would be probably pretty easy to resurrect.  That's
what I want. http://bitbucket.org/achimpassen/clojure-ties/overview/
It's broken right now pretty badly but I bet someone could fix it up
again.

On Apr 2, 11:56 am, Laurent PETIT  wrote:
> Hello,
>
> 2009/4/2 Jason Sankey 
>
>
>
>
>
> > Laurent PETIT wrote:
> > > Hi,
>
> > > 2009/4/2 Jason Sankey mailto:ja...@zutubi.com>>
>
> > >     Ivy [ ... ] also supports pluggable resolvers, so
> > >     you can host your Jars/dependency information in multiple ways.
>
> > > Does that mean one could write resolvers to automagically get libraries
> > > from "source" repositories such as github, bitbucket, ... (as long as a
> > > minimal standard convention for the repositories layout is followed) ?
>
> > > Clearly identified versions could be directly mapped to tagged branches,
> > > and SNAPSHOT versions to the HEAD  branch ?
>
> > > This could be really cool ! :-)
>
> > I certainly think this is possible.  Are you talking about building from
> > the source on demand, or having jars stored in the repositories?  It
> > sounds like the former, in which case I'm not sure if this would be an
> > efficient way to do it.
>
> Honestly, I was talking about the former, thinking that once the library is
> recompiled once it could be cached in a local repo for future uses.
>
> I thought about it because it seems to be the solution that demands the
> least from the library developer: no need to subscribe to an external
> repository hosting provider for each and every library he makes. But the
> second solution is certainly and interesting one, given that some people
> seem to already have the proper infrastructure for it! :-)
>
>
>
> > Instead, you can just have a build server that builds the projects on
> > every change, and publishes the jars to a repository.  Apart from the
> > efficiency of building only once, the jars would only be published on a
> > successful build/test.  This is what I have set up now for clojure and
> > clojure-contrib onhttp://pulse.zutubi.com/, where the jars go to an
> > internal Ivy repository.  I believe Howard Lewis Ship also has a build
> > server that builds clojure only and publishes it to a Maven repository.
>
> > I'm happy to expand pulse.zutubi.com if people find it useful to other
> > clojure projects, and work on the features of the internal repository.
>
> > Cheers,
> > Jason
>
> > --
> > Pulse - Continuous Integration made easy.
> > Does your project have a pulse?
> > Try it free at:http://zutubi.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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Laurent PETIT
Hello,

2009/4/2 Jason Sankey 

>
> Laurent PETIT wrote:
> > Hi,
> >
> > 2009/4/2 Jason Sankey mailto:ja...@zutubi.com>>
> >
> > Ivy [ ... ] also supports pluggable resolvers, so
> > you can host your Jars/dependency information in multiple ways.
> >
> >
> > Does that mean one could write resolvers to automagically get libraries
> > from "source" repositories such as github, bitbucket, ... (as long as a
> > minimal standard convention for the repositories layout is followed) ?
> >
> > Clearly identified versions could be directly mapped to tagged branches,
> > and SNAPSHOT versions to the HEAD  branch ?
> >
> > This could be really cool ! :-)
>
> I certainly think this is possible.  Are you talking about building from
> the source on demand, or having jars stored in the repositories?  It
> sounds like the former, in which case I'm not sure if this would be an
> efficient way to do it.


Honestly, I was talking about the former, thinking that once the library is
recompiled once it could be cached in a local repo for future uses.

I thought about it because it seems to be the solution that demands the
least from the library developer: no need to subscribe to an external
repository hosting provider for each and every library he makes. But the
second solution is certainly and interesting one, given that some people
seem to already have the proper infrastructure for it! :-)


>
>
> Instead, you can just have a build server that builds the projects on
> every change, and publishes the jars to a repository.  Apart from the
> efficiency of building only once, the jars would only be published on a
> successful build/test.  This is what I have set up now for clojure and
> clojure-contrib on http://pulse.zutubi.com/, where the jars go to an
> internal Ivy repository.  I believe Howard Lewis Ship also has a build
> server that builds clojure only and publishes it to a Maven repository.
>
> I'm happy to expand pulse.zutubi.com if people find it useful to other
> clojure projects, and work on the features of the internal repository.
>
> Cheers,
> Jason
>
> --
> Pulse - Continuous Integration made easy.
> Does your project have a pulse?
> Try it free at: http://zutubi.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
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 + Terracotta Update

2009-04-02 Thread Paul Stadig
I've been speaking with the Terracotta engineers, so here is an update on a
couple of the issues:

1) array.clone(). It turns out this is a bug in Terracotta. They have
acknowledged it, and will be working to resolve it. However, they mentioned
(as I have found else where on the interweb[1][2]) that arraycopy is
slightly faster than array.clone(), though nothing to write home about, so
it may be worth rolling that change back into Clojure, or at least it won't
hurt.

2) AtomicReference. They seem to think that adding support for AR in
Terracotta is low hanging fruit for someone who wants to write a patch, and
somehow they roped me into doing it. ;)

3) Boolean.TRUE != Boolean.TRUE across VMs. This also is a bug that they are
working to resolve.

So it looks like three of the biggest issues I had to work around in getting
Clojure to work with Terracotta, will be resolved on the Terracotta side.
This means that the Terracotta Integration Module that I wrote[3] will
pretty much boil down to a configuration file.

I think the only other *serious* issue is the problem with *in*, *out*, and
*err*. Either they need to be made into "special" vars, or derefed
specially, because their root values cannot be put into the TC cluster.

That's all folks!


Paul

[1]
http://groups.google.com/group/comp.lang.java.programmer/msg/f63fdf8da28004f0
[2] http://www.javapractices.com/topic/TopicAction.do?Id=3
[3] http://github.com/pjstadig/tim-clojure-1.0-snapshot/tree/master

On Mon, Mar 30, 2009 at 7:38 PM, Rich Hickey  wrote:

>
>
>
> On Mar 30, 5:12 pm, Paul Stadig  wrote:
> > I have gotten to the point in my Clojure + Terracotta experiment, where I
> > believe all of the features of Clojure are functional (Refs, Atoms,
> > transactions, etc.). I do not have a way to extensively test the Clojure
> > functionality, but I have run the clojure.contrib.test-clojure test
> suites
> > successfully, as well as some simple tests on my machine.
> >
> > There are still some open issues (though not necessarily deal killers),
> and
> > given the limited extent to which I have tested this, I would not
> consider
> > this production quality in the least. I would welcome help from the
> Clojure
> > community in testing this integration module. I'm sure there are
> unexplored
> > corners.
> >
> > Being that several of the changes are relatively trivial, they could be
> > easily integrated back into the Clojure core. I have detailed as best as
> > possible the changes I had to make to Clojure in this report: Clojure +
> > Terracotta Integration Report
> > (http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv)<
> http://docs.google.com/Doc?id=dg7c7v49_241g5t8tqsv>It
> > is very possible that I have misunderstood things, so if there is a
> > better way to accomplish any of the solutions, then let me know.
> >
> > I would welcome any comments, feedback, etc.
> >
>
> Thanks for the detailed report! I'll look through it soon.
>
> Rich
>
> >
>

--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Jason Sankey

Laurent PETIT wrote:
> Hi,
> 
> 2009/4/2 Jason Sankey mailto:ja...@zutubi.com>>
> 
> Ivy [ ... ] also supports pluggable resolvers, so
> you can host your Jars/dependency information in multiple ways.
> 
> 
> Does that mean one could write resolvers to automagically get libraries 
> from "source" repositories such as github, bitbucket, ... (as long as a 
> minimal standard convention for the repositories layout is followed) ?
> 
> Clearly identified versions could be directly mapped to tagged branches, 
> and SNAPSHOT versions to the HEAD  branch ?
> 
> This could be really cool ! :-)

I certainly think this is possible.  Are you talking about building from 
the source on demand, or having jars stored in the repositories?  It 
sounds like the former, in which case I'm not sure if this would be an 
efficient way to do it.

Instead, you can just have a build server that builds the projects on 
every change, and publishes the jars to a repository.  Apart from the 
efficiency of building only once, the jars would only be published on a 
successful build/test.  This is what I have set up now for clojure and 
clojure-contrib on http://pulse.zutubi.com/, where the jars go to an 
internal Ivy repository.  I believe Howard Lewis Ship also has a build 
server that builds clojure only and publishes it to a Maven repository.

I'm happy to expand pulse.zutubi.com if people find it useful to other 
clojure projects, and work on the features of the internal repository.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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
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: speed question

2009-04-02 Thread Raffael Cavallaro

If you change the color constructor you can get some nice color
effects:

(. setColor (let [scaled (Math/round (* value color-scale))]
 (Color.   255 (- 255 scaled) scaled)))

will give you yellow and magenta for example
--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Bradbev

It seems to me that the real solution is that the Clojure compiler
needs to support global constants.  You could probably emulate the
behaviour by rebinding global vars inside the let though.

(def *foo* 100)
(defn bar []
 (let [foo *foo*]
  ...))

Brad

On Apr 2, 7:57 am, Paul Stadig  wrote:
> I think you are right, Brad.
>
> However, I wonder though if there is a better way to define a constant.
> Neither the macro nor function seems clean. I like David's
> wrapping-the-whole-thing-in-a-let, but what if you wanted to access the
> value of "width" in a different file? Would one have to resort to defining a
> Java class (at compile time or runtime)?
>
> Paul
>
> On Thu, Apr 2, 2009 at 10:47 AM, Bradbev  wrote:
>
> > It would seem that macros in this case should not be required.  A
> > normal function that simply returns a constant should get inlined by
> > the JIT.
>
> > Cheers,
> > Brad
--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Laurent PETIT
Hi,

2009/4/2 Jason Sankey 

> Ivy [ ... ] also supports pluggable resolvers, so
> you can host your Jars/dependency information in multiple ways.
>

Does that mean one could write resolvers to automagically get libraries from
"source" repositories such as github, bitbucket, ... (as long as a minimal
standard convention for the repositories layout is followed) ?

Clearly identified versions could be directly mapped to tagged branches, and
SNAPSHOT versions to the HEAD  branch ?

This could be really cool ! :-)

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



Java interoperability and Clojure

2009-04-02 Thread Geoff Wozniak

What are the limitations of Clojure and Java interoperability? Are
they clearly stated somewhere?

I have been experimenting with using Clojure to test some existing
Java code (being able to do so makes a convincing argument to use it
where I work) and I've noticed that there doesn't seem to be any way
to call or access package-protected methods or fields -- either that
or I'm doing something wrong. :)

I've also been trying use the java.lang.reflect capabilities (such as
setAccessible() in java.lang.reflect.AccessbileObject) and noticed
that they do not have an effect. How much can be done using those
libraries within Clojure to affect Java code?

Any information provided would be most helpful.  Being able to use
Clojure to write tests for existing Java code (that extensively
employs package-protected methods and fields) would be a nice way to
demonstrate Clojure's capabilities to some people I work with.

--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

Embracing Maven may sound like madness for a dynamic language when you
are trying to break free from Static Languages Land.  There _ARE_
compelling arguments for using simple maven pom files though.

1 - You get access to repository managers like http://archiva.apache.org/

2 - You get access to automated build tools like https://hudson.dev.java.net/
and http://continuum.apache.org/

3 - IDEs can pick up pom.xml files and "just work"

4 - DRY project structure.  Not reinventing the wheel for every module
you write.

5 - Lots of other reasons.

On Apr 2, 7:39 am, Jason Sankey  wrote:
> Paul Stadig wrote:
> > This works great for Java libraries, but only libraries that are in a
> > maven repo. How hard is it to get code into a repo? What about java
> > libraries not in a maven repo, or clojure code like clojure-json on GitHub?
>
> I don't think it is terribly hard to get in the repo, but there can be lag.
>
> > 1. You could set up your own repo. Ok. Cool, but not the easiest to
> > setup and maintain, plus you need a server.
>
> Actually, many Maven projects end up having to do exactly that, and
> indeed lots of people recommend doing so.  The main reasons are:
>
> 1) Having an external dependency for your build is bad news: e.g. you
> don't want your builds to fail because the Maven repo is down.
> 2) Historically at least the Maven central repository contains projects
> with incorrect dependency information, so you need to correct that
> yourself anyway.
> 3) Just depending on the latest version of a module (or latest of a
> release stream) on the central repository means your build can break due
> to an unforseen external change.  So while it might seem nice to keep
> magically up to date (without changing your own repository/poms) at
> first this is not something that works in practice.
>
> Maintaining your own repository takes work but makes these problems go
> away.  On the flipside you have to ask if this work is yielding enough
> benefit over just getting the jars you need and dropping them in a
> directory.  I think for small projects/companies it won't be, but for
> larger efforts and particularly where you have multiple modules of your
> own with their own interdepencies the balance tips.
>
> > 2. You could install dependencies in your local repo. Cool, if the
> > project happens to be using maven and you can to "mvn install". Uncool,
> > if you have to manually "install" it into your local repo. Also uncool,
> > because I see my local repo more as a cache that can sometimes get
> > crufty and can be cleared out if I need the disk space. Maven *should*
> > be able to re-download my dependencies and put them in my local repo,
> > but not so for these manual workarounds.
>
> In my experience for these other dependencies the trickiest part can be
> figuring out what they in turn depend on, which you have to do either
> way.  Once you know that dropping them into a simple repository is not
> that hard.
>
> If you want to maintain this information that you derived manually, then
> you just can't expect to treat it like a cache.  Keep One True copy
> somewhere, possibly in version control.
>
> > 3. ???
>
> > I'm not trying to be disparaging. If this works for someone, I think it
> > is pretty slick. I'm still of the mind that there could be something
> > better. Something that can pull from a maven repo as needed, but also
> > pull from other sources like github, sourceforge, google code, etc. I'm
> > just spoiled by rubygems. This is an existence proof that there can be a
> > simple way to download and setup dependencies (not without foibles).
>
> Other tools like apt/dpkg also come to mind as solving this reasonably
> well.  I think a key thing in this case is a lot of effort goes into
> maintaining the packages and testing a full "distribution" of them
> together.  This makes the dependency information and stability more
> reliable than the Maven central repo -- but it requires a lot of resources.
>
> > Perhaps if there was a Clojure Maven Repo (CMR) where people could
> > easily get their code distributed, then I would feel satisfied.
>
> Certainly a standardised way to specify your dependencies would be a
> good thing.  I'm not sure it needs to be Maven based -- although
> interoperability with Maven would be a worthy goal.
>
> I am personally a happy Ivy user -- Ivy essentially does the dependency
> management part of Maven but (IMO):
>
> - with more flexibility; and
> - without the rest of the Maven baggage (or features depending on your
> perspective)
>
> Ivy interoperates with Maven, and also supports pluggable resolvers, so
> you can host your Jars/dependency information in multiple ways.
>
> > What happened to the ClojureForge idea from tech.coop
> > ? Did anything come about from that, Drew? Perhaps
> > just hosting CMR with some way to signup for an account to be able to
> > "mvn deploy"?
>
> A central place to at least look for Clojure libraries would be a great
> start.

Re: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Jason Sankey

Paul Stadig wrote:
> This works great for Java libraries, but only libraries that are in a 
> maven repo. How hard is it to get code into a repo? What about java 
> libraries not in a maven repo, or clojure code like clojure-json on GitHub?

I don't think it is terribly hard to get in the repo, but there can be lag.

> 1. You could set up your own repo. Ok. Cool, but not the easiest to 
> setup and maintain, plus you need a server.

Actually, many Maven projects end up having to do exactly that, and 
indeed lots of people recommend doing so.  The main reasons are:

1) Having an external dependency for your build is bad news: e.g. you 
don't want your builds to fail because the Maven repo is down.
2) Historically at least the Maven central repository contains projects 
with incorrect dependency information, so you need to correct that 
yourself anyway.
3) Just depending on the latest version of a module (or latest of a 
release stream) on the central repository means your build can break due 
to an unforseen external change.  So while it might seem nice to keep 
magically up to date (without changing your own repository/poms) at 
first this is not something that works in practice.

Maintaining your own repository takes work but makes these problems go 
away.  On the flipside you have to ask if this work is yielding enough 
benefit over just getting the jars you need and dropping them in a 
directory.  I think for small projects/companies it won't be, but for 
larger efforts and particularly where you have multiple modules of your 
own with their own interdepencies the balance tips.

> 2. You could install dependencies in your local repo. Cool, if the 
> project happens to be using maven and you can to "mvn install". Uncool, 
> if you have to manually "install" it into your local repo. Also uncool, 
> because I see my local repo more as a cache that can sometimes get 
> crufty and can be cleared out if I need the disk space. Maven *should* 
> be able to re-download my dependencies and put them in my local repo, 
> but not so for these manual workarounds.

In my experience for these other dependencies the trickiest part can be 
figuring out what they in turn depend on, which you have to do either 
way.  Once you know that dropping them into a simple repository is not 
that hard.

If you want to maintain this information that you derived manually, then 
you just can't expect to treat it like a cache.  Keep One True copy 
somewhere, possibly in version control.

> 3. ???
> 
> I'm not trying to be disparaging. If this works for someone, I think it 
> is pretty slick. I'm still of the mind that there could be something 
> better. Something that can pull from a maven repo as needed, but also 
> pull from other sources like github, sourceforge, google code, etc. I'm 
> just spoiled by rubygems. This is an existence proof that there can be a 
> simple way to download and setup dependencies (not without foibles).

Other tools like apt/dpkg also come to mind as solving this reasonably 
well.  I think a key thing in this case is a lot of effort goes into 
maintaining the packages and testing a full "distribution" of them 
together.  This makes the dependency information and stability more 
reliable than the Maven central repo -- but it requires a lot of resources.

> Perhaps if there was a Clojure Maven Repo (CMR) where people could 
> easily get their code distributed, then I would feel satisfied.

Certainly a standardised way to specify your dependencies would be a 
good thing.  I'm not sure it needs to be Maven based -- although 
interoperability with Maven would be a worthy goal.

I am personally a happy Ivy user -- Ivy essentially does the dependency 
management part of Maven but (IMO):

- with more flexibility; and
- without the rest of the Maven baggage (or features depending on your 
perspective)

Ivy interoperates with Maven, and also supports pluggable resolvers, so 
you can host your Jars/dependency information in multiple ways.

> What happened to the ClojureForge idea from tech.coop 
> ? Did anything come about from that, Drew? Perhaps 
> just hosting CMR with some way to signup for an account to be able to 
> "mvn deploy"?

A central place to at least look for Clojure libraries would be a great 
start.  If it also hosted those libraries and included standardised 
dependency information, I think it would be helpful whether you just 
wanted to stick the jars in a directory or use a full-blown dependency 
management tool.

Cheers,
Jason

> On Thu, Apr 2, 2009 at 1:25 AM, dysinger  > wrote:
> 
> 
> ...for easy dependency management and no-compile project setup.
> https://github.com/dysinger/clojure-pom/tree
> 
> Using maven only for the dependency management and to create a custom
> repl script allows me to still use emacs/slime for dynamic development
> of clojure code.
> 
> My motivation is 3 fold:
> 
> 1) I have lots of small modules

Re: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

Comments below mixed in...

On Apr 2, 3:35 am, Paul Stadig  wrote:
> This works great for Java libraries, but only libraries that are in a maven
> repo. How hard is it to get code into a repo? What about java libraries not
> in a maven repo, or clojure code like clojure-json on GitHub?
>

You can add the dependency in your pom.  If maven can't find it, it
will show you the one-liner command to manually install the jar and
then you are off to the races. If you want to make it easy on other
people you just whip up a quick pom.xml (like I did for clojure &
clojure-contrib)

> 1. You could set up your own repo. Ok. Cool, but not the easiest to setup
> and maintain, plus you need a server.
>
> 2. You could install dependencies in your local repo. Cool, if the project
> happens to be using maven and you can to "mvn install". Uncool, if you have
> to manually "install" it into your local repo. Also uncool, because I see my
> local repo more as a cache that can sometimes get crufty and can be cleared
> out if I need the disk space. Maven *should* be able to re-download my
> dependencies and put them in my local repo, but not so for these manual
> workarounds.
>
> 3. ???

It's easy enough to work with it. You have several options.  I just
use maven to get the jars that I need in the right place and whip up a
repl script for SLIME with the right classpath.  I only need to call
it one time to do this and then I have the regular src, bin, lib, etc
dirs in my project ready to roll - all generated from a 20-ish line
pom file.

>
> I'm not trying to be disparaging. If this works for someone, I think it is
> pretty slick. I'm still of the mind that there could be something better.

I agree.  I would like to see an all Clojure builder like Buildr or
Ties that can use maven repos but doesn't require XML files.

> Something that can pull from a maven repo as needed, but also pull from
> other sources like github, sourceforge, google code, etc. I'm just spoiled

That's hard to do if the projects don't all adapt the same layout and
dependency management.  The Java world for good or bad has rallied
around maven repos.  There are 10s of thousands of libs "up in there".

> by rubygems. This is an existence proof that there can be a simple way to
> download and setup dependencies (not without foibles).
>
> Perhaps if there was a Clojure Maven Repo (CMR) where people could easily
> get their code distributed, then I would feel satisfied.

If you do 'mvn package' or 'mvn install' with my pom it will jar up
your clojure code and you can then write other clojure libs that
depend on the 1st one.

Again I am not a Maven fanatic.  I am just trying to find a way to DRY
the project structure for all my components and also leverage the
bazillion lines of java code out there easily.

>
> What happened to the ClojureForge idea from tech.coop? Did anything come
> about from that, Drew? Perhaps just hosting CMR with some way to signup for
> an account to be able to "mvn deploy"?
>
> Paul
>
> On Thu, Apr 2, 2009 at 1:25 AM, dysinger  wrote:
>
> > ...for easy dependency management and no-compile project setup.
> >https://github.com/dysinger/clojure-pom/tree
>
> > Using maven only for the dependency management and to create a custom
> > repl script allows me to still use emacs/slime for dynamic development
> > of clojure code.
>
> > My motivation is 3 fold:
>
> > 1) I have lots of small modules and want convention over configuration
> > (no boiler plate ant scripts or other such cut and paste)
>
> > 2) I want access to the kabazillion libraries in the maven repos -
> > just go look at mvnrepository.com for example.
>
> > 3) Although I spent 10 years on Java, I am a dynamic language fan.  I
> > don't care or want to AOT compile at the moment. I just want to setup
> > the libraries that my clojure code depends on and start writing /
> > prototyping clojure code in Emacs SLIME.
>
> > I would love to hear some feedback and/or what other people have been
> > working on.
>
> > -Tim
>
>
--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread dysinger

This approach won't get you very far IMHO working on lots of
projects.  At some point you will have conflicts on which library
version you need.

On Apr 1, 8:29 pm, mikel  wrote:
> On Apr 2, 12:27 am, dysinger  wrote:
>
>
>
> > Dogh!  Plz pardon my spelling. :D (embarrassed)
>
> > On Apr 1, 7:25 pm, dysinger  wrote:
>
> > > ...for easy dependency management and no-compile project 
> > > setup.https://github.com/dysinger/clojure-pom/tree
>
> > > Using maven only for the dependency management and to create a custom
> > > repl script allows me to still use emacs/slime for dynamic development
> > > of clojure code.
>
> > > My motivation is 3 fold:
>
> > > 1) I have lots of small modules and want convention over configuration
> > > (no boiler plate ant scripts or other such cut and paste)
>
> > > 2) I want access to the kabazillion libraries in the maven repos -
> > > just go look at mvnrepository.com for example.
>
> > > 3) Although I spent 10 years on Java, I am a dynamic language fan.  I
> > > don't care or want to AOT compile at the moment. I just want to setup
> > > the libraries that my clojure code depends on and start writing /
> > > prototyping clojure code in Emacs SLIME.
>
> > > I would love to hear some feedback and/or what other people have been
> > > working on.
>
> > > -Tim
>
> Personally, I check Clojure and clojure-contrib out of their repos,
> use ant to build them, and use an ultra-simple shell script to start a
> Clojure repl in an environment where the classpath contains references
> to all the library jars I use. The script reads the jars at startup
> time, so all I have to do to add some new library is drop it into the
> right directory (well, I then need to restart Clojure, or manually add
> the newly-added jar to Clojure's classpath).
>
> My "IDE" is good ol' Gnu Emacs with SLIME. That's it, basically. For
> loading projects I use a dirt-simple system loader I knocked together.
--~--~-~--~~~---~--~~
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
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: test-is now supports TAP

2009-04-02 Thread Jason Sankey

Stuart Sierra wrote:
> On Apr 1, 12:21 pm, Jason Sankey  wrote:
>> Out of interest, are you interested in other output formats for test-is?
>>   I chose JUnit compatible as a defacto-standard -- it integrates with
>> the unofficial build server I have been working on as well as many other
>> tools.  I have it working but in need of some tweaks and cleanups.  I am
>> happy to donate the code (contributor agreement is in the mail to Rich)
>> when I clean it up.  It could also easily live outside of test-is as an
>> optional extension, in which case I will probably make it public on GitHub.
> 
> Yes, I would like to have more output formats.  I'd like to keep each
> format in a separate namespace (like I did with the TAP extension) but
> make them all available in clojure-contrib.  Let me know if I can be
> of any help in integrating the JUnit output with test-is.

OK, great.  I will clean up my implementation and make sure it mimics 
the style of the existing one, then I can provide a patch for review. 
My name has hit the contributors page now, so I guess my agreement 
reached Rich intact.

Cheers,
Jason

-- 
Pulse - Continuous Integration made easy.
Does your project have a pulse?
Try it free at: http://zutubi.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
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: Questions about Clojure and Common Lisp

2009-04-02 Thread David Nolen



On Apr 1, 11:41 am, Chanwoo Yoo  wrote:
> Hello. Yesterday, I talked with a representative of a publisher about
> a translation of Lisp books. There are books about Ruby, Lua, Erlang,
> and Groovy in South Korea, but there is no book about Lisp except
> SICP. So he is considering printing the first Lisp book in South
> Korea. We talked about 'Programming Clojure', 'ANSI Common Lisp', and
> 'Practical Common Lisp'. I told him that I slightly prefered
> 'Programming Clojure' to others because of Clojure's support for
> concurrency and java interoperability. I said that the strong points
> of Clojure would make programmers of main stream languages have
> interests in Lisp. And he asked me questions like follows.
>
> 1. Has Clojure become stable?
> He is afraid that the publishing of 'Programming Clojure' would be
> meaningless if Clojure take significant changes after the publishing.
> We know it will change. But the degree is the matter.

Fully lazy sequences was a fairly dramatic internal change, that only
took a few weeks before all the existing libraries had stabilized.  I
know that for my own code it was mostly a search and replace (people
who aggressively used lazy-cons had slightly more work). I think Rich
is pretty good about not changing interfaces.  I'm not sure what else
Rich wants to get in before 1.0, but whatever changes are made, I
believe they will mostly be evolutions and not dramatic changes to the
interface, right? ;)

>
> 2. Could I get any benchmarking data about the performance of Clojure
> and Java?
> I read that Clojure can generate code as fast as Java in 'Programming
> Clojure'. But he worries whether Clojure is slow like Groovy. Could I
> get data about performance comparisons between Clojure and Java on
> several algorithms?

>From the kinds of posts that come up, Clojure is very competitive with
Java in real world contexts. It's definitely the fastest language I've
ever used that is as dynamic as it is.  The only time Clojure seems to
fall behind pure Java is loop heavy operations on Java primitives, but
again, because Clojure integrates so easily with Java, you can
implement the slow parts in Java if you must.  The speed at which you
can produce clear clean code in Clojure vs Java I think more than pays
off for the rare performance differences.

>
> 3. Clojure can use Java libraries. Common Lisp can use C/C++
> libraries. Is it possible to say Clojure has strong points to Common
> Lisp in the power of libraries?

Definitely. But as people have mentioned, since you're not crossing an
FFI the integration is much, much better. One argument for Clojure
over Common Lisp (and Common Lisp is cool) is that Clojure is not just
a modernized Lisp, it is a modernized language period. It deeply
integrates concurrency-  I believe any new language must address this
to be taken seriously from now on- multicore is clearly the way of the
future and other languages require you to find libraries and change
your programming style. Clojure comes out of the box concurrency ready
from its fundamental design.  This was the deal sealer for me.

>
> All these questions are not easy to answer for me. I think I should
> give him the object information. So I hope that I get opinions from
> the community.
--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Paul Stadig
Yeah that works the same as defining a function, just more explicit. I was
looking for a way to define a constant and just use it as "my-const" without
having to use the parens to call a function or a macro. I guess that would
be something like a symbol macro in CL?


Paul

On Thu, Apr 2, 2009 at 11:08 AM, MikeM wrote:

>
> There is definline which seems appropriate in place of the constant
> macros.
>
> (definline my-const [] 1)
> (my-const) ;= 1
>
>
> >
>

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread MikeM

There is definline which seems appropriate in place of the constant
macros.

(definline my-const [] 1)
(my-const) ;= 1


--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Paul Stadig
I think you are right, Brad.

However, I wonder though if there is a better way to define a constant.
Neither the macro nor function seems clean. I like David's
wrapping-the-whole-thing-in-a-let, but what if you wanted to access the
value of "width" in a different file? Would one have to resort to defining a
Java class (at compile time or runtime)?


Paul

On Thu, Apr 2, 2009 at 10:47 AM, Bradbev  wrote:

>
> It would seem that macros in this case should not be required.  A
> normal function that simply returns a constant should get inlined by
> the JIT.
>
> Cheers,
> Brad
>

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Bradbev

It would seem that macros in this case should not be required.  A
normal function that simply returns a constant should get inlined by
the JIT.

Cheers,
Brad

On Apr 2, 5:20 am, Dmitri  wrote:
> Thanks a lot, that's really helpful. I never thought of using a macro
> to define constants
> like that, it's definitely a good trick and it does seem to result in
> the biggest performance
> gain.
>
> On Apr 2, 7:25 am, Paul Stadig  wrote:
>
> > I got it down to about 3 seconds. I did what William said, but the biggest
> > improvement was from changing the way *width*, *height*, and *max-steps*
> > were defined. I noticed that in the Java version they are constants, but in
> > the Clojure version they are Vars which means that inside your tight inner
> > loops you are dereferencing the vars multiple times. Vars are for thread
> > local values, but these values are not expected to change. I'm not sure the
> > best way to make these vars into constants, but I changed them into macros:
>
> > (defmacro *width* [] (float 640))
>
> > Then replaced instances of *width* with (*width*). The macros will get
> > compiled down to floats instead of resulting in multiple Var.deref calls
> > (and probably Number.floatValue calls) per loop iteration.
>
> > Here is the code:
>
> > (ns main
> >  (:import (java.awt Color Container Graphics Canvas Dimension)
> >           (javax.swing JPanel JFrame)
> >           (java.awt.image BufferedImage BufferStrategy)))
>
> > (set! *warn-on-reflection* true)
>
> > (defmacro *width* [] (float 640))
> > (defmacro *height* [] (float 640))
> > (defmacro *max-steps* [] (float 32))
>
> > (defn on-thread [#^Runnable f] (doto (new Thread f) (.start)))
>
> > (defn check-bounds [x y]
> >    (loop [px (float x)
> >           py (float y)
> >           zx (float 0.0)
> >           zy (float 0.0)
> >           zx2 (float 0.0)
> >           zy2 (float 0.0)
> >           value (float 0)]
> >       (if (and (< value (*max-steps*)) (< (+ zx2 zy2) (float 4.0)))
> >            (let [new-zy (float (+ (* (float 2.0) zx zy) py))
> >                  new-zx (float (+ (- zx2 zy2) px))
> >                  new-zx2 (float (* new-zx new-zx))
> >                  new-zy2 (float (* new-zy new-zy))]
> >                  (recur px py new-zx new-zy new-zx2 new-zy2 (inc value)))
> >            (if (== value (*max-steps*)) 0 value
>
> > (defn draw-line [#^Graphics g y]
> >    (let [dy (- 1.25 (* 2.5 (/ y (*height*]
> >      (doseq [x (range 0 (*width*))]
> >        (let [dx (- (* 2.5 (/ x (*width*))) 2.0)]
> >                (let [value (check-bounds dx dy)]
> >                    (if (> value  0)
> >                        (doto g
> >                            (. setColor (Color. (* value (/ 255
> > (*max-steps*)
> >                            (. drawRect x y 0 0
>
> > (defn draw-lines
> >    ([buffer g] (draw-lines buffer g (*height*)))
> >    ([#^BufferStrategy buffer g y]
> >          (doseq [y (range 0 y)]
> >             (draw-line g y)
> >             ;(on-thread (draw-line g y))
> >             (. buffer show
>
> > (defn draw [#^Canvas canvas]
> >    (let [buffer (. canvas getBufferStrategy)
> >          g        (. buffer getDrawGraphics)]
> >          (draw-lines buffer g)))
>
> > (defn main []
>
> >  (let [panel (JPanel.)
> >        canvas (Canvas.)
> >        frame (JFrame. "Mandelbrot")]
>
> >    (doto panel
> >      (.setPreferredSize (Dimension. (*width*) (*height*)))
> >      (.setLayout nil)
> >      (.add canvas))
>
> >    (doto frame
> >      (.setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
> >      (.setBounds 0,0,(*width*) (*height*))
> >      (.setResizable false)
> >      (.add panel)
> >      (.setVisible true))
>
> >    (doto canvas
> >      (.setBounds 0,0,(*width*) (*height*))
> >      (.setBackground (Color/BLACK))
> >      (.createBufferStrategy 2)
> >      (.requestFocus))
>
> >    (draw canvas)))
>
> > (time (main))
>
> > ~$ clojure /tmp/mandelbrot.clj
> > "Elapsed time: 3577.128587 msecs"
>
> > Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Ilya Sergey
Oh, yes. It actually replaces dashes. Never mind. :)

Ilya

2009/4/2 Daniel Jomphe 

>
> Oh, that's it. I think I fiddled with this last week. :\
>
> So now, I've got these working:
>
>  eclipse, intellij
>
> -- NetBeans --
> enclojure still complains contrib isn't on the classpath, whatever I
> do.
>
> -- Emacs --
> No more works since I've pulled emacs-starter-kit's latest changes. 'M-
> x slime' doesn't fire up clojure anymore; slime no more exists, in
> fact. The last commit actually removed clojure-mode.el. Maybe they're
> in the middle of reorganizing some things.
>
> Since I previously had a separate installation of clojure-mode and
> slime, I checked what's new in clojure-mode. Looks like a new 'M-x
> clojure-install' is available, which would be responsible of
> installing clojure.jar, clojure-contrib.jar and slime. Looks really
> neat. Plus, they've removed paredit; maybe they've integrated it
> directly.
>
> --
>
> Overall, I really like what I see. Once I'll have made up a choice,
> I'll probably spend some time contributing. Meanwhile, it's
> exploration time.
>
> Thanks again for everybody's answers. (Of course, suggestions for
> NetBeans and Emacs are still welcome.)
> On Apr 2, 9:12 am, Laurent PETIT  wrote:
> > in order to be compatible with package and java class names, your clojure
> > files must not have the - , so clojure automatically replaces them with
> > underscores _ when searching for a file / folder / package fragment.
> >
> > But inside clojure itself, when you reference the namespace by its
> > symbol/name, you must replace the underscores in the filename by an - ,
> so
> > try :
> >
> >  (ns myns
> >  (:use clojure.contrib.duck-streams))
> >
> > HTH,
> >
> > --
> > Laurent
> >
> > 2009/4/2 Daniel Jomphe 
> >
> >
> >
> > > Thanks to everybody for their (sometimes highly detailed) answers.
> >
> > > -- ECLIPSE --
> > > It's nice that contrib is indeed bundled in clojuredev. Core clojure
> > > works, but I get the following:
> >
> > >  (ns myns
> > >  (:use clojure.contrib.duck_streams))
> >
> > >  ==> [...].Exception: namespace 'clojure.contrib.duck_streams'
> > >   not found after loading '/clojure/contrib/duck_streams'
> >
> > > -- INTELLIJ --
> > > I also got the very same error yesterday in IntelliJ+LaClojure, after
> > > adding contrib's jar.
> >
> > > -- EMACS --
> > > I'm actually a user of emacs-starter-kit, but haven't updated in a
> > > while. If I remember well, when I started using it, I had to install
> > > SLIME and clojure-mode myself, since they weren't yet part of it. I'll
> > > have another shot at it now.
> >
> > > 
> > > I'm suspecting the problem may be with my code, but I took it out of
> > > Stuarts' great book's code samples.
> >
>

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Ilya Sergey
Daniel,

How have you added clojure-contrib.jar to your module? The most common way
to do this is to create global/project/module library, attaching this jat to
it and adding this library to module dependencies. If it doesn't help, could
you provide little example to reproduce it? I guess, this is my bad with
classpath adjustment.

Kind regrads,
Ilya

2009/4/2 Daniel Jomphe 

>
> Thanks to everybody for their (sometimes highly detailed) answers.
>
> -- ECLIPSE --
> It's nice that contrib is indeed bundled in clojuredev. Core clojure
> works, but I get the following:
>
>  (ns myns
>  (:use clojure.contrib.duck_streams))
>
>  ==> [...].Exception: namespace 'clojure.contrib.duck_streams'
>   not found after loading '/clojure/contrib/duck_streams'
>
> -- INTELLIJ --
> I also got the very same error yesterday in IntelliJ+LaClojure, after
> adding contrib's jar.
>
> -- EMACS --
> I'm actually a user of emacs-starter-kit, but haven't updated in a
> while. If I remember well, when I started using it, I had to install
> SLIME and clojure-mode myself, since they weren't yet part of it. I'll
> have another shot at it now.
>
> 
> I'm suspecting the problem may be with my code, but I took it out of
> Stuarts' great book's code samples.
> >
>

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Daniel Jomphe

Oh, that's it. I think I fiddled with this last week. :\

So now, I've got these working:

  eclipse, intellij

-- NetBeans --
enclojure still complains contrib isn't on the classpath, whatever I
do.

-- Emacs --
No more works since I've pulled emacs-starter-kit's latest changes. 'M-
x slime' doesn't fire up clojure anymore; slime no more exists, in
fact. The last commit actually removed clojure-mode.el. Maybe they're
in the middle of reorganizing some things.

Since I previously had a separate installation of clojure-mode and
slime, I checked what's new in clojure-mode. Looks like a new 'M-x
clojure-install' is available, which would be responsible of
installing clojure.jar, clojure-contrib.jar and slime. Looks really
neat. Plus, they've removed paredit; maybe they've integrated it
directly.

--

Overall, I really like what I see. Once I'll have made up a choice,
I'll probably spend some time contributing. Meanwhile, it's
exploration time.

Thanks again for everybody's answers. (Of course, suggestions for
NetBeans and Emacs are still welcome.)
On Apr 2, 9:12 am, Laurent PETIT  wrote:
> in order to be compatible with package and java class names, your clojure
> files must not have the - , so clojure automatically replaces them with
> underscores _ when searching for a file / folder / package fragment.
>
> But inside clojure itself, when you reference the namespace by its
> symbol/name, you must replace the underscores in the filename by an - , so
> try :
>
>  (ns myns
>      (:use clojure.contrib.duck-streams))
>
> HTH,
>
> --
> Laurent
>
> 2009/4/2 Daniel Jomphe 
>
>
>
> > Thanks to everybody for their (sometimes highly detailed) answers.
>
> > -- ECLIPSE --
> > It's nice that contrib is indeed bundled in clojuredev. Core clojure
> > works, but I get the following:
>
> >  (ns myns
> >      (:use clojure.contrib.duck_streams))
>
> >  ==> [...].Exception: namespace 'clojure.contrib.duck_streams'
> >               not found after loading '/clojure/contrib/duck_streams'
>
> > -- INTELLIJ --
> > I also got the very same error yesterday in IntelliJ+LaClojure, after
> > adding contrib's jar.
>
> > -- EMACS --
> > I'm actually a user of emacs-starter-kit, but haven't updated in a
> > while. If I remember well, when I started using it, I had to install
> > SLIME and clojure-mode myself, since they weren't yet part of it. I'll
> > have another shot at it now.
>
> > 
> > I'm suspecting the problem may be with my code, but I took it out of
> > Stuarts' great book's code samples.
--~--~-~--~~~---~--~~
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
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: Ironicly Maven2 is the lightest I could come up with

2009-04-02 Thread Paul Stadig
This works great for Java libraries, but only libraries that are in a maven
repo. How hard is it to get code into a repo? What about java libraries not
in a maven repo, or clojure code like clojure-json on GitHub?

1. You could set up your own repo. Ok. Cool, but not the easiest to setup
and maintain, plus you need a server.

2. You could install dependencies in your local repo. Cool, if the project
happens to be using maven and you can to "mvn install". Uncool, if you have
to manually "install" it into your local repo. Also uncool, because I see my
local repo more as a cache that can sometimes get crufty and can be cleared
out if I need the disk space. Maven *should* be able to re-download my
dependencies and put them in my local repo, but not so for these manual
workarounds.

3. ???

I'm not trying to be disparaging. If this works for someone, I think it is
pretty slick. I'm still of the mind that there could be something better.
Something that can pull from a maven repo as needed, but also pull from
other sources like github, sourceforge, google code, etc. I'm just spoiled
by rubygems. This is an existence proof that there can be a simple way to
download and setup dependencies (not without foibles).

Perhaps if there was a Clojure Maven Repo (CMR) where people could easily
get their code distributed, then I would feel satisfied.

What happened to the ClojureForge idea from tech.coop? Did anything come
about from that, Drew? Perhaps just hosting CMR with some way to signup for
an account to be able to "mvn deploy"?


Paul

On Thu, Apr 2, 2009 at 1:25 AM, dysinger  wrote:

>
> ...for easy dependency management and no-compile project setup.
> https://github.com/dysinger/clojure-pom/tree
>
> Using maven only for the dependency management and to create a custom
> repl script allows me to still use emacs/slime for dynamic development
> of clojure code.
>
> My motivation is 3 fold:
>
> 1) I have lots of small modules and want convention over configuration
> (no boiler plate ant scripts or other such cut and paste)
>
> 2) I want access to the kabazillion libraries in the maven repos -
> just go look at mvnrepository.com for example.
>
> 3) Although I spent 10 years on Java, I am a dynamic language fan.  I
> don't care or want to AOT compile at the moment. I just want to setup
> the libraries that my clojure code depends on and start writing /
> prototyping clojure code in Emacs SLIME.
>
> I would love to hear some feedback and/or what other people have been
> working on.
>
> -Tim
> >
>

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Laurent PETIT
in order to be compatible with package and java class names, your clojure
files must not have the - , so clojure automatically replaces them with
underscores _ when searching for a file / folder / package fragment.

But inside clojure itself, when you reference the namespace by its
symbol/name, you must replace the underscores in the filename by an - , so
try :

 (ns myns
 (:use clojure.contrib.duck-streams))

HTH,

-- 
Laurent


2009/4/2 Daniel Jomphe 

>
> Thanks to everybody for their (sometimes highly detailed) answers.
>
> -- ECLIPSE --
> It's nice that contrib is indeed bundled in clojuredev. Core clojure
> works, but I get the following:
>
>  (ns myns
>  (:use clojure.contrib.duck_streams))
>
>  ==> [...].Exception: namespace 'clojure.contrib.duck_streams'
>   not found after loading '/clojure/contrib/duck_streams'
>
> -- INTELLIJ --
> I also got the very same error yesterday in IntelliJ+LaClojure, after
> adding contrib's jar.
>
> -- EMACS --
> I'm actually a user of emacs-starter-kit, but haven't updated in a
> while. If I remember well, when I started using it, I had to install
> SLIME and clojure-mode myself, since they weren't yet part of it. I'll
> have another shot at it now.
>
> 
> I'm suspecting the problem may be with my code, but I took it out of
> Stuarts' great book's code samples.
> >
>

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Daniel Jomphe

Thanks to everybody for their (sometimes highly detailed) answers.

-- ECLIPSE --
It's nice that contrib is indeed bundled in clojuredev. Core clojure
works, but I get the following:

  (ns myns
  (:use clojure.contrib.duck_streams))

  ==> [...].Exception: namespace 'clojure.contrib.duck_streams'
   not found after loading '/clojure/contrib/duck_streams'

-- INTELLIJ --
I also got the very same error yesterday in IntelliJ+LaClojure, after
adding contrib's jar.

-- EMACS --
I'm actually a user of emacs-starter-kit, but haven't updated in a
while. If I remember well, when I started using it, I had to install
SLIME and clojure-mode myself, since they weren't yet part of it. I'll
have another shot at it now.


I'm suspecting the problem may be with my code, but I took it out of
Stuarts' great book's code samples.
--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread fitzpatrick...@googlemail.com

That did it! I just used the functions that created my-row-data in
place of my-row-data. Thanks very much for the help.
PJ


On Apr 2, 1:34 pm, Laurent PETIT  wrote:
> Difficult without seeing the code.
>
> the idea is to try not storing what is currently in my-row-data anywhere.
>
> So if you can create a function that returns what is currently stored in
> my-row-data, and pass that function to your function t, then the head of
> your sequence will not be retained in any variable, so it can be garbage
> collected while doseq is still working on the rest of the sequence.
>
> Your code could be changed as :
>
> (defn t [filename my-row-data-fn]
>    (with-open [w (java.io.FileWriter. (java.io.File. file-name))]
>        (doseq [l (my-row-data-fn)]
>          (.write w (str (output-array (first l) ",")
>                                                                        "@"
>
>    (output-array (second l) ",")
>
>  "\n")
>
> Hope this helps, if not, you will have to show us more code above the t
> function,
>
> --
> Laurent
>
> 2009/4/2 fitzpatrick...@googlemail.com 
>
>
>
> > Apologies for my ignorance ,i am new to clojure, but can you give an
> > example of what the code should look like. I understand my-row-data is
> > lexical as it defined outside the function but i don't understand how
> > to implement this new function.
> > tks,
> > PJ
>
> > On Apr 2, 1:03 pm, Laurent PETIT  wrote:
> > > You're holding the head, because my-row-data is defined in the lexical or
> > > dynamic scope of the function, and holds the head.
>
> > > Try creating a function returning the seq that is currently stored in
> > > my-row-data and call it instead : (my-row-data)
>
> > > --
> > > Laurent
>
> > > 2009/4/2 fitzpatrick...@googlemail.com 
>
> > > > Hi,
> > > > Thanks for the replies.
>
> > > > I have adapted the code above with my example. I still get the heap
> > > > error!
> > > > my-row-data is the lazy sequence. each element in the seq is a 2
> > > > element vector of Java String[]
> > > > output-array is just a printing function for the String[]. For
> > > > convenience i place a @ between the two outputs.
>
> > > > (defn t [file-name]
> > > >    (with-open [w (java.io.FileWriter. (java.io.File. file-name))]
> > > >        (doseq [l my-row-data]
> > > >          (.write w (str (output-array (first l) ",")
>
> >  "@"
>
> > > >    (output-array (second l) ",")
>
> > > >  "\n")
>
> > > >                                        )
> > > >                                )
> > > >                )
> > > > )
>
> > > > tks,
> > > > PJ
>
> > > > On Apr 2, 12:15 pm, Christian Vest Hansen 
> > > > wrote:
> > > > > On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
>
> > > > >  wrote:
>
> > > > > > Hi,
> > > > > > I am attempting to print a large lazy seq to file. I have attempted
> > > > > > various approaches and obviously am missing something obvious.
> > > > > > I have attempted do use do-seq and also iterated manually through
> > the
> > > > > > sequence but i always come up with the heap error.
> > > > > > Has anyone got any suggestions?
>
> > > > > Don't hold on to the head of the seq.
>
> > > > > It may not be obvious where, but you are most likely holding on the
> > > > > the head of the seq, which prevents the elements from being GC'd as
> > > > > you iterate them.
>
> > > > > > tks,
> > > > > > PJ
>
> > > > > --
> > > > > Venlig hilsen / Kind regards,
> > > > > Christian Vest Hansen.
--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread Laurent PETIT
Difficult without seeing the code.

the idea is to try not storing what is currently in my-row-data anywhere.

So if you can create a function that returns what is currently stored in
my-row-data, and pass that function to your function t, then the head of
your sequence will not be retained in any variable, so it can be garbage
collected while doseq is still working on the rest of the sequence.

Your code could be changed as :

(defn t [filename my-row-data-fn]
   (with-open [w (java.io.FileWriter. (java.io.File. file-name))]
   (doseq [l (my-row-data-fn)]
 (.write w (str (output-array (first l) ",")
   "@"

   (output-array (second l) ",")

 "\n")

Hope this helps, if not, you will have to show us more code above the t
function,

-- 
Laurent

2009/4/2 fitzpatrick...@googlemail.com 

>
> Apologies for my ignorance ,i am new to clojure, but can you give an
> example of what the code should look like. I understand my-row-data is
> lexical as it defined outside the function but i don't understand how
> to implement this new function.
> tks,
> PJ
>
> On Apr 2, 1:03 pm, Laurent PETIT  wrote:
> > You're holding the head, because my-row-data is defined in the lexical or
> > dynamic scope of the function, and holds the head.
> >
> > Try creating a function returning the seq that is currently stored in
> > my-row-data and call it instead : (my-row-data)
> >
> > --
> > Laurent
> >
> > 2009/4/2 fitzpatrick...@googlemail.com 
> >
> >
> >
> > > Hi,
> > > Thanks for the replies.
> >
> > > I have adapted the code above with my example. I still get the heap
> > > error!
> > > my-row-data is the lazy sequence. each element in the seq is a 2
> > > element vector of Java String[]
> > > output-array is just a printing function for the String[]. For
> > > convenience i place a @ between the two outputs.
> >
> > > (defn t [file-name]
> > >(with-open [w (java.io.FileWriter. (java.io.File. file-name))]
> > >(doseq [l my-row-data]
> > >  (.write w (str (output-array (first l) ",")
> > >
>  "@"
> >
> > >(output-array (second l) ",")
> >
> > >  "\n")
> >
> > >)
> > >)
> > >)
> > > )
> >
> > > tks,
> > > PJ
> >
> > > On Apr 2, 12:15 pm, Christian Vest Hansen 
> > > wrote:
> > > > On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
> >
> > > >  wrote:
> >
> > > > > Hi,
> > > > > I am attempting to print a large lazy seq to file. I have attempted
> > > > > various approaches and obviously am missing something obvious.
> > > > > I have attempted do use do-seq and also iterated manually through
> the
> > > > > sequence but i always come up with the heap error.
> > > > > Has anyone got any suggestions?
> >
> > > > Don't hold on to the head of the seq.
> >
> > > > It may not be obvious where, but you are most likely holding on the
> > > > the head of the seq, which prevents the elements from being GC'd as
> > > > you iterate them.
> >
> > > > > tks,
> > > > > PJ
> >
> > > > --
> > > > Venlig hilsen / Kind regards,
> > > > Christian Vest Hansen.
> >
>

--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread fitzpatrick...@googlemail.com

Apologies for my ignorance ,i am new to clojure, but can you give an
example of what the code should look like. I understand my-row-data is
lexical as it defined outside the function but i don't understand how
to implement this new function.
tks,
PJ

On Apr 2, 1:03 pm, Laurent PETIT  wrote:
> You're holding the head, because my-row-data is defined in the lexical or
> dynamic scope of the function, and holds the head.
>
> Try creating a function returning the seq that is currently stored in
> my-row-data and call it instead : (my-row-data)
>
> --
> Laurent
>
> 2009/4/2 fitzpatrick...@googlemail.com 
>
>
>
> > Hi,
> > Thanks for the replies.
>
> > I have adapted the code above with my example. I still get the heap
> > error!
> > my-row-data is the lazy sequence. each element in the seq is a 2
> > element vector of Java String[]
> > output-array is just a printing function for the String[]. For
> > convenience i place a @ between the two outputs.
>
> > (defn t [file-name]
> >    (with-open [w (java.io.FileWriter. (java.io.File. file-name))]
> >        (doseq [l my-row-data]
> >          (.write w (str (output-array (first l) ",")
> >                                                                        "@"
>
> >    (output-array (second l) ",")
>
> >  "\n")
>
> >                                        )
> >                                )
> >                )
> > )
>
> > tks,
> > PJ
>
> > On Apr 2, 12:15 pm, Christian Vest Hansen 
> > wrote:
> > > On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
>
> > >  wrote:
>
> > > > Hi,
> > > > I am attempting to print a large lazy seq to file. I have attempted
> > > > various approaches and obviously am missing something obvious.
> > > > I have attempted do use do-seq and also iterated manually through the
> > > > sequence but i always come up with the heap error.
> > > > Has anyone got any suggestions?
>
> > > Don't hold on to the head of the seq.
>
> > > It may not be obvious where, but you are most likely holding on the
> > > the head of the seq, which prevents the elements from being GC'd as
> > > you iterate them.
>
> > > > tks,
> > > > PJ
>
> > > --
> > > Venlig hilsen / Kind regards,
> > > Christian Vest Hansen.
--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Dmitri

Thanks a lot, that's really helpful. I never thought of using a macro
to define constants
like that, it's definitely a good trick and it does seem to result in
the biggest performance
gain.

On Apr 2, 7:25 am, Paul Stadig  wrote:
> I got it down to about 3 seconds. I did what William said, but the biggest
> improvement was from changing the way *width*, *height*, and *max-steps*
> were defined. I noticed that in the Java version they are constants, but in
> the Clojure version they are Vars which means that inside your tight inner
> loops you are dereferencing the vars multiple times. Vars are for thread
> local values, but these values are not expected to change. I'm not sure the
> best way to make these vars into constants, but I changed them into macros:
>
> (defmacro *width* [] (float 640))
>
> Then replaced instances of *width* with (*width*). The macros will get
> compiled down to floats instead of resulting in multiple Var.deref calls
> (and probably Number.floatValue calls) per loop iteration.
>
> Here is the code:
>
> (ns main
>  (:import (java.awt Color Container Graphics Canvas Dimension)
>           (javax.swing JPanel JFrame)
>           (java.awt.image BufferedImage BufferStrategy)))
>
> (set! *warn-on-reflection* true)
>
> (defmacro *width* [] (float 640))
> (defmacro *height* [] (float 640))
> (defmacro *max-steps* [] (float 32))
>
> (defn on-thread [#^Runnable f] (doto (new Thread f) (.start)))
>
> (defn check-bounds [x y]
>    (loop [px (float x)
>           py (float y)
>           zx (float 0.0)
>           zy (float 0.0)
>           zx2 (float 0.0)
>           zy2 (float 0.0)
>           value (float 0)]
>       (if (and (< value (*max-steps*)) (< (+ zx2 zy2) (float 4.0)))
>            (let [new-zy (float (+ (* (float 2.0) zx zy) py))
>                  new-zx (float (+ (- zx2 zy2) px))
>                  new-zx2 (float (* new-zx new-zx))
>                  new-zy2 (float (* new-zy new-zy))]
>                  (recur px py new-zx new-zy new-zx2 new-zy2 (inc value)))
>            (if (== value (*max-steps*)) 0 value
>
> (defn draw-line [#^Graphics g y]
>    (let [dy (- 1.25 (* 2.5 (/ y (*height*]
>      (doseq [x (range 0 (*width*))]
>        (let [dx (- (* 2.5 (/ x (*width*))) 2.0)]
>                (let [value (check-bounds dx dy)]
>                    (if (> value  0)
>                        (doto g
>                            (. setColor (Color. (* value (/ 255
> (*max-steps*)
>                            (. drawRect x y 0 0
>
> (defn draw-lines
>    ([buffer g] (draw-lines buffer g (*height*)))
>    ([#^BufferStrategy buffer g y]
>          (doseq [y (range 0 y)]
>             (draw-line g y)
>             ;(on-thread (draw-line g y))
>             (. buffer show
>
> (defn draw [#^Canvas canvas]
>    (let [buffer (. canvas getBufferStrategy)
>          g        (. buffer getDrawGraphics)]
>          (draw-lines buffer g)))
>
> (defn main []
>
>  (let [panel (JPanel.)
>        canvas (Canvas.)
>        frame (JFrame. "Mandelbrot")]
>
>    (doto panel
>      (.setPreferredSize (Dimension. (*width*) (*height*)))
>      (.setLayout nil)
>      (.add canvas))
>
>    (doto frame
>      (.setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
>      (.setBounds 0,0,(*width*) (*height*))
>      (.setResizable false)
>      (.add panel)
>      (.setVisible true))
>
>    (doto canvas
>      (.setBounds 0,0,(*width*) (*height*))
>      (.setBackground (Color/BLACK))
>      (.createBufferStrategy 2)
>      (.requestFocus))
>
>    (draw canvas)))
>
> (time (main))
>
> ~$ clojure /tmp/mandelbrot.clj
> "Elapsed time: 3577.128587 msecs"
>
> Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: speed question

2009-04-02 Thread David Sletten


On Apr 2, 2009, at 2:05 AM, MikeM wrote:

>
> Starting with your version, I got about a 2x improvement with the
> following:
>
> (defn check-bounds [x y]
>(let [f2 (float 2.0)
>  f4 (float 4.0)]
>(loop [px (float x)
>   py (float y)
>   zx (float 0.0)
>   zy (float 0.0)
>   zx2 (float 0.0)
>   zy2 (float 0.0)
>   value (float 0)]
>   (if (and (< value (*max-steps*)) (< (+ zx2 zy2) f4))
>(let [new-zy (float (+ (* (* f2 zx) zy) py))
>  new-zx (float (+ (- zx2 zy2) px))
>  new-zx2 (float (* new-zx new-zx))
>  new-zy2 (float (* new-zy new-zy))]
>  (recur px py new-zx new-zy new-zx2 new-zy2 (inc
> value)))
>(if (== value (*max-steps*)) 0 value)
>
> f2 and f4 didn't do much, most improvement seems to come from (* (* f2
> zx) zy) in place of (* f2 zx zy). Using the arity 2 multiply results
> in the multiply being inlined.

Building on your and Paul's improvements I simply wrapped (almost)  
everything in a 'let' rather than using 'def' or Paul's cool macro  
idea. I also pulled out a couple of divisions from draw-line. This  
takes about 38% of the time of Paul's version:
(let [width (float 640)
   height (float 640)
   max-steps (float 32)
   color-scale (float (quot 255 max-steps))
   height-factor (/ 2.5 height)
   width-factor (/ 2.5 width)]

   (defn on-thread [#^Runnable f] (doto (new Thread f) (.start)))

   (defn check-bounds [x y]
 (let [f2 (float 2.0)
   f4 (float 4.0)]
   (loop [px (float x)
  py (float y)
  zx (float 0.0)
  zy (float 0.0)
  zx2 (float 0.0)
  zy2 (float 0.0)
  value (float 0)]
 (if (and (< value max-steps) (< (+ zx2 zy2) f4))
   (let [new-zy (float (+ (* (* f2 zx) zy) py))
 new-zx (float (+ (- zx2 zy2) px))
 new-zx2 (float (* new-zx new-zx))
 new-zy2 (float (* new-zy new-zy))]
 (recur px py new-zx new-zy new-zx2 new-zy2 (inc
 value)))
   (if (== value max-steps) 0 value)

   (defn draw-line [#^Graphics g y]
 (let [dy (- 1.25 (* y height-factor))]
   (doseq [x (range 0 width)]
 (let [dx (- (* x width-factor) 2.0)]
   (let [value (check-bounds dx dy)]
 (if (> value  0)
   (doto g
 (. setColor (Color. (* value color-scale)))
 (. drawRect x y 0 0

   (defn draw-lines
 ([buffer g] (draw-lines buffer g height))
 ([#^BufferStrategy buffer g y]
(doseq [y (range 0 y)]
  (draw-line g y)
 ;(on-thread (draw-line g y))
  (. buffer show

   (defn draw [#^Canvas canvas]
 (let [buffer (. canvas getBufferStrategy)
   g(. buffer getDrawGraphics)]
   (draw-lines buffer g)))

   (defn main []

 (let [panel (JPanel.)
   canvas (Canvas.)
   frame (JFrame. "Mandelbrot")]

   (doto panel
 (.setPreferredSize (Dimension. width height))
 (.setLayout nil)
 (.add canvas))

   (doto frame
 (.setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
 (.setBounds 0,0,width height)
 (.setResizable false)
 (.add panel)
 (.setVisible true))

   (doto canvas
 (.setBounds 0,0,width height)
 (.setBackground (Color/BLACK))
 (.createBufferStrategy 2)
 (.requestFocus))

   (draw canvas

Aloha,
David Sletten

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Dmitri

like Paul said earlier changing the globals to macros makes seems to
make a huge impact.
and the check-bounds and draw-line get called for each line on the
screen so it makes sense
that optimizations there will make a big impact.

On Apr 2, 8:05 am, MikeM  wrote:
> Starting with your version, I got about a 2x improvement with the
> following:
>
> (defn check-bounds [x y]
>    (let [f2 (float 2.0)
>          f4 (float 4.0)]
>    (loop [px (float x)
>           py (float y)
>           zx (float 0.0)
>           zy (float 0.0)
>           zx2 (float 0.0)
>           zy2 (float 0.0)
>           value (float 0)]
>       (if (and (< value (*max-steps*)) (< (+ zx2 zy2) f4))
>            (let [new-zy (float (+ (* (* f2 zx) zy) py))
>                  new-zx (float (+ (- zx2 zy2) px))
>                  new-zx2 (float (* new-zx new-zx))
>                  new-zy2 (float (* new-zy new-zy))]
>                  (recur px py new-zx new-zy new-zx2 new-zy2 (inc
> value)))
>            (if (== value (*max-steps*)) 0 value)
>
> f2 and f4 didn't do much, most improvement seems to come from (* (* f2
> zx) zy) in place of (* f2 zx zy). Using the arity 2 multiply results
> in the multiply being inlined.
--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread MikeM

Starting with your version, I got about a 2x improvement with the
following:

(defn check-bounds [x y]
   (let [f2 (float 2.0)
 f4 (float 4.0)]
   (loop [px (float x)
  py (float y)
  zx (float 0.0)
  zy (float 0.0)
  zx2 (float 0.0)
  zy2 (float 0.0)
  value (float 0)]
  (if (and (< value (*max-steps*)) (< (+ zx2 zy2) f4))
   (let [new-zy (float (+ (* (* f2 zx) zy) py))
 new-zx (float (+ (- zx2 zy2) px))
 new-zx2 (float (* new-zx new-zx))
 new-zy2 (float (* new-zy new-zy))]
 (recur px py new-zx new-zy new-zx2 new-zy2 (inc
value)))
   (if (== value (*max-steps*)) 0 value)

f2 and f4 didn't do much, most improvement seems to come from (* (* f2
zx) zy) in place of (* f2 zx zy). Using the arity 2 multiply results
in the multiply being inlined.
--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread Laurent PETIT
You're holding the head, because my-row-data is defined in the lexical or
dynamic scope of the function, and holds the head.

Try creating a function returning the seq that is currently stored in
my-row-data and call it instead : (my-row-data)

-- 
Laurent

2009/4/2 fitzpatrick...@googlemail.com 

>
> Hi,
> Thanks for the replies.
>
> I have adapted the code above with my example. I still get the heap
> error!
> my-row-data is the lazy sequence. each element in the seq is a 2
> element vector of Java String[]
> output-array is just a printing function for the String[]. For
> convenience i place a @ between the two outputs.
>
> (defn t [file-name]
>(with-open [w (java.io.FileWriter. (java.io.File. file-name))]
>(doseq [l my-row-data]
>  (.write w (str (output-array (first l) ",")
>"@"
>
>(output-array (second l) ",")
>
>  "\n")
>
>)
>)
>)
> )
>
> tks,
> PJ
>
>
> On Apr 2, 12:15 pm, Christian Vest Hansen 
> wrote:
> > On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
> >
> >  wrote:
> >
> > > Hi,
> > > I am attempting to print a large lazy seq to file. I have attempted
> > > various approaches and obviously am missing something obvious.
> > > I have attempted do use do-seq and also iterated manually through the
> > > sequence but i always come up with the heap error.
> > > Has anyone got any suggestions?
> >
> > Don't hold on to the head of the seq.
> >
> > It may not be obvious where, but you are most likely holding on the
> > the head of the seq, which prevents the elements from being GC'd as
> > you iterate them.
> >
> > > tks,
> > > PJ
> >
> > --
> > Venlig hilsen / Kind regards,
> > Christian Vest Hansen.
> >
>

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Dmitri

thanks a lot, that's really helpful.

On Apr 2, 7:25 am, Paul Stadig  wrote:
> I got it down to about 3 seconds. I did what William said, but the biggest
> improvement was from changing the way *width*, *height*, and *max-steps*
> were defined. I noticed that in the Java version they are constants, but in
> the Clojure version they are Vars which means that inside your tight inner
> loops you are dereferencing the vars multiple times. Vars are for thread
> local values, but these values are not expected to change. I'm not sure the
> best way to make these vars into constants, but I changed them into macros:
>
> (defmacro *width* [] (float 640))
>
> Then replaced instances of *width* with (*width*). The macros will get
> compiled down to floats instead of resulting in multiple Var.deref calls
> (and probably Number.floatValue calls) per loop iteration.
>
> Here is the code:
>
> (ns main
>  (:import (java.awt Color Container Graphics Canvas Dimension)
>           (javax.swing JPanel JFrame)
>           (java.awt.image BufferedImage BufferStrategy)))
>
> (set! *warn-on-reflection* true)
>
> (defmacro *width* [] (float 640))
> (defmacro *height* [] (float 640))
> (defmacro *max-steps* [] (float 32))
>
> (defn on-thread [#^Runnable f] (doto (new Thread f) (.start)))
>
> (defn check-bounds [x y]
>    (loop [px (float x)
>           py (float y)
>           zx (float 0.0)
>           zy (float 0.0)
>           zx2 (float 0.0)
>           zy2 (float 0.0)
>           value (float 0)]
>       (if (and (< value (*max-steps*)) (< (+ zx2 zy2) (float 4.0)))
>            (let [new-zy (float (+ (* (float 2.0) zx zy) py))
>                  new-zx (float (+ (- zx2 zy2) px))
>                  new-zx2 (float (* new-zx new-zx))
>                  new-zy2 (float (* new-zy new-zy))]
>                  (recur px py new-zx new-zy new-zx2 new-zy2 (inc value)))
>            (if (== value (*max-steps*)) 0 value
>
> (defn draw-line [#^Graphics g y]
>    (let [dy (- 1.25 (* 2.5 (/ y (*height*]
>      (doseq [x (range 0 (*width*))]
>        (let [dx (- (* 2.5 (/ x (*width*))) 2.0)]
>                (let [value (check-bounds dx dy)]
>                    (if (> value  0)
>                        (doto g
>                            (. setColor (Color. (* value (/ 255
> (*max-steps*)
>                            (. drawRect x y 0 0
>
> (defn draw-lines
>    ([buffer g] (draw-lines buffer g (*height*)))
>    ([#^BufferStrategy buffer g y]
>          (doseq [y (range 0 y)]
>             (draw-line g y)
>             ;(on-thread (draw-line g y))
>             (. buffer show
>
> (defn draw [#^Canvas canvas]
>    (let [buffer (. canvas getBufferStrategy)
>          g        (. buffer getDrawGraphics)]
>          (draw-lines buffer g)))
>
> (defn main []
>
>  (let [panel (JPanel.)
>        canvas (Canvas.)
>        frame (JFrame. "Mandelbrot")]
>
>    (doto panel
>      (.setPreferredSize (Dimension. (*width*) (*height*)))
>      (.setLayout nil)
>      (.add canvas))
>
>    (doto frame
>      (.setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
>      (.setBounds 0,0,(*width*) (*height*))
>      (.setResizable false)
>      (.add panel)
>      (.setVisible true))
>
>    (doto canvas
>      (.setBounds 0,0,(*width*) (*height*))
>      (.setBackground (Color/BLACK))
>      (.createBufferStrategy 2)
>      (.requestFocus))
>
>    (draw canvas)))
>
> (time (main))
>
> ~$ clojure /tmp/mandelbrot.clj
> "Elapsed time: 3577.128587 msecs"
>
> Paul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread fitzpatrick...@googlemail.com

Hi,
Thanks for the replies.

I have adapted the code above with my example. I still get the heap
error!
my-row-data is the lazy sequence. each element in the seq is a 2
element vector of Java String[]
output-array is just a printing function for the String[]. For
convenience i place a @ between the two outputs.

(defn t [file-name]
(with-open [w (java.io.FileWriter. (java.io.File. file-name))]
(doseq [l my-row-data]
  (.write w (str (output-array (first l) ",")
"@"

(output-array (second l) ",")
"\n")

)
)
)
)

tks,
PJ


On Apr 2, 12:15 pm, Christian Vest Hansen 
wrote:
> On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
>
>  wrote:
>
> > Hi,
> > I am attempting to print a large lazy seq to file. I have attempted
> > various approaches and obviously am missing something obvious.
> > I have attempted do use do-seq and also iterated manually through the
> > sequence but i always come up with the heap error.
> > Has anyone got any suggestions?
>
> Don't hold on to the head of the seq.
>
> It may not be obvious where, but you are most likely holding on the
> the head of the seq, which prevents the elements from being GC'd as
> you iterate them.
>
> > tks,
> > PJ
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread e
i didn't know about this one.  thanks

On Thu, Apr 2, 2009 at 4:51 AM, Rayne  wrote:

> La Clojure

--~--~-~--~~~---~--~~
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
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: speed question

2009-04-02 Thread Paul Stadig
I got it down to about 3 seconds. I did what William said, but the biggest
improvement was from changing the way *width*, *height*, and *max-steps*
were defined. I noticed that in the Java version they are constants, but in
the Clojure version they are Vars which means that inside your tight inner
loops you are dereferencing the vars multiple times. Vars are for thread
local values, but these values are not expected to change. I'm not sure the
best way to make these vars into constants, but I changed them into macros:

(defmacro *width* [] (float 640))

Then replaced instances of *width* with (*width*). The macros will get
compiled down to floats instead of resulting in multiple Var.deref calls
(and probably Number.floatValue calls) per loop iteration.

Here is the code:

(ns main
 (:import (java.awt Color Container Graphics Canvas Dimension)
  (javax.swing JPanel JFrame)
  (java.awt.image BufferedImage BufferStrategy)))

(set! *warn-on-reflection* true)

(defmacro *width* [] (float 640))
(defmacro *height* [] (float 640))
(defmacro *max-steps* [] (float 32))

(defn on-thread [#^Runnable f] (doto (new Thread f) (.start)))

(defn check-bounds [x y]
   (loop [px (float x)
  py (float y)
  zx (float 0.0)
  zy (float 0.0)
  zx2 (float 0.0)
  zy2 (float 0.0)
  value (float 0)]
  (if (and (< value (*max-steps*)) (< (+ zx2 zy2) (float 4.0)))
   (let [new-zy (float (+ (* (float 2.0) zx zy) py))
 new-zx (float (+ (- zx2 zy2) px))
 new-zx2 (float (* new-zx new-zx))
 new-zy2 (float (* new-zy new-zy))]
 (recur px py new-zx new-zy new-zx2 new-zy2 (inc value)))
   (if (== value (*max-steps*)) 0 value

(defn draw-line [#^Graphics g y]
   (let [dy (- 1.25 (* 2.5 (/ y (*height*]
 (doseq [x (range 0 (*width*))]
   (let [dx (- (* 2.5 (/ x (*width*))) 2.0)]
   (let [value (check-bounds dx dy)]
   (if (> value  0)
   (doto g
   (. setColor (Color. (* value (/ 255
(*max-steps*)
   (. drawRect x y 0 0

(defn draw-lines
   ([buffer g] (draw-lines buffer g (*height*)))
   ([#^BufferStrategy buffer g y]
 (doseq [y (range 0 y)]
(draw-line g y)
;(on-thread (draw-line g y))
(. buffer show


(defn draw [#^Canvas canvas]
   (let [buffer (. canvas getBufferStrategy)
 g(. buffer getDrawGraphics)]
 (draw-lines buffer g)))

(defn main []

 (let [panel (JPanel.)
   canvas (Canvas.)
   frame (JFrame. "Mandelbrot")]

   (doto panel
 (.setPreferredSize (Dimension. (*width*) (*height*)))
 (.setLayout nil)
 (.add canvas))

   (doto frame
 (.setDefaultCloseOperation JFrame/EXIT_ON_CLOSE)
 (.setBounds 0,0,(*width*) (*height*))
 (.setResizable false)
 (.add panel)
 (.setVisible true))

   (doto canvas
 (.setBounds 0,0,(*width*) (*height*))
 (.setBackground (Color/BLACK))
 (.createBufferStrategy 2)
 (.requestFocus))

   (draw canvas)))

(time (main))

~$ clojure /tmp/mandelbrot.clj
"Elapsed time: 3577.128587 msecs"


Paul

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread Christian Vest Hansen

On Thu, Apr 2, 2009 at 11:58 AM, fitzpatrick...@googlemail.com
 wrote:
>
> Hi,
> I am attempting to print a large lazy seq to file. I have attempted
> various approaches and obviously am missing something obvious.
> I have attempted do use do-seq and also iterated manually through the
> sequence but i always come up with the heap error.
> Has anyone got any suggestions?

Don't hold on to the head of the seq.

It may not be obvious where, but you are most likely holding on the
the head of the seq, which prevents the elements from being GC'd as
you iterate them.

> tks,
> PJ
> >
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread Laurent PETIT
e.g. the following code works very well for me (so I had to stop it before
the file size became > to 1 Gbyte :-) :

;; file test.clj

(ns test)

(defn infinite [] (repeat "a line"))

(defn t []
(with-open [w (java.io.FileWriter. (java.io.File. "/tmp/test"))]
(doseq [l (infinite)]
  (.write w (str l "\n")

HTH,

-- 
Laurent


2009/4/2 Laurent PETIT 

> Can you post the code that poses problem ?
>
> 2009/4/2 fitzpatrick...@googlemail.com 
>
>
>> Hi,
>> I am attempting to print a large lazy seq to file. I have attempted
>> various approaches and obviously am missing something obvious.
>> I have attempted do use do-seq and also iterated manually through the
>> sequence but i always come up with the heap error.
>> Has anyone got any suggestions?
>> tks,
>> PJ
>> >>
>>
>

--~--~-~--~~~---~--~~
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
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: Print a Large Lazy Seq - Heap Error

2009-04-02 Thread Laurent PETIT
Can you post the code that poses problem ?

2009/4/2 fitzpatrick...@googlemail.com 

>
> Hi,
> I am attempting to print a large lazy seq to file. I have attempted
> various approaches and obviously am missing something obvious.
> I have attempted do use do-seq and also iterated manually through the
> sequence but i always come up with the heap error.
> Has anyone got any suggestions?
> tks,
> PJ
> >
>

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



Print a Large Lazy Seq - Heap Error

2009-04-02 Thread fitzpatrick...@googlemail.com

Hi,
I am attempting to print a large lazy seq to file. I have attempted
various approaches and obviously am missing something obvious.
I have attempted do use do-seq and also iterated manually through the
sequence but i always come up with the heap error.
Has anyone got any suggestions?
tks,
PJ
--~--~-~--~~~---~--~~
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
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: Find the function you need

2009-04-02 Thread Rayne

I already have this function. It's called channel #Clojure on
freenode :p. All I got to do is wave my magic wand at hiredman and
CLABANGO!.

On Apr 1, 8:17 pm, Mitch  wrote:
> While still learning clojure, I often times need a function and am not
> sure if it already exists or where to look for it.  I thought it would
> be useful to be able to give a return value and arguments and search
> all functions for ones which return the given value when called with
> the given arguments.  Here's what I came up with:
>
> (defn test-for
>   "Tests to see if a given function called with given arguments
> results
>   in given value, catching any exceptions that occur"
>   [v f & args]
>   (try (= v (apply f args))
>     (catch Exception e nil)))
>
> (defn find-func
>   "Given a value and arguments, searches all public functions in all
> namespaces"
>   [v & args]
>   (map key
>        (mapcat
>          (fn [ns_]
>            (filter
>              #(binding [*out* nil *in* nil]
>                 (apply test-for v (val %) args))
>              (ns-publics (the-ns ns_
>          (all-ns
>
> Binding *in* and *out* stops any IO functions from messing up the
> search.  There's probably still ways this could be dangerous though,
> depending on the given args.  Hope someone finds this useful or
> improves upon it.
>
> -Mitch
--~--~-~--~~~---~--~~
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
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: I feel I'm making an elementary mistake with proxy, but I don't know what...

2009-04-02 Thread Christian Vest Hansen

On Thu, Apr 2, 2009 at 2:33 AM, Luke VanderHart
 wrote:
>
> Ugh, I hate it when I make a fool of myself and realize the answer to
> a question 1 minute after posting it, even when wrestling with it for
> an hour beforehand...
>
> The reason the example doesn't work is that the method is of a
> different arity than the one I'm attempting to call.
>
> Still doesn't explain why it's failing with the same error when I try
> to actually use it on a Swing object, but I'll try to isolate that
> condition separately... Sorry for the pointless post.

http://en.wikipedia.org/wiki/Rubber_Duck_Debugging

:)

>
> Thanks,
> -Luke
>
> On Apr 1, 8:29 pm, levand  wrote:
>> Isn't this supposed to work?
>>
>> (defn create-layout []
>>     (proxy [java.awt.LayoutManager] []
>>       (addLayoutComponent [name comp]
>>                           (println "Called addLayoutComponent"))
>>       (removeLayoutComponent [comp]
>>                              (println "Called removeLayoutComponent"))
>>       (preferredLayoutSize [container]
>>                            (println "Called preferredLayoutSize"))
>>       (minimumLayoutSize [container]
>>                          (println "Called minimumLayoutSize"))
>>       (layoutContainer [container]
>>                        (println "Called layoutContainer"
>>
>> user> (def layout (create-layout))
>> #'user/layout
>> user> (instance? java.awt.LayoutManager layout)
>> true
>> user> (. layout preferredLayoutSize)
>> ; Evaluation aborted. java.lang.IllegalArgumentException: No matching
>> field found: preferredLayoutSize for class
>> clojure.proxy.java.lang.Object$LayoutManager (NO_SOURCE_FILE:0)
>>   [Thrown class clojure.lang.Compiler$CompilerException]
>>
>> I get the same thing for all its methods, when I try to call them
>> manually and also when I hook it up to a Swing container.
>>
>> I'd greatly appreciate it if anyone has any insight regarding what is
>> going on...
>>
>> Thanks,
>> -Luke
> >
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Rayne

Every one of those IDE's work with adding stuff like Clojure-contrib
to the classpath. In La Clojure, it's as simple as going to File ->
Project Structure -> Libraries -> Attach Classes and finding the
correct directory of Clojure-contrib. In Enclojure, it's as simple as
right clicking Libraries in your project and hitting Add Jar or
Properties and doing it from there. I'm not sure where the problem is
as it works fine in both IDE's for me. Even in Clojure-dev.

On Apr 1, 2:22 pm, Daniel Jomphe  wrote:
> Let's say I *hate* dealing with Java classpaths, especially within
> IDEs.
> Somehow, it's always the hardest configuration part of setting up a
> project.
>
> Let's add I want to use clojure + clojure.contrib.
>
> If my mileage is representative at all of most newcomer's experiences
> trying to get acquainted with clojure, this is very bad: all the
> following editors have a plugin for clojure, but none of them comes
> with an easy way to add clojure.contrib to the classpath.
>
> emacs+SLIME+clojure-mode - works incredibly great for core clojure
> netbeans - works great for core clojure
> intellij - works ok for core clojure; if I add contrib's jar to the
> libs, it seems to see it somehow, but still doesn't work
>
> I have spent ~30 mins in each one of them trying to make it work, and
> failed. I have also spent some time skimming different tutorials, and
> it looks like this is not covered.
>
> Would you fellow clojurians have wise advice for me? While I await
> your answers, I'm going to try eclipse. I think I've read Laurent
> Petit, the other day, saying his eclipse plugin automatically handles
> classpaths.
>
> I would *love* to know how to make it work in each one of these
> editors; I'm not yet decided on which one I want to use.
--~--~-~--~~~---~--~~
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
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: basic question on structuring refs

2009-04-02 Thread Laurent PETIT
Referring to http://clojure.org/refs :

Rule 1. states that all your reads will be consistent as of the starting
point of the transaction
Rule 2. states that no changes will have been made by any other transactions
to any Refs that have been *ref-set**/altered**/ensured* by this
transaction.

So by re-reading this page, I'm now pretty sure that you will have to call
ensure to guarantee what you stated below.

HTH,

-- 
Laurent

2009/4/2 Korny Sietsma 

> Hmm - I'm unclear.  I had the impression that if thread a *reads* ref
> "world" and thread b *alters* ref "world" that would cause one of them to
> retry... is that wrong?  It probably doesn't matter to my code, but it'd be
> good to know.
>
> - Korny
>
>
> On Thu, Apr 2, 2009 at 6:11 PM, Laurent PETIT wrote:
>
>> Hello,
>>
>> 2009/4/2 Korny Sietsma 
>>
>>>
>>> If I understand correctly, two threads calling do_something_to with
>>> different keys won't collide, as they read @world but don't change it.  I'll
>>> get a collision if one thread changes @world and another changes an
>>> individual structure - but I guess that's necessary, as the change might
>>> have deleted the record with the key needed by the other thread.
>>
>>
>> I'm far from a specialist of these aspects of clojure, but I'm not sure
>> you're right when you say you will get a collision. I think you will not
>> have a collision, unless you call (ensure) on the world ?
>>
>>
>>
>>
>
>
> --
> Kornelis Sietsma  korny at my surname dot com
> "Every jumbled pile of person has a thinking part
> that wonders what the part that isn't thinking
> isn't thinking of"
>
> >
>

--~--~-~--~~~---~--~~
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
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: basic question on structuring refs

2009-04-02 Thread Korny Sietsma
Hmm - I'm unclear.  I had the impression that if thread a *reads* ref
"world" and thread b *alters* ref "world" that would cause one of them to
retry... is that wrong?  It probably doesn't matter to my code, but it'd be
good to know.

- Korny

On Thu, Apr 2, 2009 at 6:11 PM, Laurent PETIT wrote:

> Hello,
>
> 2009/4/2 Korny Sietsma 
>
>>
>> If I understand correctly, two threads calling do_something_to with
>> different keys won't collide, as they read @world but don't change it.  I'll
>> get a collision if one thread changes @world and another changes an
>> individual structure - but I guess that's necessary, as the change might
>> have deleted the record with the key needed by the other thread.
>
>
> I'm far from a specialist of these aspects of clojure, but I'm not sure
> you're right when you say you will get a collision. I think you will not
> have a collision, unless you call (ensure) on the world ?
>
>
> >
>


-- 
Kornelis Sietsma  korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"

--~--~-~--~~~---~--~~
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
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: Full Clojure, Right Now! (tm)

2009-04-02 Thread Laurent PETIT
Hi,

2009/4/1 Daniel Jomphe 

>
> Would you fellow clojurians have wise advice for me? While I await
> your answers, I'm going to try eclipse. I think I've read Laurent
> Petit, the other day, saying his eclipse plugin automatically handles
> classpaths.
>

Indeed, with clojuredev, initializing a new clojure project installs clojure
and clojure-contrib in the classpath of the project for you. These are
versions bundled with clojuredev.
Then, if you want to change them for your own version, call the project's
context menu > Properties > Java Build Path > Libraries >  and change them
to suit your needs.

If you want to give a quick try to the plugin, without compromising your
(potentially) existing eclipse installation :

- download and install eclipse for java :
http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/ganymedesr2
- start it
- Go to Help > Software updates > Available Software > Add Site
- Add the update site : http://clojure-dev.googlecode.com/svn/updatesite/
- Expand the tree through to the "Clojuredev feature" leaf , check it, click
install (in the top right corner)
- agree to all licensing / approval requests stuff, quit the download
installer, accept to restart eclipse
- optionally : quick check that the plugin is correctly installed by
verifying that you see clojuredev's feature in Help > About Eclipse Platform
> (you should see a clojure logo, and by clicking on it and then clicking on
"plugin details" it you should see 4 installed plugins)
- you should be in the java perspective (if not : Window > Open perspective
> Other > Java )
- create a clojure project File > New > clojure project  (if you don't see
clojure project, just refresh the perspective via Window > Refresh
Perspective), enter a name, and voila!
- select your project's node in the package explore. Clic Ctr+F11 on windows
(or more generally the shortcut for your OS can be seen via Run > Run menu),
this will start the java project by calling repl_ln, and you will see the
REPL in the console of the launched project

To be sure that you will not encounter any problem, I've reproduced the
above steps while writing, it took me about 10 minutes. I hope you have a
similar experience.


As a final word, I would say that I'm pretty sure there are also decent ways
to add libraries to other IDE's platforms. Since they're all open source
initiatives, there is certainly still a lack of coverage in documentation,
and bugs and ... (they are plenty of bugs in clojuredev too :-), so I would
invite you to try and use the plugin for your editor of choice, and help the
plugins authors for this environment improve it by submitting bugs (even if
you find a workaround to a bug, submitting a bug will help other users not
having to re-find this same workaround), request enhancement. Don't also
hesitate to explicit what would be your priorities for new functionalities
...

I personally, as a contributor to Eclipse, am not willing to attract people
to eclipse that would have no interest in learning it. My intend is to help
spread clojure over the developers community, by letting them use their
favorite tool, Eclipse being one of the choices.

Regards,

-- 
Laurent

--~--~-~--~~~---~--~~
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
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: basic question on structuring refs

2009-04-02 Thread Laurent PETIT
Hello,

2009/4/2 Korny Sietsma 

>
> If I understand correctly, two threads calling do_something_to with
> different keys won't collide, as they read @world but don't change it.  I'll
> get a collision if one thread changes @world and another changes an
> individual structure - but I guess that's necessary, as the change might
> have deleted the record with the key needed by the other thread.


I'm far from a specialist of these aspects of clojure, but I'm not sure
you're right when you say you will get a collision. I think you will not
have a collision, unless you call (ensure) on the world ?

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