Re: Bug: recur won't work in tail position within cond

[Ralf Bensmann]

In Clojure the extra () around case and expr are skipped if no function call
is made. Have a look at clojure.org/api
-Ralf

On Thu, Dec 4, 2008 at 5:54 AM, harrison clarke <[EMAIL PROTECTED]> wrote:

> did cond change syntax?
>
> last i checked, it was
>
> (cond (case) (expr)
>
>  (case) (expr)
>
>  )
>
> >
>

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

PATCH: add overloaded (reader) and (writer) to clojure.contrib.duck-stream

[walterc]

i've added overloaded versions of reader and writer to
clojure.contrib.duck-stream.  they can now take an additional string
argument named "encoding" so content can be read or written with the
specified encoding instead of default encoding.  the semantics of the
original functions have not changed.

the patch is uploaded to the files section of this group:
http://groups.google.com/group/clojure/web/duck-stream.patch


regards,

walter chang

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Improved Maven Build

[ivant]

I remember reading somewhere[1], that we can actually run ant from
maven.  It just occurred to me, that we can build the pom with
groupId, artifactId and version, which actually uses ant for the
build.  This way the builds will be identical and we'll only have to
update the version in the pom.

I don't have the time right now, but I can try to build the pom in the
weekend.

[1] Probably here: http://books.sonatype.com/maven-book/index.html

On Dec 4, 8:59 pm, Luke Amdor <[EMAIL PROTECTED]> wrote:
> As an avid Maven fan, I really don't think Clojure would really
> benefit much from having a Maven build. It really doesn't have any
> dependencies to speak of and is extremely easy to build.
>
> The main thing that I would like to be able to do is to easily get the
> newest Clojure snapshots and releases. So being able to refer to a
> dependency on Clojure in my own project's pom.xml is important to me.
>
> Just my 2c.
>
> Luke
>
> On Dec 4, 7:24 am, verec <[EMAIL PROTECTED]>
> wrote:
>
> > +1 (avoid Maven, drop pom)
>
> > I'm just out of a project that has used Maven for more than 18 month.
> > The pain and frustration caused by the slowness and compexity of
> > Maven's "download the whole internet" approach can be matched only
> > bu the willingness of team astronauts to introduce Maven plugins in
> > the build process, more often that not to fix an endogenous problem.
>
> > +1 (keep Ant)
> > --
> > JFB
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

clojure-contrib build fails; ant does not like "path" element for jar

[Juergen Gmeiner]

Maverick:~/site/clojure/clojure-contrib gj$ ant -Dclojure.jar=../
clojure/clojure.jar
Buildfile: build.xml

 - boring stuff snipped

jar:

BUILD FAILED
/Users/gj/site/clojure/clojure-contrib/build.xml:62: The  type
doesn't support the nested "path" element.

Total time: 1 second

This works for me:

Maverick:~/site/clojure/clojure-contrib gj$ git diff
diff --git a/build.xml b/build.xml
index 0a3bad6..9e1c8ad 100644
--- a/build.xml
+++ b/build.xml
@@ -60,7 +60,7 @@

   
 
-  
+  
   
   
   

CA is in the mail; anyway boring patch, public domain, yadda yadda

Cheers,
Juergen
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure-contrib build fails; ant does not like "path" element for jar

[Juergen Gmeiner]

Or better even:



I think I'll have some more coffe :)
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure template library

[Jeff Rose]

Rich Hickey wrote:
> 
> 
> On Dec 3, 1:04 pm, Jeff Rose <[EMAIL PROTECTED]> wrote:
>> I've just pushed a template library for Clojure up onto github for
>> public use.  You can find it here:
>>
>> http://github.com/rosejn/clj-libs/tree/master
>>
>> This library is based loosely on erb from Ruby, which is the only other
>> template system I've used, and it allows you to insert Clojure
>> scriptlets inside a text document.  Following is a short example of how
>> it currently works.  Any thoughts, suggestions or feedback are welcome.
>>   I plan on making it easier to instantiate pages by passing a hash, or
>> maybe a sequence of hashes, which will be successively bound for you.
>> I'll probably add some configuration options for handling whitespace and
>> trimming newlines too.  Any other ideas or patches welcome.
>>
> 
> Neat! One thing I recommend is that you consider taking a functional
> approach to templates - it would be much more in line with Clojure.
> Two examples of a more functional approach are:
> 
> StringTemplate
> http://www.stringtemplate.org/
> 
> Google XML Pages
> http://code.google.com/p/gxp/
> 
> Rich

Ok, I can see the benefits of a functional style template.  Do you think 
the important aspect of this is whether you use a push or a pull model 
for populating forms with data?  In a functional style you would pass 
all the necessary values to a function, which would then populate the 
form and return a result. I don't like the idea of having to use XML or 
some mini-language to do variable replacement, if statements, and 
iteration over collections though.  If I make the template library a 
push model where you send it the values, but you just use Clojure code 
to determine how they get used, does that still fit the bill?

As for the javascript template engines, I think that kind of solution 
might be great for a websites, but a template engine like this is useful 
for many applications besides filling in html pages, so I'd still like 
to have a generic template mechanism from within Clojure.  From the 
above, I think StringTemplate has some interesting ideas.  I'm going to 
look into supporting recursive template application and include mechanisms.

-Jeff

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[bOR_]

Are there any screencasts planned which will feature atoms? (I found
that the screencasts are an excellent way of learning 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure template library

[blackdog]

Hi Jeff, 

Don't forget that Velocity and Freemarker are also good candidates for
server side templating and with clojure's java integration a snap to
use, e.g. ...

(defn genSyntaxHiLight
   [] (let [fmc (freeMarkerConfig)
tmpl (. fmc getTemplate "clojure.ftl")
map (clj-ns/get-tree)
]
 
 (. tmpl process (convertMap map) *out*)
))


the clojure.ftl is a free marker template. I think that with clojure's
maps implementing Map that the (convertMap) I had required previously
is no longer necessary.

bd

On Fri, 05 Dec 2008 11:22:04 +0100
Jeff Rose <[EMAIL PROTECTED]> wrote:

> 
> Rich Hickey wrote:
> > 
> > 
> > On Dec 3, 1:04 pm, Jeff Rose <[EMAIL PROTECTED]> wrote:
> >> I've just pushed a template library for Clojure up onto github for
> >> public use.  You can find it here:
> >>
> >> http://github.com/rosejn/clj-libs/tree/master
> >>
> >> This library is based loosely on erb from Ruby, which is the only
> >> other template system I've used, and it allows you to insert
> >> Clojure scriptlets inside a text document.  Following is a short
> >> example of how it currently works.  Any thoughts, suggestions or
> >> feedback are welcome. I plan on making it easier to instantiate
> >> pages by passing a hash, or maybe a sequence of hashes, which will
> >> be successively bound for you. I'll probably add some
> >> configuration options for handling whitespace and trimming
> >> newlines too.  Any other ideas or patches welcome.
> >>
> > 
> > Neat! One thing I recommend is that you consider taking a functional
> > approach to templates - it would be much more in line with Clojure.
> > Two examples of a more functional approach are:
> > 
> > StringTemplate
> > http://www.stringtemplate.org/
> > 
> > Google XML Pages
> > http://code.google.com/p/gxp/
> > 
> > Rich
> 
> Ok, I can see the benefits of a functional style template.  Do you
> think the important aspect of this is whether you use a push or a
> pull model for populating forms with data?  In a functional style you
> would pass all the necessary values to a function, which would then
> populate the form and return a result. I don't like the idea of
> having to use XML or some mini-language to do variable replacement,
> if statements, and iteration over collections though.  If I make the
> template library a push model where you send it the values, but you
> just use Clojure code to determine how they get used, does that still
> fit the bill?
> 
> As for the javascript template engines, I think that kind of solution 
> might be great for a websites, but a template engine like this is
> useful for many applications besides filling in html pages, so I'd
> still like to have a generic template mechanism from within Clojure.
> From the above, I think StringTemplate has some interesting ideas.
> I'm going to look into supporting recursive template application and
> include mechanisms.
> 
> -Jeff
> 
> > 


-- 
None are more hopelessly enslaved than those who falsely believe they
are free — Goethe

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Parth Malwankar]

On Dec 5, 6:02 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
>
> Docs here:
>
> http://clojure.org/atoms
>
> Feedback welcome,
>
> Rich

Are the following equivalent or is one recommended over
the other? The first (using atoms) is definitely more convenient
and less verbose.

user=> (def a (ref {:a 1 :b 2 :c 3}))
#'user/a
user=> (def a (atom {:a 1 :b 2 :c 3}))
#'user/a
user=> (swap! a assoc  :a 5)
{:c 3, :b 2, :a 5}
user=> a
#

OR

user=> (def b (ref {:a 1 :b 2 :c 3}))
#'user/b
user=> (dosync (ref-set b (assoc @b :a 5)))
{:c 3, :b 2, :a 5}
user=> b
#
user=> @b
{:c 3, :b 2, :a 5}
user=>

Parth

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

function args question

[hitesh]

I'm working on some opengl code in clojure and I want to specify a
vertex.  However, instead of passing in the three arguments it wants,
I want to specify a single vector of 3 elements.  How can I do this?

Here's what it would normally look like (gl represents the current
opengl drawing context object):

(.glVertex3f gl 1.0 3.7 0.0)


Here's what I want to write:

(let [ point [1.0 3.7 0.0] ]
  (.glVertex3f gl point))


I've tried playing around with apply.

(apply .glVertex3f gl point)

But it generates an error: no matching method glVertex3f for class
com.sun.opengl.impl.GLImpl.

I'm not sure what this concept is called, but here's some code in
other languages that demonstrates it.

Here's the equivalent concept in Haskell

foo :: (Show a) => a -> a -> IO ()
foo a b = mapM_ print [a, b]

*Main> uncurry foo (1,2)
1
2


Or in Ruby

def foo(a,b)
  puts a
  puts b
end

x = [1,2]

foo *x
1
2


Any ideas?

Thanks,
Hitesh


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: function args question

[Meikel Brandmeyer]

Hi,

On 5 Dez., 03:28, hitesh <[EMAIL PROTECTED]> wrote:
> (apply .glVertex3f gl point)

In general this is exactly how apply is used. However .foo
is special: "functions" starting with a dot are translated into
method calls on the first argument. So (.glVertex3f gl x y z)
translates is to (. gl glVertex3f x y z). . however is a special
form and does not work with apply.

Here we have to create some wrapper:

(def my-vertex-call #(jcall %1 glVertex3f %2 %3 %4))
(apply my-vertex-call gl [x y z])

More info on this issue can be found in this thread:
http://groups.google.com/group/clojure/browse_thread/thread/979d286ecaf21a82/0770c7eec859eb0c?lnk=gst&q=jcall#0770c7eec859eb0c

More info on special forms:
http://clojure.org/special_forms

Note: (Object.) also translates to (new Object).
This is also a special form, so similar considerations
may apply.

Hope this helps.

Sincerely
Meikel


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: function args question

[Jeff Rose]

hitesh wrote:
> I'm working on some opengl code in clojure and I want to specify a
> vertex.  However, instead of passing in the three arguments it wants,
> I want to specify a single vector of 3 elements.  How can I do this?
>
> Here's what it would normally look like (gl represents the current
> opengl drawing context object):
>
> (.glVertex3f gl 1.0 3.7 0.0)
>
>
> Here's what I want to write:
>
> (let [ point [1.0 3.7 0.0] ]
>   (.glVertex3f gl point))
>
>
> I've tried playing around with apply.
>
> (apply .glVertex3f gl point)
>
> But it generates an error: no matching method glVertex3f for class
> com.sun.opengl.impl.GLImpl.
>
> I'm not sure what this concept is called, but here's some code in
> other languages that demonstrates it.
>
> Here's the equivalent concept in Haskell
>
> foo :: (Show a) => a -> a -> IO ()
> foo a b = mapM_ print [a, b]
>
> *Main> uncurry foo (1,2)
> 1
> 2
>
>
> Or in Ruby
>
> def foo(a,b)
>   puts a
>   puts b
> end
>
> x = [1,2]
>
> foo *x
> 1
> 2
>
>
> Any ideas?
>
> Thanks,
> Hitesh
So it works with functions defined in Clojure:

Clojure
user=> (defn foo [a b c] (list a b c))
#'user/foo
user=> (foo [1 2 3])
java.lang.IllegalArgumentException: Wrong number of args passed to: 
user$foo (NO_SOURCE_FILE:0)
user=> (apply foo [1 2 3])
(1 2 3)
user=> (defn bar [[a b c]] (foo a b c))
#'user/bar
user=> (bar [1 2 3])
(1 2 3)

Using apply you can use anything that can be a sequence (it either 
implements or it can return something that implements ISeq).  Otherwise 
you could wrap it with a function like bar, which uses destructuring to 
decompose the vector and call foo explicitly.

I think the problem you are having has to do with wanting to apply 
arguments to a function inside a doto, the java interop stuff.  From 
what I can tell you won't be able to do it currently.  In ruby the 
foo(*args) syntax is called the splat operator, but I don't know if 
that's universal.

Later,
Jeff


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Rich Hickey]

On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> Are there any screencasts planned which will feature atoms? (I found
> that the screencasts are an excellent way of learning clojure).

Screencasts are generally a side-effect of a speaking engagement. I
imagine next time I give a talk, I'll talk about atoms too.

To address the general question about when to use atoms/refs/agents,
it helps to think of things this way:

First, note that in talking about atoms/refs/agents we are talking
about Clojure's reference types that allow changes to be seen by
multiple threads, so these three reference types are all shared
reference types.

There are two dimensions to the choice about using them, the first is
- will the changes be synchronous or asynchronous, and the second is,
will a change to this reference ever need to be coordinated with a
change to another reference or references.

Chouser made a nice diagram after I described this on IRC:

http://clojure.googlegroups.com/web/clojure-conc.png

As you can see, for coordinated changes, refs + transactions are the
only game in town, and asynchrony (beyond a set of commutes) doesn't
make much sense, so no reference type is coming to replace the X.

For independent change, you have two choices, agents and atoms.

Atoms are synchronous, the change happens on the calling thread. They
are as close to a plain variable as you get from Clojure, with a
critical benefit - they are thread safe, in particular, they are not
subject to read-modify-write race conditions. Your writes don't happen
unless they are a function of what was read. But modifications to
atoms are side effects, and thus need to be avoided in transactions.

Agents are asynchronous, and that can have important benefits. In
particular, it means actions get queued, and the sender can proceed
immediately. They provide a transparent interface to the threading
system and thread pools. Agents also cooperate with transactions in
ways that atoms cannot - e.g. agent sends are allowed in transactions
and get held until commit.

What's nice is the unified model underlying the reference types. All
can be read via deref/@, all are designed to refer to an immutable
data value, and to model change as a function of that value. All
support validators.

What that means is that, if you build your state transformation
functions as pure functions, you can freely choose/switch between the
different reference types, even using the same logic for two different
reference types.

However, they are different, and they have not been unified in the
areas in which they differ, in particular, they each have a unique
modification vocabulary - ref-set/alter/commute/send/send-off/swap!/
compare-and-set!.

In the end, Clojure is a tool, and will never be able to make
architectural decisions for you. Hopefully the above will help you
make informed choices.

The memoization example is a prime motivating case for atoms - a local
cache. It's also one that people routinely get multithread-wrong when
trying to implement with simple mutable variables.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Adding boolean?

[MikeM]

Perhaps the reason to not include it is that the utility of the
boolean? function is limited. Any value can be used where a clojure
boolean is expected - any non-nil value is true and nil is false.
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Test wether something is an atom (as it is known in Scheme)

[Arie van Wingerden]

Hi,

I am learning Clojure by working thru Kent Dybvigs book in Scheme and
Clojure at the same time. A nice way to discover the differences ;-)

I wonder if the next definition is appropriate to test if something ia an
atom (as Scheme sees it):

(defn atom? [x]
  (not (coll? x)))

Thx,
   Arie

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: PATCH: add overloaded (reader) and (writer) to clojure.contrib.duck-stream

[Rich Hickey]

On Dec 5, 3:23 am, walterc <[EMAIL PROTECTED]> wrote:
> i've added overloaded versions of reader and writer to
> clojure.contrib.duck-stream.  they can now take an additional string
> argument named "encoding" so content can be read or written with the
> specified encoding instead of default encoding.  the semantics of the
> original functions have not changed.
>
> the patch is uploaded to the files section of this 
> group:http://groups.google.com/group/clojure/web/duck-stream.patch
>

Thanks Walter. I'd just like to remind you and everyone else, you
cannot submit patches to clojure or clojure-contrib without a CA, and
people with CAs can't accept or submit them for you.

If you haven't sent one in, please do:

http://clojure.org/contributing

Thanks,

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Parth Malwankar]

Thanks for taking to time for such a detailed explanation Rich.
This makes things much clear. And thanks Chouser for the
pictorial representation.

Parth


On Dec 5, 6:24 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
>
> > Are there any screencasts planned which will feature atoms? (I found
> > that the screencasts are an excellent way of learning clojure).
>
> Screencasts are generally a side-effect of a speaking engagement. I
> imagine next time I give a talk, I'll talk about atoms too.
>
> To address the general question about when to use atoms/refs/agents,
> it helps to think of things this way:
>
> First, note that in talking about atoms/refs/agents we are talking
> about Clojure's reference types that allow changes to be seen by
> multiple threads, so these three reference types are all shared
> reference types.
>
> There are two dimensions to the choice about using them, the first is
> - will the changes be synchronous or asynchronous, and the second is,
> will a change to this reference ever need to be coordinated with a
> change to another reference or references.
>
> Chouser made a nice diagram after I described this on IRC:
>
> http://clojure.googlegroups.com/web/clojure-conc.png
>
> As you can see, for coordinated changes, refs + transactions are the
> only game in town, and asynchrony (beyond a set of commutes) doesn't
> make much sense, so no reference type is coming to replace the X.
>
> For independent change, you have two choices, agents and atoms.
>
> Atoms are synchronous, the change happens on the calling thread. They
> are as close to a plain variable as you get from Clojure, with a
> critical benefit - they are thread safe, in particular, they are not
> subject to read-modify-write race conditions. Your writes don't happen
> unless they are a function of what was read. But modifications to
> atoms are side effects, and thus need to be avoided in transactions.
>
> Agents are asynchronous, and that can have important benefits. In
> particular, it means actions get queued, and the sender can proceed
> immediately. They provide a transparent interface to the threading
> system and thread pools. Agents also cooperate with transactions in
> ways that atoms cannot - e.g. agent sends are allowed in transactions
> and get held until commit.
>
> What's nice is the unified model underlying the reference types. All
> can be read via deref/@, all are designed to refer to an immutable
> data value, and to model change as a function of that value. All
> support validators.
>
> What that means is that, if you build your state transformation
> functions as pure functions, you can freely choose/switch between the
> different reference types, even using the same logic for two different
> reference types.
>
> However, they are different, and they have not been unified in the
> areas in which they differ, in particular, they each have a unique
> modification vocabulary - ref-set/alter/commute/send/send-off/swap!/
> compare-and-set!.
>
> In the end, Clojure is a tool, and will never be able to make
> architectural decisions for you. Hopefully the above will help you
> make informed choices.
>
> The memoization example is a prime motivating case for atoms - a local
> cache. It's also one that people routinely get multithread-wrong when
> trying to implement with simple mutable variables.
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure-contrib build fails; ant does not like "path" element for jar

[Stefan Bodewig]

On 2008-12-05, Juergen Gmeiner <[EMAIL PROTECTED]> wrote:

> BUILD FAILED
> /Users/gj/site/clojure/clojure-contrib/build.xml:62: The  type
> doesn't support the nested "path" element.

That was added in Ant 1.7.0, released two years ago.

Stefan

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Mark McGranaghan]

This is indeed the definition used in the clojure.contrib.pred library:
http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure/contrib/pred.clj#L45

- Mark M.

On Fri, Dec 5, 2008 at 8:07 AM, Arie van Wingerden <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am learning Clojure by working thru Kent Dybvigs book in Scheme and
> Clojure at the same time. A nice way to discover the differences ;-)
>
> I wonder if the next definition is appropriate to test if something ia an
> atom (as Scheme sees it):
>
> (defn atom? [x]
>   (not (coll? x)))
>
> Thx,
>Arie
>
>
> >
>

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: License of/permission for Clojure's logo

[Tom Hickey]

I don't think we ever really discussed the colors representing
anything specific. I always vaguely thought of them as earth and sky.

I'm really glad that people like the logo!

Cheers,
Tom
http://tomhickey.com

On Dec 4, 12:46 pm, "Howard Lewis Ship" <[EMAIL PROTECTED]> wrote:
> +1 on the Logo.  I wish Tapestry had one half as good.
>
> A few of us were debating whether the green ying represented Java or
> the blue yang.  What's the official story?
>
>
>
> On Thu, Dec 4, 2008 at 9:04 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > On Dec 4, 11:46 am, samppi <[EMAIL PROTECTED]> wrote:
> >> Ah ha ha ha. Wow, my mistake. I'll make sure to spell it correctly.
>
> >> I totally agree with cogfun, though—it's a really nice logo. Did you
> >> make it yourself?
>
> > No, it was designed by my brother, Tom Hickey.
>
> > Rich
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Julian Morrison]

It seems like a pure efficiency optimization - used alone it doesn't
change semantics from dosync and alter over one ref.

It makes me feel wary. What if I changed my design and wanted to do
more in the same transaction? What if I later wanted to call a
function that uses it in the scope of a wider transaction? Or a
transaction that might retry? What if this was library code beyond my
power to alter?

On the other hand I understand how it could be hugely simpler and
quicker, and sometimes an immediate synchronous change is the right
design.

Perhaps it ought to have a warning sticker. "This is a side-effecting,
transaction-breaking blunt instrument contagious to any function that
calls it. Prefer using a ref, especially in library code".

On Dec 5, 1:02 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
>
> Docs here:
>
> http://clojure.org/atoms
>
> Feedback welcome,
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Rich Hickey]

On Dec 5, 8:50 am, Julian Morrison <[EMAIL PROTECTED]> wrote:
> It seems like a pure efficiency optimization - used alone it doesn't
> change semantics from dosync and alter over one ref.
>
> It makes me feel wary. What if I changed my design and wanted to do
> more in the same transaction? What if I later wanted to call a
> function that uses it in the scope of a wider transaction? Or a
> transaction that might retry? What if this was library code beyond my
> power to alter?
>
> On the other hand I understand how it could be hugely simpler and
> quicker, and sometimes an immediate synchronous change is the right
> design.
>
> Perhaps it ought to have a warning sticker. "This is a side-effecting,
> transaction-breaking blunt instrument contagious to any function that
> calls it. Prefer using a ref, especially in library code".
>

Well, for most of its intended uses, it isn't that, and that advice
doesn't hold. Take a memoization or similar cache - perfectly fine in
a transaction. Or a one-time init - also fine.

The ! is the sticker, I guess.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Rich Hickey]

On Dec 5, 8:24 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
>
> > Are there any screencasts planned which will feature atoms? (I found
> > that the screencasts are an excellent way of learning clojure).
>
> Screencasts are generally a side-effect of a speaking engagement. I
> imagine next time I give a talk, I'll talk about atoms too.
>
> To address the general question about when to use atoms/refs/agents,
> it helps to think of things this way:
>
> First, note that in talking about atoms/refs/agents we are talking
> about Clojure's reference types that allow changes to be seen by
> multiple threads, so these three reference types are all shared
> reference types.
>
> There are two dimensions to the choice about using them, the first is
> - will the changes be synchronous or asynchronous, and the second is,
> will a change to this reference ever need to be coordinated with a
> change to another reference or references.
>
> Chouser made a nice diagram after I described this on IRC:
>
> http://clojure.googlegroups.com/web/clojure-conc.png
>
> As you can see, for coordinated changes, refs + transactions are the
> only game in town, and asynchrony (beyond a set of commutes) doesn't
> make much sense, so no reference type is coming to replace the X.
>
> For independent change, you have two choices, agents and atoms.
>
> Atoms are synchronous, the change happens on the calling thread. They
> are as close to a plain variable as you get from Clojure, with a
> critical benefit - they are thread safe, in particular, they are not
> subject to read-modify-write race conditions. Your writes don't happen
> unless they are a function of what was read. But modifications to
> atoms are side effects, and thus need to be avoided in transactions.
>

Julian's post highlighted a point I need to make clear about the
above:

"Modifications to atoms are side effects, and thus need to be avoided
in transactions"

should be qualified with:

"unless you are ok with having them run more than once. For many
intended uses of atoms, like memoization caches, that's perfectly
fine."

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Stephen C. Gilardi]

On Dec 5, 2008, at 8:50 AM, Mark McGranaghan wrote:

> This is indeed the definition used in the clojure.contrib.pred  
> library:
> http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure/contrib/pred.clj#L45

That's true. However, with Clojure now having a specific meaning for   
"atom" that's different from that of the larger Lisp world, I'm  
wondering if it would be a good idea to remove atom? from pred.clj.

Feedback welcome.

--Steve


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Meikel Brandmeyer]

Hi,

On 5 Dez., 15:03, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> That's true. However, with Clojure now having a specific meaning for  
> "atom" that's different from that of the larger Lisp world, I'm  
> wondering if it would be a good idea to remove atom? from pred.clj.
>
> Feedback welcome.

I would think so. Or come up with a different name.
non-coll? ?

Sincerely
Meikel


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Rich Hickey]

On Dec 5, 9:03 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2008, at 8:50 AM, Mark McGranaghan wrote:
>
> > This is indeed the definition used in the clojure.contrib.pred
> > library:
> >http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure...
>
> That's true. However, with Clojure now having a specific meaning for
> "atom" that's different from that of the larger Lisp world, I'm
> wondering if it would be a good idea to remove atom? from pred.clj.
>
> Feedback welcome.
>

atom?/p is not one of strongest or best-named abstractions in older
Lisps. Maybe it made sense in a world with only one composite data
structure. Good riddance I say.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Randall R Schulz]

On Friday 05 December 2008 05:24, Rich Hickey wrote:
> On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> > Are there any screencasts planned which will feature atoms? (I
> > found that the screencasts are an excellent way of learning
> > clojure).
>
> Screencasts are generally a side-effect of a speaking engagement. I
> imagine next time I give a talk, I'll talk about atoms too.

Are you ever going to get out to the Silicon Valley area to give a talk?


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: (doc)strings after param in defn

[Randall R Schulz]

On Thursday 04 December 2008 23:23, Meikel Brandmeyer wrote:
> Hi,
>
> On 5 Dez., 00:38, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> > ...
> ...
>
> > And am I mistaken in my reading of the API docs for (defmulti ...)
> > and (defmethod ...) or is there no accommodation in either for
> > doc-strings? Surely that's not the case, right?
>
> You can always use:
>
>   (defmulti #^{:arglists '([a b] [a b c]) :doc "bla"} foo identity)

Why all the circumlocutions to bring a multimethod up to the level of 
documentation support of a plain function?


> ...
>
> Sincerely
> Meikel


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: function args question

[Jeff Rose]

hitesh wrote:
> I'm working on some opengl code in clojure and I want to specify a
> vertex.  However, instead of passing in the three arguments it wants,
> I want to specify a single vector of 3 elements.  How can I do this?
>
> Here's what it would normally look like (gl represents the current
> opengl drawing context object):
>
> (.glVertex3f gl 1.0 3.7 0.0)
>
>
> Here's what I want to write:
>
> (let [ point [1.0 3.7 0.0] ]
>   (.glVertex3f gl point))
>
>
> I've tried playing around with apply.
>
> (apply .glVertex3f gl point)
>
> But it generates an error: no matching method glVertex3f for class
> com.sun.opengl.impl.GLImpl.
>
> I'm not sure what this concept is called, but here's some code in
> other languages that demonstrates it.
>
> Here's the equivalent concept in Haskell
>
> foo :: (Show a) => a -> a -> IO ()
> foo a b = mapM_ print [a, b]
>
> *Main> uncurry foo (1,2)
> 1
> 2
>
>
> Or in Ruby
>
> def foo(a,b)
>   puts a
>   puts b
> end
>
> x = [1,2]
>
> foo *x
> 1
> 2
>
>
> Any ideas?
>
> Thanks,
> Hitesh
>   
Ok, maybe I just ran into a nicer answer to your problem.  There is a 
macro called memfn that is used to turn java functions into first class 
functions.  Here is an example with strings, which are just standard 
java string objects so it should be the same:

user=> (def index-of (memfn indexOf substr))
#'user/index-of
user=> (def mystr "foobar")
#'user/mystr
user=> (apply index-of [mystr "ba"])
3

Where the "foobar" string is the instance that is getting the indexOf 
called, like this in java:

mystr.indexOf("ba")

This could be another way to do what you are trying to do.

-Jeff

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Rich Hickey]

On Dec 5, 9:09 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> On Friday 05 December 2008 05:24, Rich Hickey wrote:
>
> > On Dec 5, 5:51 am, bOR_ <[EMAIL PROTECTED]> wrote:
> > > Are there any screencasts planned which will feature atoms? (I
> > > found that the screencasts are an excellent way of learning
> > > clojure).
>
> > Screencasts are generally a side-effect of a speaking engagement. I
> > imagine next time I give a talk, I'll talk about atoms too.
>
> Are you ever going to get out to the Silicon Valley area to give a talk?
>

I hope to get a slot at Java One in SF this spring.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Randall R Schulz]

On Friday 05 December 2008 06:33, Rich Hickey wrote:
> On Dec 5, 9:09 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> > ...
> >
> > Are you ever going to get out to the Silicon Valley area to give a
> > talk?
>
> I hope to get a slot at Java One in SF this spring.

Anything less pricey?

Maybe you could swing by the SVJUG while you're out here?


> Rich


RRS

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: DISCUSS: replace (rand)

[bOR_]

On Dec 4, 9:07 am, "don.aman" <[EMAIL PROTECTED]> wrote:
> Since we're being all high-level, it'd be good for a random function
> which allows us to specify the range of numbers, since % doesn't
> promise an even spread of probabilities (especially for large ranges).

Not sure if I understand the second part (% an even part), but I
realized that
a random function for a specific range of numbers can be written using
the
lazy example in this thread. (I earlier got stuck trying to use (cycle
(rand-int 10))
for that.

(defn lazy-rand-vect
  "a lazy cycle of random elements taken from a vector."
  [vector]
(lazy-cons (nth vector (rand-int (count vector))) (lazy-rand-vect
vector)))


example:
(def amino_acids 21)
(def virus_length 1000)

(defn make-virus
  "Creates a virus of length virus_length"
  []
  (apply str (take virus_length (lazy-rand-vect (apply vector (map #
(char (+ 65 %)) (range 10))
  ; old way also worked, but lazy-rand-vect I can use for a few other
things as
well.:
  ;(apply str (take virus_length (map #(char (+ (rand-int amino_acids)
65 %)) (cycle (list 0))

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Arie van Wingerden]

Hi Mark,

didn't know about that. But I'm glad it appears to be okay then.

Arie

2008/12/5 Mark McGranaghan <[EMAIL PROTECTED]>

>
> This is indeed the definition used in the clojure.contrib.pred library:
>
> http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure/contrib/pred.clj#L45
>
> - Mark M.
>
> On Fri, Dec 5, 2008 at 8:07 AM, Arie van Wingerden <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > I am learning Clojure by working thru Kent Dybvigs book in Scheme and
> > Clojure at the same time. A nice way to discover the differences ;-)
> >
> > I wonder if the next definition is appropriate to test if something ia an
> > atom (as Scheme sees it):
> >
> > (defn atom? [x]
> >   (not (coll? x)))
> >
> > Thx,
> >Arie
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Arie van Wingerden]

Hi Rich,

right. But still I think Meikel has got a valid point that a function would
need to be defined for that.

I also wondered whether a kind of  type? function would be appropriate.
So (type? 3) would return integer etc.

Arie

2008/12/5 Rich Hickey <[EMAIL PROTECTED]>

>
>
>
> On Dec 5, 9:03 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> > On Dec 5, 2008, at 8:50 AM, Mark McGranaghan wrote:
> >
> > > This is indeed the definition used in the clojure.contrib.pred
> > > library:
> > >http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure.
> ..
> >
> > That's true. However, with Clojure now having a specific meaning for
> > "atom" that's different from that of the larger Lisp world, I'm
> > wondering if it would be a good idea to remove atom? from pred.clj.
> >
> > Feedback welcome.
> >
>
> atom?/p is not one of strongest or best-named abstractions in older
> Lisps. Maybe it made sense in a world with only one composite data
> structure. Good riddance I say.
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: PATCH: Fix in-case macro from clojure.contrib fcase library

[Stuart Sierra]

Fixed. Thanks,
-Stuart Sierra

On Dec 5, 12:39 am, "Tchavdar Roussanov" <[EMAIL PROTECTED]> wrote:
> The attached patch fixes the compile error when in-case macro is used in
> different name space. The expanded code contains a private function from
> clojure.contrib.fcase name space.
>
> --Tchavdar
>
>  fcase.patch
> < 1KViewDownload
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Elegant but very slow

[Stuart Sierra]

On Dec 4, 7:09 pm, "Christian Vest Hansen" <[EMAIL PROTECTED]>
wrote:
> Ah, disregard that. I found the rules:
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all#about

Yeah -- " this is an adaptation of a benchmark for testing GC so we
are interested in the whole tree being allocated before any nodes are
GC'd - which probably excludes lazy evaluation."

So this is testing the compiler and garbage collector more than the
language.  Given that Clojure's immutable data structures are much
more complex than the simple classes in the Java example, I don't
think it will ever be possible to write a competitive implementation
in pure Clojure.  However, the advantage of having Java as a host
language is that you can use it for low-level operations like this.

-Stuart Sierra
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Stuart Sierra]

On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.

I like it; it greatly simplifies a common use for Refs.

"Clojure.  Sometimes you just need to mutate."

"Clojure.  Mutate safely."

-Stuart Sierra
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

reduction

[Chouser]

Google groups files section is having issues.
Here's 'reduction' as discussed in IRC, mostly written by Rich.

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

diff --git a/src/clj/clojure/core.clj b/src/clj/clojure/core.clj
index 4aad594..a027e00 100644
--- a/src/clj/clojure/core.clj
+++ b/src/clj/clojure/core.clj
@@ -535,7 +535,20 @@
   "Returns a seq of the items in coll in reverse order. Not lazy."
   [coll]
 (reduce conj nil coll))
-  
+
+(defn reduction
+  "Returns a lazy seq of the intermediate values of the reduction (as
+  per reduce) of coll by f, starting with init."
+  ([f [x & xs :as coll]]
+   (when (seq coll)
+ (if-let [[x2 & xs2] xs]
+   (reduction f (f x x2) xs2)
+   (cons x nil
+  ([f init [x & xs :as coll]]
+   (if (seq coll)
+ (lazy-cons init (reduction f (f init x) xs))
+ (cons init nil
+
 ;;math stuff
 (defn +
   "Returns the sum of nums. (+) returns 0."

Re: Test wether something is an atom (as it is known in Scheme)

[Rich Hickey]

On Dec 5, 9:07 am, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 5 Dez., 15:03, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
>
> > That's true. However, with Clojure now having a specific meaning for
> > "atom" that's different from that of the larger Lisp world, I'm
> > wondering if it would be a good idea to remove atom? from pred.clj.
>
> > Feedback welcome.
>
> I would think so. Or come up with a different name.
> non-coll? ?
>

We have complement and not. Do we need non-xxx? versions of all the
predicates? I don't think non-coll? is special.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Test wether something is an atom (as it is known in Scheme)

[Rich Hickey]

On Dec 5, 10:28 am, "Arie van Wingerden" <[EMAIL PROTECTED]> wrote:
> Hi Rich,
>
> right. But still I think Meikel has got a valid point that a function would
> need to be defined for that.
>
> I also wondered whether a kind of  type? function would be appropriate.
> So (type? 3) would return integer etc.
>

There is class, and, more useful, instance?

Rich

> 2008/12/5 Rich Hickey <[EMAIL PROTECTED]>
>
>
>
> > On Dec 5, 9:03 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> > > On Dec 5, 2008, at 8:50 AM, Mark McGranaghan wrote:
>
> > > > This is indeed the definition used in the clojure.contrib.pred
> > > > library:
> > > >http://github.com/kevinoneill/clojure-contrib/tree/master/src/clojure.
> > ..
>
> > > That's true. However, with Clojure now having a specific meaning for
> > > "atom" that's different from that of the larger Lisp world, I'm
> > > wondering if it would be a good idea to remove atom? from pred.clj.
>
> > > Feedback welcome.
>
> > atom?/p is not one of strongest or best-named abstractions in older
> > Lisps. Maybe it made sense in a world with only one composite data
> > structure. Good riddance I say.
>
> > 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Monadic Parsing

[Randall R Schulz]

On Wednesday 03 December 2008 15:13, jim wrote:
> Continuing with the monad theme, I decided to implement monadic
> parsing in Clojure.  Erik Meijer and Graham Hutton published a paper
> called "Monadic Parsing in Haskell" and I implemented the examples
> from that paper in Clojure.  The code is available here:

Thanks. I'm finding this an interesting aid as I learn about monads 
specifically and functional programming in general.


> http://groups.google.com/group/clojure/web/monad-parser.clj
>
> And you also need the monad code from here:
>
> http://clojure.googlegroups.com/web/monad-redux.clj

I notice these files use the (comment ...) macro to enclose what is 
essentially arbitrary English text.

Is this a good idea? It seems vulnerable to a change that would render 
the enclose content not syntactically valid.


> The code is uncommented and should be read in parallel with the
> original paper from here (pdf):
>
> http://www.cs.nott.ac.uk/~gmh/pearl.pdf

I also retrieved the 1990 ACM paper "Comprehending Monads" by Philip 
Wadler. I forget which ACM publication it appeared it, but it can 
easily be found via Google Scholar or other search service.



> Comments welcome.
>
> Next up: monad transformers

I look forward to it.


> Jim


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Adding boolean?

[Tom Emerson]

On Fri, Dec 5, 2008 at 8:25 AM, MikeM <[EMAIL PROTECTED]> wrote:
> Perhaps the reason to not include it is that the utility of the
> boolean? function is limited. Any value can be used where a clojure
> boolean is expected - any non-nil value is true and nil is false.

But this isn't about looking at a boolean context, it is about testing
whether I'm looking specifically at 'true' or 'false'. The context is
when marshalling a structure into a string for inclusion in an
existing system, where I define

(def *ARGS* {:foo 0 :bar true :baz "hello"})

And want to turn this into a string like:

foo:I:0|bar:B:true|baz:S:hello

Where the type of the argument is encoded as "I" (integer), "B"
(boolean), or "S" string. The function to do this is trivial:

(defn- type2id
  "Generates the appropriate type code for the type of the v"
  [v]
  (cond (integer? v) "I"
(string? v) "S"
(boolean? v) "B"))

assuming that the predicate boolean? exists. In my view having this
would make the API more orthogonal, even if its actual use is rather
specialized.

-tree

-- 
Tom Emerson
[EMAIL PROTECTED]
http://www.dreamersrealm.net/~tree

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Rich Hickey]

On Dec 5, 10:50 am, Chouser <[EMAIL PROTECTED]> wrote:
> Google groups files section is having issues.
> Here's 'reduction' as discussed in IRC, mostly written by Rich.
>

Attachments are preferred - thanks!

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Stuart Sierra]

On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> I've added a new reference type - atom.
> Feedback welcome,

A request, if it's possible: allow watchers to be set on atoms and
refs in addition to agents.

I'd like to experiment with "reactive" programming using the different
transaction models.

-Stuart Sierra
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Mutual definitions (exercise 2.8.6 in Kent Dybvigs book TSPL)

[Arie van Wingerden]

Hi,

I tried to use definitions which call each other, like so:

(defn is-odd? [n]
  (if (= n 0)
  false
  (is-even? (- n 1

(defn is-even? [n]
  (if (= n 0)
  true
  (is-odd? (- n 1

but obviously Clojure rejects this, saying:
   Exception in thread "main" java.lang.Exception: Unable to resolve symbol:
is-even? in this context
which refers to "is-even?" in the definition of is-odd?

Since I am very new to Clojure I may have missed a language construct to
resolve this issue :-)

Thx,
   Arie

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Rich Hickey]

On Fri, Dec 5, 2008 at 11:01 AM, Stuart Sierra
<[EMAIL PROTECTED]>wrote:

>
> On Dec 4, 8:02 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> > I've added a new reference type - atom.
> > Feedback welcome,
>
> A request, if it's possible: allow watchers to be set on atoms and
> refs in addition to agents.
>
> I'd like to experiment with "reactive" programming using the different
> transaction models.
>

I'm working on that.  It has utility even outside traditional reactive
contexts, in moving the imperative part of your logic outside of your state
transformation function. I think it's a good model.

Chouser recently went through an interesting exercise doing just that,
perhaps he'll chime in with his experiences.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Randall R Schulz]

On Friday 05 December 2008 08:00, Rich Hickey wrote:
> On Dec 5, 10:50 am, Chouser <[EMAIL PROTECTED]> wrote:
> > Google groups files section is having issues.
> > Here's 'reduction' as discussed in IRC, mostly written by Rich.
>
> Attachments are preferred - thanks!

It came through as an attachment here.


> Rich


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Mutual definitions (exercise 2.8.6 in Kent Dybvigs book TSPL)

[Randall R Schulz]

On Friday 05 December 2008 08:07, Arie van Wingerden wrote:
> Hi,
>
> I tried to use definitions which call each other, like so:
>
> (defn is-odd? [n]
>   (if (= n 0)
>   false
>   (is-even? (- n 1
>
> (defn is-even? [n]
>   (if (= n 0)
>   true
>   (is-odd? (- n 1
>
> but obviously Clojure rejects this, saying:
>Exception in thread "main" java.lang.Exception: Unable to resolve
> symbol: is-even? in this context
> which refers to "is-even?" in the definition of is-odd?
>
> Since I am very new to Clojure I may have missed a language construct
> to resolve this issue :-)

You can (def is-even?) before your (defn is-odd? ...), which will allow 
it to compile.

However, this implementation is very inefficient, since it' will call 
mutually recursively back and forth (without any kind of tail-call 
optimization, at least as written) decrementing the initial argument 
until it gets to zero.

The trampoline mechanism can fix the fact that this code consumes an 
amount of stack space linearly dependent on the initial argument, but 
clearly this is not the way to test for evenness or oddness!


> Thx,
>Arie


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Mutual definitions (exercise 2.8.6 in Kent Dybvigs book TSPL)

[Arie van Wingerden]

Hi Randall,

yes, I am very aware that it is not an efficient solution ;-)

It is only an exercise just to make (Scheme) students aware of the
possibilities of mutual definitions.
The assignment in Kent's book reads:
;;; Exercise 2.8.6.
;;; All of the recursive procedures shown so far have been directly
;;; recursive. That is, each procedure directly applies itself to a new
;;; argument. It is also possible to write two procedures that use each
;;; other, resulting in indirect recursion. Define the procedures odd?
;;; and even?, each in terms of the other. [Hint: What should each return
;;; when its argument is 0?]

Thanks for the reply!
   Arie


2008/12/5 Randall R Schulz <[EMAIL PROTECTED]>

>
> On Friday 05 December 2008 08:07, Arie van Wingerden wrote:
> > Hi,
> >
> > I tried to use definitions which call each other, like so:
> >
> > (defn is-odd? [n]
> >   (if (= n 0)
> >   false
> >   (is-even? (- n 1
> >
> > (defn is-even? [n]
> >   (if (= n 0)
> >   true
> >   (is-odd? (- n 1
> >
> > but obviously Clojure rejects this, saying:
> >Exception in thread "main" java.lang.Exception: Unable to resolve
> > symbol: is-even? in this context
> > which refers to "is-even?" in the definition of is-odd?
> >
> > Since I am very new to Clojure I may have missed a language construct
> > to resolve this issue :-)
>
> You can (def is-even?) before your (defn is-odd? ...), which will allow
> it to compile.
>
> However, this implementation is very inefficient, since it' will call
> mutually recursively back and forth (without any kind of tail-call
> optimization, at least as written) decrementing the initial argument
> until it gets to zero.
>
> The trampoline mechanism can fix the fact that this code consumes an
> amount of stack space linearly dependent on the initial argument, but
> clearly this is not the way to test for evenness or oddness!
>
>
> > Thx,
> >Arie
>
>
> Randall Schulz
>
> >
>

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Mutual definitions (exercise 2.8.6 in Kent Dybvigs book TSPL)

[Stuart Sierra]

On Dec 5, 11:17 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> You can (def is-even?) before your (defn is-odd? ...), which will allow
> it to compile.

The recently-added "declare" is for just this purpose:
(declare is-even?)

-Stuart Sierra
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: PATCH: add overloaded (reader) and (writer) to clojure.contrib.duck-stream

[walterc]

will do

On Dec 5, 9:33 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Dec 5, 3:23 am, walterc <[EMAIL PROTECTED]> wrote:
>
> > i've added overloaded versions of reader and writer to
> > clojure.contrib.duck-stream.  they can now take an additional string
> > argument named "encoding" so content can be read or written with the
> > specified encoding instead of default encoding.  the semantics of the
> > original functions have not changed.
>
> > the patch is uploaded to the files section of this 
> > group:http://groups.google.com/group/clojure/web/duck-stream.patch
>
> Thanks Walter. I'd just like to remind you and everyone else, you
> cannot submit patches to clojure or clojure-contrib without a CA, and
> people with CAs can't accept or submit them for you.
>
> If you haven't sent one in, please do:
>
> http://clojure.org/contributing
>
> Thanks,
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Chouser]

On Fri, Dec 5, 2008 at 10:50 AM, Chouser <[EMAIL PROTECTED]> wrote:
> Google groups files section is having issues.
> Here's 'reduction' as discussed in IRC, mostly written by Rich.

I messed it up anyway -- tried to use if-let too early.
Try this patch instead.

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

commit f491694550c8ea0b528afd2d98268572a5dab599
Author: Chouser <[EMAIL PROTECTED]>
Date:   Fri Dec 5 11:32:59 2008 -0500

reduction

diff --git a/src/clj/clojure/core.clj b/src/clj/clojure/core.clj
index 4aad594..75da416 100644
--- a/src/clj/clojure/core.clj
+++ b/src/clj/clojure/core.clj
@@ -2738,6 +2738,19 @@
   coll (range (count coll)))
   (map #(if-let [e (find smap %)] (val e) %) coll)))
 
+(defn reduction
+  "Returns a lazy seq of the intermediate values of the reduction (as
+  per reduce) of coll by f, starting with init."
+  ([f [x & xs :as coll]]
+   (when (seq coll)
+ (if-let [[x2 & xs2] xs]
+   (reduction f (f x x2) xs2)
+   (cons x nil
+  ([f init [x & xs :as coll]]
+   (if (seq coll)
+ (lazy-cons init (reduction f (f init x) xs))
+ (cons init nil
+
 (defmacro dosync 
   "Runs the exprs (in an implicit do) in a transaction that encompasses
   exprs and any nested calls.  Starts a transaction if none is already

Another build.xml patch for contrib (was: Re: clojure-contrib build fails; ant does not like "path" element for jar)

[Meikel Brandmeyer]

Hi,

Am 05.12.2008 um 14:40 schrieb Stefan Bodewig:

BUILD FAILED
/Users/gj/site/clojure/clojure-contrib/build.xml:62: The  type
doesn't support the nested "path" element.


That was added in Ant 1.7.0, released two years ago.


Hmmm... For me the path element works and I have an ant 1.7.0...

Anyway I added the local.properties file as suggested and also
changed the path to fileset for the issue above. It seems, that
in classpath should also contain pathelements instead paths.
So I changes this also.

I'm not an ant guru, so someone with more ant experience
should have a look before committing.

Sincerely
Meikel



build.xml.patch
Description: Binary data




smime.p7s
Description: S/MIME cryptographic signature

Re: A try on condp (was: Re: proposal: match multimethod)

[Meikel Brandmeyer]

Hi,

Am 04.12.2008 um 10:44 schrieb Meikel Brandmeyer:

I almost whipped this up yesterday, but I got sidetracked thinking
about how best to provide a feature like Scheme's cond's =>. Do you
know it? It feeds the value of the test to the fn on the rhs of the
clause. It can be useful.


It seems my patch is completely needless: In contrib
there is already cond-let, which does what you want.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: Mutual definitions (exercise 2.8.6 in Kent Dybvigs book TSPL)

[Arie van Wingerden]

Ah, yes! That's defenitely more elegant.

Thx,
   Arie

2008/12/5 Stuart Sierra <[EMAIL PROTECTED]>

>
> On Dec 5, 11:17 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> > You can (def is-even?) before your (defn is-odd? ...), which will allow
> > it to compile.
>
> The recently-added "declare" is for just this purpose:
> (declare is-even?)
>
> -Stuart Sierra
> >
>

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

conj-when

[[EMAIL PROTECTED]]

I think this is pretty useful, but I'm a noob and don't know better :)
I found myself trying to use atoms and refs to start with rather than
taking a functional approach, maybe something like this is good in the
standard lib to emphasize a functional approach? Or maybe it exists
and I don't know it

(defmacro conj-when [pred new & coll]
`(let [test# ~pred]
 (if test#
 (conj [EMAIL PROTECTED] ~new)
 [EMAIL PROTECTED])))

and an example ...

(defn- syncPacket [r]
  (let [state (r :state)]
(conj-when (= state :WINNER) { :WINNER (r :winBall) }
(conj-when (or (= state :CONGRATS) (= state 
:START)) {:COUNTDOWN
(r :countDown)}
{
 :CUR_SEC (r :sec)
 :PRIZE (r :prize)
 :JACKPOT (r :jackpot)
 :BUY_INS (count @(r :cards))
 :STATE (subs (str state) 1)
 :MESSAGE (r :message)
 }


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Improved Maven Build

[Howard Lewis Ship]

I think the best solution is to use Ant to build, but:

- Include a pom.xml
- Build binary and source artifacts
- Use the Maven Ant Tasks to deploy the artifacts to a local (for
snapshots) or remove (for final builds) repository

Also, I think if the Java code was published, along with Javadoc, we'd
have some incentive to comment the code. The Clojure code base is
woefully under-documented.

On Fri, Dec 5, 2008 at 12:48 AM, ivant <[EMAIL PROTECTED]> wrote:
>
> I remember reading somewhere[1], that we can actually run ant from
> maven.  It just occurred to me, that we can build the pom with
> groupId, artifactId and version, which actually uses ant for the
> build.  This way the builds will be identical and we'll only have to
> update the version in the pom.
>
> I don't have the time right now, but I can try to build the pom in the
> weekend.
>
> [1] Probably here: http://books.sonatype.com/maven-book/index.html
>
> On Dec 4, 8:59 pm, Luke Amdor <[EMAIL PROTECTED]> wrote:
>> As an avid Maven fan, I really don't think Clojure would really
>> benefit much from having a Maven build. It really doesn't have any
>> dependencies to speak of and is extremely easy to build.
>>
>> The main thing that I would like to be able to do is to easily get the
>> newest Clojure snapshots and releases. So being able to refer to a
>> dependency on Clojure in my own project's pom.xml is important to me.
>>
>> Just my 2c.
>>
>> Luke
>>
>> On Dec 4, 7:24 am, verec <[EMAIL PROTECTED]>
>> wrote:
>>
>> > +1 (avoid Maven, drop pom)
>>
>> > I'm just out of a project that has used Maven for more than 18 month.
>> > The pain and frustration caused by the slowness and compexity of
>> > Maven's "download the whole internet" approach can be matched only
>> > bu the willingness of team astronauts to introduce Maven plugins in
>> > the build process, more often that not to fix an endogenous problem.
>>
>> > +1 (keep Ant)
>> > --
>> > JFB
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

unsupported binding form for cond-let

[Brian Doyle]

I started to play with cond-let in the contrib.cond package and got an
unexpected error:

user=> (cond-let [x (zero? 0)] (println "hello world"))
java.lang.Exception: Unsupported binding form: (zero? 0) (NO_SOURCE_FILE:11)

user=> (cond-let x (zero? 0) (println "hello world"))
hello world

Maybe it was overlooked when making the binding forms more
consistent?   Like:

user=> (when-let [x (zero? 0)] (println "hello world"))
hello world

user=> (if-let [x true] (println "hello world"))
hello 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Running out of memory when using filter?

[Paul Mooser]

I'm continuing to try to suss this out, so I decided to run with a
memory profiler. I'm seeing tens of thousands of lazy conses
accounting for hundreds of megabytes of memory, which perhaps implies
I'm holding on to a reference to them somewhere, but I just don't see
how, since as I showed above, I am only referring to these sequences
in the context of doseq.

I'll post an update if I find a smoking gun.
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Erlang vs Clojure

[Jeremy Dunck]

On Oct 17, 6:01 pm, Luc Prefontaine <[EMAIL PROTECTED]>
wrote:
> I am not very far from tackling this issue. In our bus messaging system,
> we are using Terracotta with some Java components
> and it's a matter of weeks before we start to investigate how we can
> bridge Clojure and Terracotta.
>
> A customer asked us about some new functionality today and I see a need
> to fill the Terracotta/Clojure gap
> somehow.
>
> I'll comeback toward the end of November with some proposal.

Luc, I'm interested.  How's it going?

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: unsupported binding form for cond-let

[Stephen C. Gilardi]

On Dec 5, 2008, at 1:33 PM, Brian Doyle wrote:

> I started to play with cond-let in the contrib.cond package and got an
> unexpected error:
>
> user=> (cond-let [x (zero? 0)] (println "hello world"))
> java.lang.Exception: Unsupported binding form: (zero? 0)  
> (NO_SOURCE_FILE:11)

I updated cond-let yesterday to support the new "everything that  
introduces names like let does has its binding forms in a vector"  
regime. However, in the case of cond-let, only the binding-form  
appears inside the vector, not a value, and there should only be one  
binding-form as the rest are ignored.

Here's an example with the current cond-let from svn:


Contents of file cond_let_example.clj on classpath:


(ns cond-let-example
   (:use clojure.contrib.cond))

(def letters {"a" :vowel
"b" :consonant
"c" :consonant
"d" :consonant
"e" :vowel})

(def numbers {1 :odd
2 :even
3 :odd
4 :even
5 :odd})

(defn classify
   [x]
   (cond-let [type]
(letters x) type
(numbers x) (str (name type))
:else "dunno"))


Repl Session


Clojure
user=> (use 'cond-let-example)
nil
user=> (doseq [i ["a" "r" "t" "f" "u" "l" :blub 1 9 7 3 :life "on"  
'mars]] (prn (classify i)))
:vowel
"dunno"
"dunno"
"dunno"
"dunno"
"dunno"
"dunno"
"odd"
"dunno"
"dunno"
"odd"
"dunno"
"dunno"
"dunno"
nil


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Running out of memory when using filter?

[Paul Mooser]

My operating theory was that the anonymous function being used by
filter was closing over both parameters to the enclosing function, but
making a simple modification to avoid that didn't seem to address the
problem.
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Erlang vs Clojure

[Luc Prefontaine]

We just started to look at the issue. Got late in the user acceptance
tests because of the radiology equipment supplier
is dragging it's feet.

I feel we will start before Xmas to put together a prototype.

I really want this to come to life because we could use cooperative
Clojure instances on our bus. This would also
provide us another form of persistance. Presently we rely on ActiveMq
queues but to maximize parallelism we
need another model and building that from queues would be harder.

I'll keep everyone posted. As soon as I can get my hands on it without
being interrupted by the current
release of our bus we launch this.

We are scheduled to go live January 5th so that's why I am struggling
and pushing on that other supplier to get his act together.
Grrr ! They're big, we're small and we move 1000 times faster. It's
frustrating. They need 3 people to do the job of one of us
and still they can't turn on a dime like us.

Luc

On Fri, 2008-12-05 at 10:42 -0800, Jeremy Dunck wrote:

> 
> 
> On Oct 17, 6:01 pm, Luc Prefontaine <[EMAIL PROTECTED]>
> wrote:
> > I am not very far from tackling this issue. In our bus messaging system,
> > we are using Terracotta with some Java components
> > and it's a matter of weeks before we start to investigate how we can
> > bridge Clojure and Terracotta.
> >
> > A customer asked us about some new functionality today and I see a need
> > to fill the Terracotta/Clojure gap
> > somehow.
> >
> > I'll comeback toward the end of November with some proposal.
> 
> Luc, I'm interested.  How's it going?
> 
> > 
> 

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Mark Engelberg]

So, earlier, I asked how atoms differ from using commute on refs.

It sounds like the answer is that if you use atoms in a larger
transaction, then as soon as the atom set is encountered, it actually
changes instantly, so if you rollback, and do the transaction again,
it's already been set, and will do so again, so your code surrounding
the atom set better not make assumptions about whether the atom
has/has not been set.

On the other hand, a ref participates in the larger transaction, so
any modification to the ref will rollback if the larger transaction is
rolled back, so when the larger transaction retries, code before the
ref set can safely assume that the ref has not yet been set.

Is this understanding correct?

--Mark

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

New Tracing Library

[Craig McDaniel]

I'd like to submit a new tracing library to clojure.contrib. Please
try it out and let me know if it is suitable.

The existing clojure.contrib.trace macros allow you to explicitly
trace any expression or redefine a function with deftrace so that it
is traced. But deftrace doesn't work with functions with multiple
arity or comment string. To trace many functions, you'd have to do a
mass change of your defns to deftrace.

This new library keeps track of functions you're tracing, allows you
to toggle trace on/off on on functions, and trace every function in a
namespace. If you reload a function, tracing is disabled for that
function. The toggle trace and untrace all functions could be used to
fill some missing pieces in emacs/slime/swank-clojure. It shouldn't be
too difficult to make a simple profiler from it.

The user interface is:

(defmacro toggle-trace
  "Toggles tracing of function f"
  [f]

(defmacro trace-on
  "Turn trace on for function f"
  [f]

(defmacro trace-off
  "Turn trace off for function f"
  [f]

(defn trace-ns
  "trace everything in the namespace ns. Don't try to trace
clojure.core."
  [ns]

(defn untrace-ns
  "untrace everything in the namespace ns"
  [ns]

(defn untrace-all
  "untrace everything and clean out traced-map"
  []

I'm pasting the code to http://paste.lisp.org/display/71652.

-Craig
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: New Tracing Library

[Craig McDaniel]

Correction: http://paste.lisp.org/display/71656

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Propose retiring clojure.contrib.pred

[Stephen C. Gilardi]

The most useful predicates that were once defined in  
clojure.contrib.pred are now defined in clojure.core. It's currently  
only a shadow of its former self and should perhaps be retired.

Is anyone relying on what remains in clojure.contrib.pred?

Is there any objection to me deleting it from clojure-contrib?

--Steve


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Running out of memory when using filter?

[Paul Mooser]

The memory profiler says that the following object is a GC root which
is holding onto the collection being passed into the filter call:

clojure.core$filter__3364$fn__3367

I'm not familiar enough with clojure's internals to speculate about
what that means, beyond what I've already mentioned previously in the
thread. Does anyone else have any ideas?
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

My Clojure Emacs Setup (I'll show mine if you show yours)

[bc]

My setup is here:
http://bc.tech.coop/blog/081205.html

What does your Clojure Emacs setup look like?

--
Bill Clementson
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: DISCUSS: replace (rand)

[Mark H.]

On Dec 4, 12:07 am, "don.aman" <[EMAIL PROTECTED]> wrote:
> Since we're being all high-level, it'd be good for a random function
> which allows us to specify the range of numbers, since % doesn't
> promise an even spread of probabilities (especially for large ranges).

Sure it does, as long as you get enough random bits that scaling the
output of the number to an arbitrary range doesn't lose more random
bits than it promises to give.  It's not the PRNG's responsibility to
do that, it's the responsibility of the function doing the scaling.
Furthermore, if you're in floating-point arithmetic, then scaling by
powers of two doesn't lose any bits as long as the numbers don't
overflow or underflow.  You'll lose a bit or two from going from the
powers of two to the range you want, but you can always get a few
extra random bits to account for that if you're concerned.

mfh
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Another build.xml patch for contrib

[Stephen C. Gilardi]

On Dec 5, 2008, at 12:41 PM, Meikel Brandmeyer wrote:

> Anyway I added the local.properties file as suggested and also
> changed the path to fileset for the issue above. It seems, that
> in classpath should also contain pathelements instead paths.
> So I changes this also.
>
> I'm not an ant guru, so someone with more ant experience
> should have a look before committing.

This works for me and I'd like to commit it. I'll wait a bit for ant- 
aware folks to comment.

--Steve


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.repl-ln available

[Stephen C. Gilardi]

On Dec 3, 2008, at 11:39 AM, Randall R Schulz wrote:

> Perhaps Steve would consider applying them to making his fancy REPL  
> more
> robust for terminal users?

I like the idea. If someone would like to work out the basics and post  
some example code, I'll be happy to try to get it running in repl-ln.

--Steve


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Zipper & Local Context?

[Randall R Schulz]

Hi,

I looked at the Clojure implementation of Huet's Zipper and it looks 
great. I like how it delegates construction and dissection of the tree 
structure to client-supplied functions so that it is generic w.r.t. to 
any types (especially for me, pre-existing, non-Clojure Java types) 
that can be deemed to encode a tree structure.

However, I would like to be able to examine the tree in the locality of 
the current traversal point through path or position specifications. 
This approach is commonly used in describing algorithms about logical 
formulas (which are inherently tree-structured). If you're not familiar 
with the notion, these paths / positions are directly analogous to file 
system path names, except that one uses integers to label the arcs, 
said integers being ordinals in the child sequence of a given node.

It seems to me that being able to access local context using such paths 
during a tree traversal would be far more convenient in many cases to 
having to navigate locally to determine whether a particular structural 
pattern was present.

As far as I can tell, there's no provision for this sort of local tree 
access in the current Zipper code. Is there any reason such a 
capability could not (or should not) be added to the existing Zipper??


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Which paper discusses Henry Baker's (sp?) egal?

[Jeremy Dunck]

On Nov 21, 11:36 am, Brett Hoerner <[EMAIL PROTECTED]> wrote:
> I've watched a lot of Clojure videos now, and keep hearing Rich
> mention "Henry Baker's egal".  Does someone have the actual paper
> title where Baker talks about this?  I have an ACM subscription (and
> assume that's where I'd find it) - but no dice on finding egal (sp?)
> and Henry G Baker has a hell of a lot of papers. ;)

It's also on ACM here:
http://portal.acm.org/citation.cfm?id=165593.165596&coll=Portal&dl=ACM&CFID=14076373&CFTOKEN=85491572

Citation:
Baker, H. G. 1993. Equal rights for functional objects or, the more
things change, the more they are the same. SIGPLAN OOPS Mess. 4, 4
(Oct. 1993), 2-27. DOI= http://doi.acm.org/10.1145/165593.165596
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Which paper discusses Henry Baker's (sp?) egal?

[Jeremy Dunck]

On Nov 25, 4:16 am, "Alexander Kjeldaas"
<[EMAIL PROTECTED]> wrote:
> Which video does he mention this? I've been on the lookout for references to
> egal in new languages, so this might be a nice clojure surprise!
> Alexander

Around 40 minutes into this video, for one:
http://blip.tv/file/982823

One of many:
http://clojure.blip.tv
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.repl-ln available

[Randall R Schulz]

Steve,

On Friday 05 December 2008 14:45, Stephen C. Gilardi wrote:
> On Dec 3, 2008, at 11:39 AM, Randall R Schulz wrote:
> > Perhaps Steve would consider applying them to making his fancy REPL
> > more
> > robust for terminal users?
>
> I like the idea. If someone would like to work out the basics and
> post some example code, I'll be happy to try to get it running in
> repl-ln.

I'm not acquainted with this, since Dudley's reply was the first I'd 
heard of sun.misc.Signal et. al.

However, with that in hand I found what looks like a pretty good 
tutorial / how-to article:

- Google: Ringlord "POSIX Signal Handling in Java"
  "POSIX Signal Handling in Java"
  


> --Steve


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.repl-ln available

[Randall R Schulz]

On Friday 05 December 2008 14:57, Randall R Schulz wrote:
> Steve,
>
> On Friday 05 December 2008 14:45, Stephen C. Gilardi wrote:
> > On Dec 3, 2008, at 11:39 AM, Randall R Schulz wrote:
> > > Perhaps Steve would consider applying them to making his fancy
> > > REPL more
> > > robust for terminal users?
> >
> > I like the idea. If someone would like to work out the basics and
> > post some example code, I'll be happy to try to get it running in
> > repl-ln.
>
> I'm not acquainted with this, since Dudley's reply was the first I'd
> heard of sun.misc.Signal et. al.

By the way, Sun excludes the sun.* packages from the JavaDoc HTML they 
publish, so you'll have to generate it yourself or avail yourself of 
whatever local tool / IDE / ingenuity you have to see the documentation 
and / or source for these classes.


> However, with that in hand I found what looks like a pretty good
> tutorial / how-to article:
>
> - Google: Ringlord "POSIX Signal Handling in Java"
>   "POSIX Signal Handling in Java"
>   



RRS

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Nested Java Types

[Randall R Schulz]

Hi,

I make pretty extensive use of nested classes
(most significantly Enum types).

I was wondering if it might be a good idea to
allow "dot" resolution to find such types.


E.g.:

user=> tau.run.TSEvent.TSEKind
java.lang.ClassNotFoundException: tau.run.TSEvent.TSEKind (repl-1:7)

user=> tau.run.TSEvent$TSEKind
tau.run.TSEvent$TSEKind


In Java code I can refer to TSEKind as tau.run.TSEvent.TSEKind so it 
seems natural to wonder if it would be reasonable to expect the same 
notation to resolve to the same type in Clojure?


Randall Schulz

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Atoms

[Chouser]

On Fri, Dec 5, 2008 at 11:07 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> I'm working on that.  It has utility even outside traditional reactive
> contexts, in moving the imperative part of your logic outside of your state
> transformation function. I think it's a good model.
>
> Chouser recently went through an interesting exercise doing just that,
> perhaps he'll chime in with his experiences.

Spoiler warning -- this is about a http://projecteuler.net/
problem.  If you don't follow the links, I think you'll be
able to understand what I'm talking about without learning
anything specific enough to ruin any particular puzzle.  If
you want to know which specific puzzle I'm discussing (to
see if you've already done it, for example) you can go to
http://tinyurl.com/6b528n   My solutions are at
http://gist.github.com/32494 but the problem number isn't
mentioned there.

For this puzzle, I had a grid of cells, each of which had a
value that depends on the values of its neighbors in a way
that guaranteed a stable solution.  The value of one cell
was given.

My initial solution [single-threaded.clj] represented the
grid as a vector of vectors of Integers, and maintained a
PersistentQueue of cells that needed to be updated, with a
single loop to work through the queue.  For each iteration
of the loop, a cell would be popped off the queue, and a new
value for that cell computed.  If the new value was
different from the old value, the 'recur' then updated the
cell in the vector and pushed the neighboring cells onto the
work queue.  When the queue was empty, a stable state had
been reached and the answer value could be read.

This ran fairly fast, used no mutable state, and the
implementation seemed relatively clean to me.  I was quite
pleased with myself.

But my friend Aaron Brooks who had already solved the
problem was encouraging me to created a multi-threaded
solution.  Note the solution I had was already thread-safe,
but only used one of my two processor cores.

My second solution [using-agents.clj] represented the grid
as a vector of vectors of agents.  The action function
computed a new value for a given agent, and then used 'send'
to queue up the same action for neighboring agents.  It also
maintained other shared state to keep track of how many cell
agents were running so that it could detect when a stable
state for the whole grid had been reached.

Despite the complexity one might expect from all that, the
agent solution was only 3 lines longer than the
single-threaded solution.  It also ran about 30% faster.

But it had a bug -- often returning the right answer, but
sometimes returning an incorrect number.  It also seemed
more imperative than the first solution, because of the
'send' calls, updating shared counters, etc.  When I
mentioned this on IRC, it was recommended I try watchers.

So I added a watcher to every agent before kicking off the
computation process.  The watcher did no computation as
such, but it was the perfect place to 'send' to neighboring
agents, update the running count, etc.  Moving this code to
the watcher also meant the action function was now pure,
with no side-effects.

It was during the process of separating the stateless and
state-management code that I discovered my bug -- the code
to manage global state had obscured an error in the
computation logic.  With them completely separate, it was
easier to think about the specific responsibilities of each.

It was also now easy to see that the pure computation
function was almost exactly the same whether I was using
agents or just a simple loop.  I finished factoring out this
duplication and ended up with code that could use either
mechanism to solve the same problem.  [with-watchers.clj]

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: My Clojure Emacs Setup (I'll show mine if you show yours)

[Mon Key]

Nice blog entry :)

My setup tends to mirror yours esp. as I've culled most of it from
your blog over the years...
Most of my startup scripts are modified versions of those you've
shared elsewhere.

I don't segment it out quite so much as it makes for transporting
directory trees difficult, and my directory structure is less UML more
ASCII...

I'm launching Clojure as the default lisp now so it's M-x Slime

Running W32 at work and OpenSuse at home I try to mirror everything as
much as possible beneath my user directory which makes transporting
configs fairly straight forward.  (I set EmacsW32 to convert
everything to UNIX style as much as possible - can't imagine working
the other direction).  I run the same color theme (ld-dark) on both
machines which keeps the transition transparent and ld-dark looks GOOD
at the REPL (to my eyes)

We differ on the build script.  It seems a waste of bandwidth to go
quite so scorched earth on the svn builds.
I glommed a modified setup that from a discussion here:

I use
;;; *Nix structure
/home/USERNAME/clojure/clojure-mode < clojure-mode for Emacs
/home/USERNAME/clojure/swank-clojure < swank for Emacs Slime
/home/USERNAME/clojure/clojure-svn/trunk < Trunk created on svn co
/home/USERNAME/clojure/clojure-contrib/trunk < Trunk created on
svn co
/home/USERNAME/clojure/Pragmatic-Programming-book/code < example
code from book
/home/USERNAME/local-emacs/slime < Slime for Emacs

;;; Windows Config
  c:\Documents and Settings\USERNAME\My Documents\clojure
which contains the following files and folders
-
|
--- slime   < emacs slime direictory .el files in here
|
--- clojure < clojure.jar will be in ./trunk/clojure.jar
|
--- clojure-contrib < clojure-contrib.jar is in here
|
--- clojure-mode< clojure-mode emacs .el files in here
|
--- swank-clojure   < swank.jar is in here
|
--- launcher
|
--- launch-clojure.bat < script to start clojure (swank-
clojure-binary)
|
---Pragmatic-closure< Code from Pragmatic Book - Programming
Closure
   |
   ---Pragmatict Programming Code

;;; I use thes for cleaning up and documenting my notes while i learn
clojure:
(defun comment-divider ()
(interactive)
(insert
";;; =="))

(global-set-key "\C-c\C-di" 'comment-divider)

;;; ==
(defun user-evald ()
"useful for inserting the users evaluated list  at ^ for notes  and
repasting into a new REPL e.g.
user> (+ 1 2)
;;; => 3 "
(interactive)
(insert
";;; => "))

(global-set-key "\C-c\M-;" 'user-evald)


On Dec 5, 5:07 pm, bc <[EMAIL PROTECTED]> wrote:
> My setup is here:http://bc.tech.coop/blog/081205.html
>
> What does your Clojure Emacs setup look like?
>
> --
> Bill Clementson
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Chouser]

Third time's charm?  The previous versions of 'reduction' returned nil
for empty collection when no init was given.  This version follows
'reduce' more closely, calling the given function with no arguments:

user=> (reduction + [])
(0)

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

commit 9ca38b1bc2f27d29192f4ecf2312bb45a53557d1
Author: Chouser <[EMAIL PROTECTED]>
Date:   Fri Dec 5 21:41:44 2008 -0500

reduction, v3

diff --git a/src/clj/clojure/core.clj b/src/clj/clojure/core.clj
index 4aad594..aa6048e 100644
--- a/src/clj/clojure/core.clj
+++ b/src/clj/clojure/core.clj
@@ -2738,6 +2738,20 @@
   coll (range (count coll)))
   (map #(if-let [e (find smap %)] (val e) %) coll)))
 
+(defn reduction
+  "Returns a lazy seq of the intermediate values of the reduction (as
+  per reduce) of coll by f, starting with init."
+  ([f [x & xs :as coll]]
+   (if (seq coll)
+ (if-let [[x2 & xs2] xs]
+   (reduction f (f x x2) xs2)
+   (cons x nil))
+ (cons (f) nil)))
+  ([f init [x & xs :as coll]]
+   (if (seq coll)
+ (lazy-cons init (reduction f (f init x) xs))
+ (cons init nil
+
 (defmacro dosync 
   "Runs the exprs (in an implicit do) in a transaction that encompasses
   exprs and any nested calls.  Starts a transaction if none is already

Re: Running out of memory when using filter?

[Stuart Sierra]

On Dec 5, 4:59 pm, Paul  Mooser <[EMAIL PROTECTED]> wrote:
> The memory profiler says that the following object is a GC root which
> is holding onto the collection being passed into the filter call:
>
> clojure.core$filter__3364$fn__3367

That class should be the instance of the anonymous fn you defined in
your filter.

Here's an experiment -- make the filter a normal function, i.e.:

(def *m*   ... fill in your map here ...)

(defn my-filter [document]
 (let [item (. document get Constants/ITEM_ID)]
   (contains? *m* item)))

(defn documents-from-vendors [doc-seq]
(filter my-filter doc-seq))

Does it still blow up?

-Stuart Sierra
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: function args question

[hitesh]

Meikel & Jeff,

Thank you.  That really helped me get over the current hump.  But as I
encounter more, I'm realizing I need to learn a lot more about the
Java interop.

Thanks,
- Hitesh


--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Chouser]

On Fri, Dec 5, 2008 at 9:55 PM, Chouser <[EMAIL PROTECTED]> wrote:
> Third time's charm?

Apparently not.  Previous versions had a couple problems.

One was that when when no init was provided, the first element of the
collection was not emitted by itself.  This is inconsistent with
Haskell's scanl1 and I think also inconsistent with itself.

Another issue is that they looked ahead in the collection one step
further than required to produce each value.  This type of issue has
caused me problems in the past when working with lazy sequences whose
cost rose sharply with each successive 'rest'.

But I found it tricky to fully solving this last problem.  Here is
a definition that almost completely solves the problem:

(defn reduction
  "Returns a lazy seq of the intermediate values of the reduction (as
  per reduce) of coll by f, starting with init."
  ([f coll]
   (if (seq coll)
 (reduction f (first coll) (rest coll))
 (cons (f) nil)))
  ([f init coll]
   (let [step (fn step [prev coll]
(when (seq coll)
  (let [x (f prev (first coll))]
(lazy-cons x (step x (rest coll))]
 (lazy-cons init (step init coll)

That one still consumes one extra value for the first value it
produces when called with no init.  The second value is then produced
without it calling 'rest' again, and so the producer is caught up with
the consumer for the rest of the seq.

There are a few ways to solve this small early eagerness, and below is
my best attempt.  Whether it's worth the extra (private) function for
this narrow case is a question I leave to others.  Both definitions of
'reduction' produce the same results in all cases, the only difference
is in how early the first 'rest' is called on the collection.

(defn- reduction-step [f prev coll]
  (when (seq coll)
(let [x (f prev (first coll))]
  (lazy-cons x (reduction-step f x (rest coll))

(defn reduction
  "Returns a lazy seq of the intermediate values of the reduction (as
  per reduce) of coll by f, starting with init."
  ([f coll]
   (if (seq coll)
 (lazy-cons (first coll) (reduction-step f (first coll) (rest coll)))
 (cons (f) nil)))
  ([f init coll]
 (lazy-cons init (reduction-step f init coll

Either solution can be made available in patch form upon request.

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: reduction

[Chouser]

How about this one?  Same results as in my previous post. Still as
lazy as possible.  Plus it's so cute!

(defn reduction
  "Returns a lazy seq of the intermediate values of the reduction (as
  per reduce) of coll by f, starting with init."
  ([f coll]
   (if (seq coll)
 (lazy-cons (first coll) (map f (reduction f coll) (rest coll)))
 (cons (f) nil)))
  ([f init coll]
   (lazy-cons init (map f (reduction f init coll) coll

--Chouser

--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Zipper & Local Context?

[Nathan Kitchen]

Could you achieve this through a combination of clojure.zip/node and
get-in/assoc-in/update-in? Of course the missing piece is going back
from nodes to locs.

-- Nathan

On Dec 5, 2:54 pm, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I looked at the Clojure implementation of Huet's Zipper and it looks
> great. I like how it delegates construction and dissection of the tree
> structure to client-supplied functions so that it is generic w.r.t. to
> any types (especially for me, pre-existing, non-Clojure Java types)
> that can be deemed to encode a tree structure.
>
> However, I would like to be able to examine the tree in the locality of
> the current traversal point through path or position specifications.
> This approach is commonly used in describing algorithms about logical
> formulas (which are inherently tree-structured). If you're not familiar
> with the notion, these paths / positions are directly analogous to file
> system path names, except that one uses integers to label the arcs,
> said integers being ordinals in the child sequence of a given node.
>
> It seems to me that being able to access local context using such paths
> during a tree traversal would be far more convenient in many cases to
> having to navigate locally to determine whether a particular structural
> pattern was present.
>
> As far as I can tell, there's no provision for this sort of local tree
> access in the current Zipper code. Is there any reason such a
> capability could not (or should not) be added to the existing Zipper??
>
> Randall Schulz
--~--~-~--~~~---~--~~
You 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---