probable bug in transients ..

2011-01-06 Thread Sunil S Nandihalli
Hello everybody,
 the following code is not producing what was expected of it in clojure 1.2
.. has this been fixed the clojure 1.3?
(let [x (transient {})]


(dotimes [i 10]


 (assoc! x i (* i i)))


(persistent! x))



{0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49}

I was expecting
{0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49, 8 64, 9 81}

thans,
Sunil.

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

Re: probable bug in transients ..

2011-01-06 Thread Baishampayan Ghose
> Hello everybody,
>  the following code is not producing what was expected of it in clojure 1.2
> .. has this been fixed the clojure 1.3?
> (let [x (transient {})]
>
>
>                         (dotimes [i 10]
>
>
>                                  (assoc! x i (* i i)))
>
>
>                         (persistent! x))
>
>
>
> {0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49}
> I was expecting
> {0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49, 8 64, 9 81}

I can reproduce it. In fact, it doesn't work for any number greater than 8.

Can't believe this, I hope we are doing something wrong.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.com

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


Re: probable bug in transients ..

2011-01-06 Thread Sunil S Nandihalli
Yea you are right it does not work for anything greater than 8 .. It took me
a while to figure out that the bug was infact the transients.. but did you
try it in clojure 1.3 alpha versions?
Sunil.

On Thu, Jan 6, 2011 at 3:35 PM, Baishampayan Ghose wrote:

> > Hello everybody,
> >  the following code is not producing what was expected of it in clojure
> 1.2
> > .. has this been fixed the clojure 1.3?
> > (let [x (transient {})]
> >
> >
> > (dotimes [i 10]
> >
> >
> >  (assoc! x i (* i i)))
> >
> >
> > (persistent! x))
> >
> >
> >
> > {0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49}
> > I was expecting
> > {0 0, 1 1, 2 4, 3 9, 4 16, 5 25, 6 36, 7 49, 8 64, 9 81}
>
> I can reproduce it. In fact, it doesn't work for any number greater than 8.
>
> Can't believe this, I hope we are doing something wrong.
>
> Regards,
> BG
>
> --
> Baishampayan Ghose
> b.ghose at gmail.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread LauJensen
Hi Sean,

Yes the two statements are equivalent. ClojureQL compiles everything
to prepared
statements, with every argument automatically paramterized. You
shouldn't have to
call the compiler function directly, ever. For quick inspection,
simply type the statement
in the repl and it will emit the SQL statement, because I've
overridden the print-method

user> (table :users)
SELECT * FROM users
user> (class *1)
clojureql.core/RTable

Its not a string, as you can see. For junior developers, the generated
SQL statements will
sometimes outperform what they would have written by hand. For SQL
masters, it should
hopefully generate what they would have written by hand.

Lau

On Jan 6, 4:23 am, Sean Corfield  wrote:
> On Wed, Jan 5, 2011 at 6:14 AM, LauJensen  wrote:
> > Just a quick heads up that ClojureQL 1.0.0 is now released. All
> > interfaces should be final and there are no known bugs.
>
> Looks really interesting. We're about to start moving some of our web
> app back end over to Clojure and this might be a good fit but I'd be a
> little concerned about performance and the docs don't give me enough
> data to figure that aspect out...
>
> Normally I'd expect systems like this to compile to a SQL prepared
> statement so arguments can be provided without needing to recompile
> the AST to SQL and recompile the SQL but I don't see anything like
> that in the docs (I see a mention of a (compile) function on the
> examples page but it isn't mentioned in the documentation).
>
> For example, with c.c.sql, I'd write something like:
>
>     (sql/with-query-results rows
>       ["SELECT dateofbirth, gender, zipcode
>         FROM user
>         WHERE id = ?" user-id]
>       ( ... process rows ... ))
>
> With ClojureQL, the obvious query would be (I think):
>
> (-> (table :user)
>     (select (where (= :id user-id)))
>     (project [:dateofbirth :gender :zipcode]))
>
> But is that really the same?
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. --http://getrailo.com/
> An Architect's View --http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood

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


Re: probable bug in transients ..

2011-01-06 Thread Joost
That is not a bug. You should NEVER use transient and its related
functions to emulate variables - you're supposed to use assoc! and
friends as if they're pure functions. That is, always use the return
value of assoc! and don't rely on its argument being modified.

something like:

(loop [x (transient {})
   i 0]
(if (< i 10)
  (recur (assoc! x i (* i i)) (inc i))
  (persistent! x)))

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


Re: probable bug in transients ..

2011-01-06 Thread Alex Osborne
Sunil S Nandihalli  writes:

> Hello everybody,
> the following code is not producing what was expected of it in clojure
> 1.2 .. has this been fixed the clojure 1.3?
>
> (let [x (transient {})]
>   (dotimes [i 10]
> (assoc! x i (* i i)))
>   (persistent! x))

This is not a bug, it's a misuse of transients.  A transient map is not
an imperative mutable map.  They're just a performance optimisation for
certain use cases of an immutable map.

To quote the clojure.org/transients documentation:

> Note in particular that transients are not designed to be bashed
> in-place. You must capture and use the return value in the next
> call. In this way, they support the same code structure as the
> functional persistent code they replace. 

There's a simple rule for using transients correctly.  First write the
code with a normal immutable data structure:

(let [x {}]
  (reduce (fn [m i] (assoc m i (* i i))) x (range 10)))

Then stick "!" on the end of assoc/conj/disj and wrap in the
transient/persistent! calls.  Don't make any other changes to the
code structure.

(let [x (transient {})]
  (persistent! (reduce (fn [m i] (assoc! m i (* i i))) x (range 10

Hope that helps,

Alex

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


Re: probable bug in transients ..

2011-01-06 Thread Joost
Joost wrote:
> you're supposed to use assoc! and
> friends as if they're pure functions.

Just correcting myself for clarity:

assoc! etc MAY modify their transient arguments, but not always, and
not always in the way you might think. The correct result of these
operations is their return value, but they are not pure functions
since you also - obviously - cannot rely on the transient arguments to
remain unchanged.

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


Re: probable bug in transients ..

2011-01-06 Thread Sunil S Nandihalli
thanks for the clarification .. I did know about the fact that I have to
capture the return value .. but some how slipped my mind and assumed it was
a bug .. I guess that will never happen again after burning my fingers this
time 

Sunil.

On Thu, Jan 6, 2011 at 4:30 PM, Joost  wrote:

> Joost wrote:
> > you're supposed to use assoc! and
> > friends as if they're pure functions.
>
> Just correcting myself for clarity:
>
> assoc! etc MAY modify their transient arguments, but not always, and
> not always in the way you might think. The correct result of these
> operations is their return value, but they are not pure functions
> since you also - obviously - cannot rely on the transient arguments to
> remain unchanged.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: probable bug in transients ..

2011-01-06 Thread Baishampayan Ghose
> thanks for the clarification .. I did know about the fact that I have to
> capture the return value .. but some how slipped my mind and assumed it was
> a bug .. I guess that will never happen again after burning my fingers this
> time 

Haha! Same here. I have used transients many times too, but I fell
into the trap this time :)

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.com

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


Re: feedback on first compojure app: Sportello

2011-01-06 Thread James Reeves
I note that the stringtemplate-clj library defaults to using directory
paths only, but StringTemplate itself can pull templates from the
classpath as well. If you placed your templates in
"resources/templates" and used StringTemplate directly, you wouldn't
have to worry about where the template directory was.

Regarding your routes, they could be made a little more concise:

(defroutes all-routes
  (GET "/" []
(pages/home))
  (POST "/" [origin addresses]
(pages/list-distances origin addresses))
  (route/not-found
(pages/not-found-404)))

And I'd avoid placing a run-jetty command in the same file your routes
are. Instead, run Jetty in the REPL, or use the "lein-ring" plugin:

https://github.com/weavejester/lein-ring

- James

On 2 January 2011 19:30, Alex Baranosky  wrote:
> Hello everyone,
> Sean Allen inspired me to share the web app I've been playing with to learn
> Compojure.  It's codenamed Sportello and is a simple app that uses the
> Google Maps API to calculate an estimated amount of miles you'll have to
> travel from a certain place depending on where you live and how frequently
> you visit a list of other places.
> https://github.com/AlexBaranosky/Sportello/tree/master/src
> I used StringTemplate for my templating, and Midje for testing.  One thing I
> could see doing is using some form of caching on my requests to google, so
> that the same request isn't sent to google over and over (they have a
> request limit).  When I get inspired to, I want to add users and sessions,
> and save a user's data.  Any direction here would be appreciated.
> To get it to run on your machine, in template.clj change the (def
> template-dir "C:\\dev\\sportellos\\templates") line to match the location of
> the templates folder in your clone of the project.  Then just lein repl
> src/server.clj and go to localhost:8080
> Any comments on style, technique or just anythings I missed would be greatly
> appreciated.  I'm really trying to expand my horizons and perfect the app as
> a kind of kata.
> Best,
> Alex
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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


Re: Clojure Quizzes?

2011-01-06 Thread benjamin.s.r
http://coderloop.com/ like Project Euler but more modern

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


Re: ANN: Gloss, a byte-format DSL

2011-01-06 Thread Geoff
Hey Eric
I did something similar for handling unsigned types. I think it's
simpler and probably faster, not that I've checked. Here's a gist of
it https://gist.github.com/767887

That code is part of a little library I wrote a while ago
https://github.com/geoffsalmon/bytebuffer  It's closer to your bin-ed
in complexity than to gloss. You might also find the pack-bits and
unpack-bits functions useful if you're parsing bit-fields and not
using Gloss's bits-seq.

I'm going to give Gloss a try. For complex binary structures, I think
I like it's way of specifying formats using (keyword, type) pairs and
reading and writing maps instead of bytebuffer's which specifies
formats as strings ('b' for byte, 'i' for int, and so on) and reads
and writes seqs of values.

- Geoff


On Jan 5, 5:45 pm, "Eric Schulte"  wrote:
> also, here's a patch to Gloss which I've used locally but which may be
> generally useful.
>
> Cheers -- Eric
>
>  0001-adding-primitive-support-for-uint16-uint32-and-uint6.patch
> 1KViewDownload
>
>
>
> "Eric Schulte"  writes:
> > Thanks for sharing this library, I found reading your code to be very
> > useful.
>
> > I need to be able to read and write elf files from within Clojure code,
> > and Gloss initially looked like a good option.  However much of the
> > streaming support and frame-based conception got in the way of my
> > particular needs.
>
> > In the end I have written a much simpler collection of functions which
> > supports parsing binary files into lists of bytes, manipulating these
> > lists, and then writing the lists back to binary files.  This is heavily
> > influenced by the code in Gloss.  Seehttps://github.com/eschulte/bin-ed
>
> > Anyways just thought I'd share, if anyone notices anything in the code
> > which doesn't make sense, or could be more easily accomplished in some
> > other way please do let me know.
>
> > Thanks -- Eric

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread faenvie


On Jan 5, 3:14 pm, LauJensen  wrote:

> ... Works out of the box with PostgreSQL and MySQL ...

nice work !

your testcode references sqlite3 too.
so what about sqlite3-support ?

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread LauJensen
Thanks!

sqlite has certain oddities. For instance when you do a union the
first query must not be in parens. In order to support this various
quirks, somebody would have to copy/paste the sql92compiler and
adjust it slightly for sqlite. I haven't done it yet, but if somebody
does I'd be happy to include that dialect in CQL. Right now, I think
95% of the functions will actually run fine on Sqlite.

On Jan 6, 4:09 pm, faenvie  wrote:
> On Jan 5, 3:14 pm, LauJensen  wrote:
>
> > ... Works out of the box with PostgreSQL and MySQL ...
>
> nice work !
>
> your testcode references sqlite3 too.
> so what about sqlite3-support ?

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


Re: probable bug in transients ..

2011-01-06 Thread Andrew Boekhoff
http://clojure.org/transients
mentions that transients are not designed to be bashed in place like mutable 
datastructures. 

The following produces the correct result.

(loop [x (transient {}) i 0]
  (if (< i 10)
   (recur (assoc! x i (* i i)) (inc i))
   (persistent! x)))

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


Re: vsClojure Release

2011-01-06 Thread eyeris
Thank you for working on this! I wanted to create an extension with
just syntax highlighting and AOT compilation but I gave up while
reading through the VS extension API. Your patience must be never-
ending to use that API :) I will download and test this later today.



On Dec 30 2010, 10:30 pm, jmis  wrote:
> The first release ofvsClojureis now available in the Visual Studio
> Gallery.  You can download it using the extension manager in Visual
> Studio 2010 and searching for "vsClojure".  There should be no manual
> setup and the extension will work with the Visual Studio 2010 Shell.
>
> This release focused on implementing basic features, laying the
> plumbing for more advanced features and creating a packaging
> strategy.  For a complete list of features please 
> visithttp://github.com/jmis/vsClojure.
>
> Future releases depend on your feedback.  Feel free to open issues in
> the issue tracker or post suggestions in the discussion group 
> athttp://groups.google.com/group/vsclojure-extension.
>
> Thanks,
> jmis

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


Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Eric Schulte
Tim Daly  writes:

> On 1/6/2011 12:03 AM, Eric Schulte wrote:
>>> Can you post examples of these? I'd love to see some other examples.
>> Sure thing, check out this old version of a file which tangles out into
>> the directory layout expected by lein.
>> http://gitweb.adaptive.cs.unm.edu/?p=asm.git;a=blob;f=asm.org;h=f043a8c8b0a917f58b62bdeac4c0dca441b8e2cb;hb=HEAD
> I see that this file is using chunk markup but I don't see
> the "ideas-to-implementation" (I2I) explanation. That is, I
> don't see text that is written so someone like me can read the
> text, understand the ideas and how they translate to code.
>

True, unfortunately I don't have any good examples where I write in an
I2I style.  I think the discipline needed to sit down and document ones
initial ideas may be one of the largest hurdles to a wider adoption of
LP practices.

However there are more examples of org-mode usage available online at
http://orgmode.org/worg/org-contrib/babel/uses.html

>
>> Also, this project has an org-mode front page with code examples, the
>> html woven from this front page is shown at
>> http://repo.or.cz/w/neural-net.git
>> and the raw org file is available here
>> http://repo.or.cz/w/neural-net.git/blob/HEAD:/neural-net.org
> I love the graphics in this example! But, alas, this also seems
> to be disconnected from the I2I property. But this is VERY
> encouraging since it shows that you can get beautifully formatted
> documents from the source.

Thanks, you may also notice that the graphics are actually produced from
inline LaTeX (using tikz) avoiding the need for external binary files
and allowing everything to be handled nicely by git.

>
>> I'll have to check  out clojure.pamphlet, it sounds like an elegant
>> alternative.  It's always interesting to see other solutions in this
>> space.  For example I think scribble is a nice tool from the scheme
>> world.  http://lambda-the-ultimate.org/node/4017
> Take a look at http://daly.axiom-developer.org/clojure.pdf
>

Very nice, I think this has become my new reference for code in the
Clojure core.  Is the .clj or .tex file available as well?

>
> The key difference, at least from my perspective, is that the CISP
> is (well, is slowly being) organized around ideas. The goal is to
> introduce the ideas and explain them in enough detail to *motivate*
> the code that follows the explanation.
>
> If you handed your printed document (or pdf) to someone will they
> come away with enough understanding of neural networks to be able
> to explain your code? Can they read the pdf and know what to change
> and where to change it? Do they have literature references to follow
> for deeper information? Is there a usable index with proper cross
> references so they can hyperlink to the explanation and its associated
> code block? These things seem, in my opinion, necessary (but not
> sufficient) for the I2I property to hold.
>
> I think that the tool you have is very, very nice. It shows me that
> it would make a proper substitute for my beloved Latex as a viable
> alternative for literate programming.
>

Thanks, and I agree the tool should support LP/I2I style composition,
the main hurdle is getting users (including myself) to write code in
that style (regardless of the tool used).

Best Regards -- Eric

>
> Tim Daly

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


Re: ANN: Gloss, a byte-format DSL

2011-01-06 Thread Eric Schulte
Hey Geoff,

This sort of feedback and code recommendations is exactly what I was
hoping for.

Geoff  writes:

> Hey Eric
> I did something similar for handling unsigned types. I think it's
> simpler and probably faster, not that I've checked. Here's a gist of
> it https://gist.github.com/767887
>

Ah, these do look like an improvement, thanks for sharing.

>
> That code is part of a little library I wrote a while ago
> https://github.com/geoffsalmon/bytebuffer  It's closer to your bin-ed
> in complexity than to gloss. You might also find the pack-bits and
> unpack-bits functions useful if you're parsing bit-fields and not
> using Gloss's bits-seq.
>

Very nice, I'm actually using vectors to fake ordered maps to mimic
Gloss' (keyword value) codecs, e.g. https://gist.github.com/768101

Cheers -- Eric

>
> I'm going to give Gloss a try. For complex binary structures, I think
> I like it's way of specifying formats using (keyword, type) pairs and
> reading and writing maps instead of bytebuffer's which specifies
> formats as strings ('b' for byte, 'i' for int, and so on) and reads
> and writes seqs of values.
>
> - Geoff
>
>
> On Jan 5, 5:45 pm, "Eric Schulte"  wrote:
>> also, here's a patch to Gloss which I've used locally but which may be
>> generally useful.
>>
>> Cheers -- Eric
>>
>>  0001-adding-primitive-support-for-uint16-uint32-and-uint6.patch
>> 1KViewDownload
>>
>>
>>
>> "Eric Schulte"  writes:
>> > Thanks for sharing this library, I found reading your code to be very
>> > useful.
>>
>> > I need to be able to read and write elf files from within Clojure code,
>> > and Gloss initially looked like a good option.  However much of the
>> > streaming support and frame-based conception got in the way of my
>> > particular needs.
>>
>> > In the end I have written a much simpler collection of functions which
>> > supports parsing binary files into lists of bytes, manipulating these
>> > lists, and then writing the lists back to binary files.  This is heavily
>> > influenced by the code in Gloss.  Seehttps://github.com/eschulte/bin-ed
>>
>> > Anyways just thought I'd share, if anyone notices anything in the code
>> > which doesn't make sense, or could be more easily accomplished in some
>> > other way please do let me know.
>>
>> > Thanks -- Eric

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


Re: problem with stream

2011-01-06 Thread Aaron Cohen
On Wed, Jan 5, 2011 at 5:13 PM, Ken Wesson  wrote:
> On Wed, Jan 5, 2011 at 4:40 PM, rainerh  wrote:
>> Hello everybody,
>>
>> I'm trying to use clojure to parse web sites. Unfortunately there is
>> some problem with following code (used library is Apache Commons HTTP
>> Client):
>>
>> (defn request [url]
>>  (let [client (new org.apache.http.impl.client.DefaultHttpClient)]
>>    (with-open [rdr (reader
>>                     (.getContent
>>                      (.getEntity
>>                       (.execute client (new
>> org.apache.http.client.methods.HttpGet url)
>>                ]
>

As an aside, the following is an alternate way of writing that intializer:

(-> client
 (.execute (org.apache.http.client.methods.HttpGet. url))
.getEntity .getContent reader)

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


Re: #clojure in 2010

2011-01-06 Thread Miki
If someone is interested in some other statistics, please let me know and 
I'll try to make it happen.
>
>
>>
> The most talkative person per session would be interesting :) though 
> perhaps session time is a PITA to establish particularly across days 
> boundaries.
>
Define "session" (a day? a subject? ...)
 

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

Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Michael Wood
Hi

On 6 January 2011 07:33, Tim Daly  wrote:
[...]
> Take a look at http://daly.axiom-developer.org/clojure.pdf

I like it :)

Some simple corrections:

You have a typo on the front page:

"Based on Version 1.3.0-alphs4" (alphs4 instead of alpha4).

In the foreword, "This is a literate fork of Clojure, invented by Rich
Hickey." sounds a little like Rich Hickey invented this fork of
Clojure rather than Clojure itself.

I have no idea what that "((iHy))" means after the date at the end of
the foreword.

Page 2:

Last sentence of 1.3.2 says "We will look now look...".

In 1.3.3 the methods for updating the right member are identical to
the ones for the left member.  I suspect "left" should be replace with
"right" in all three lines?

Page 5:

Fourth paragraph of 1.3.5 contains a sentence with a missing "a":
"Since it is copy operation...".

Also in 1.3.5, the list of Black node types duplicates the information
in 1.3.3.  (Same with the list of Red nodes in 1.3.11.)

In the introductions to the Black, BlackVal, BlackBranch and
BlackBranchVal descriptions you say "This is constructed by
PersistenTreeMap's black method."  Are all of them constructed with
the black method?  If so, perhaps you should say that somewhere
instead of saying it separately for each one?  Perhaps 1.3.10 is
enough.  Just when I was reading through the introductions to Black,
BlackVal etc., I kept wondering if the next one was going to say it
was constructed by some method other than black, since you were
explicitly mentioning it every time.

Page 9:

There seems to be a spurious "new" in the first sentence: "If either
of the children exist but new have no value for this node..."

The second sentence of 1.3.11 is confusing to me.  It seems to me that
the colour of the node returned has nothing to do with whether or not
subtrees are balanced, so it doesn't make sense to me to contrast
these two things.  (Of course I know nothing about Red Black trees
other than what I've read so far in this document.)

The next paragraph is a little confusing to me too.  Why would Red
nodes have to be returned only because the default colour is Black?
Surely even if the default colour were Red, Red nodes would need to be
returned?  Perhaps I'm missing something fundamental about how Red
Black trees work.

Page 13:

1.3.16 seems to be more or less a copy of 1.3.10 with Black replaced
with Red, so it also has the extraneous "new".

Page 14:

The second sentence of 1.3.17 says "... all four cases all
balance...".  It would be better without the second "all".

The next paragraph says "Each cases shows the ML code...".  This
should of course be "Each case...".  Also, what is "ML code"?

Page 16:

There's a missing "'s" in the second sentence: "... a black node (p5)
removeRight method..."

Anyway, that's as far as I've got so far.

-- 
Michael Wood 

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


Re: clojure.java.shell hanging issues

2011-01-06 Thread Miki


> Looking at the source code I'm not sure if the patches were applied.
> Maybe there was a "regression". The symptoms seem consistent with what
> was supposed to have been fixed.
>
> Following the clojure.org api docs, I clicked through on the source code 
> link on
>
> http://richhickey.github.com/clojure-contrib/shell-api.html
>
Can we add a notice on the 
http://richhickey.github.com/clojure...that
 the "official" docs are at 
http://clojure.github.com/clojure..
?
I've seen several people getting confused by that.

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

Re: probable bug in transients ..

2011-01-06 Thread Raoul Duke
On Thu, Jan 6, 2011 at 3:32 AM, Baishampayan Ghose  wrote:
> Haha! Same here. I have used transients many times too, but I fell
> into the trap this time :)

now if only there were some kind of programming language technology
that could help us figure out when we're mis-applying operations to
things... ;-)

(yeah, i am kidding around about type checking, but if not that, then
something like dialyzer some day would be pretty dope for 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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Boston Clojure Meetup Thursday Jan 13

2011-01-06 Thread Straszheim, Jeff

1st Boston Clojure Meetup


Date:  Thursday, January 13th, 2011

Location:  Akamai Technologies
8 Cambridge Center
Conference Room 200D
Cambridge, MA 02142
(Corner of Broadway and Galileo Galilei)



Akamai Technologies will be hosting the first Boston Clojure
Meetup on Thursday, January 13th.  This will be an opportunity
for local Clojure enthusiasts to gather and discuss topics of
interest to the Clojure community. For this first meeting,
Jeffrey Straszheim will be presenting his Dataflow library from
Clojure Contrib.

 

Please forward this meeting invitation to anyone you know who
might be interested.

 

Agenda:

6:307:00   Informal Meet & Greet

7:007:15   Introduction - Eric Kobrin

7:157:30   Future Meetup Topics and Locations

7:408:00   Dataflow in Clojure - Jeffrey Straszheim

8:00-  Drinks at CBC on your own




If you have any questions, please contact:

Eric Kobrin 
617-444-3951(office)
786-261-7093(cell)
 

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


Re: #clojure in 2010

2011-01-06 Thread Michael Ossareh
On Thu, Jan 6, 2011 at 08:50, Miki  wrote:

> If someone is interested in some other statistics, please let me know and
> I'll try to make it happen.
>>
>>
>>>
>> The most talkative person per session would be interesting :) though
>> perhaps session time is a PITA to establish particularly across days
>> boundaries.
>>
> Define "session" (a day? a subject? ...)
>

login to logout. So the stat would be number of messages / hours logged in.



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

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

Re: probable bug in transients ..

2011-01-06 Thread Ken Wesson
On Thu, Jan 6, 2011 at 1:08 PM, Raoul Duke  wrote:
> On Thu, Jan 6, 2011 at 3:32 AM, Baishampayan Ghose  wrote:
>> Haha! Same here. I have used transients many times too, but I fell
>> into the trap this time :)
>
> now if only there were some kind of programming language technology
> that could help us figure out when we're mis-applying operations to
> things... ;-)

A compiler warning if the return value from assoc!, disj!, or conj! is
discarded could help in this particular case.

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


Re: Boston meetup Jan 11?

2011-01-06 Thread rob levy
I'm also going to Boston Coding Dojo tonight.  The Clojure Meetup is going
to be at Akamai, a week from tonight's dojo, which I'm looking forward to:
http://groups.google.com/group/clojure/browse_thread/thread/821248c3dd0b69b8

On Thu, Dec 30, 2010 at 9:34 PM, Alyssa Kwan wrote:

> Hi!
>
> You would be more than welcome at the Boston Coding Dojo (http://
> www.meetup.com/boston-coding-dojo/).  We meet every other Thursday at
> First Church in Boston, in Boston's Back Bay on Marlborough St.  In
> January, we are meeting on 1/6 and 1/20, so nothing on the week of
> 1/9, I'm afraid.  What kind of meeting do you have in mind?  I could
> certainly recommend some restaurants that are more conducive to
> conversation.  If you are looking for a space to hack, I can certainly
> check with the church for availability; we meet in a lovely chapel
> with plenty of room.  It would cost $75 for the space for the night.
> There's also the Workbar (http://www.workbarboston.com), which is
> pricier and a little more cramped... :).
>
> Everyone on the list should also check out Boston Software
> Craftsmanship (http://groups.google.com/group/boston-software-
> craftsmanship/).  Their next meeting is on 1/24 and is on monads
> (http://gathers.us/events/jan-boston-software-craftsmanship-meeting).
>
> Thanks!
> Alyssa
>
> On Dec 30, 1:52 pm, dysinger  wrote:
> > 10 of us from Sonian are going to converge on Boston the week of Jan
> > 9.  It's always awesome to meet other Clojure hackers. I propose we
> > meet up somewhere central(ish) Jan 11 @ 7-9pm-ish.  We have room at
> > our company headquarters in Dedham but that might be a hike for some
> > people.  Any other places we could meet/greet & hack for an hour or
> > two central to Boston?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Tim Daly



On 1/6/2011 11:16 AM, Eric Schulte wrote:

Tim Daly  writes:


On 1/6/2011 12:03 AM, Eric Schulte wrote:

Can you post examples of these? I'd love to see some other examples.

Sure thing, check out this old version of a file which tangles out into
the directory layout expected by lein.
http://gitweb.adaptive.cs.unm.edu/?p=asm.git;a=blob;f=asm.org;h=f043a8c8b0a917f58b62bdeac4c0dca441b8e2cb;hb=HEAD

I see that this file is using chunk markup but I don't see
the "ideas-to-implementation" (I2I) explanation. That is, I
don't see text that is written so someone like me can read the
text, understand the ideas and how they translate to code.


True, unfortunately I don't have any good examples where I write in an
I2I style.  I think the discipline needed to sit down and document ones
initial ideas may be one of the largest hurdles to a wider adoption of
LP practices.

However there are more examples of org-mode usage available online at
http://orgmode.org/worg/org-contrib/babel/uses.html


Also, this project has an org-mode front page with code examples, the
html woven from this front page is shown at
http://repo.or.cz/w/neural-net.git
and the raw org file is available here
http://repo.or.cz/w/neural-net.git/blob/HEAD:/neural-net.org

I love the graphics in this example! But, alas, this also seems
to be disconnected from the I2I property. But this is VERY
encouraging since it shows that you can get beautifully formatted
documents from the source.

Thanks, you may also notice that the graphics are actually produced from
inline LaTeX (using tikz) avoiding the need for external binary files
and allowing everything to be handled nicely by git.


I'll have to check  out clojure.pamphlet, it sounds like an elegant
alternative.  It's always interesting to see other solutions in this
space.  For example I think scribble is a nice tool from the scheme
world.  http://lambda-the-ultimate.org/node/4017

Take a look at http://daly.axiom-developer.org/clojure.pdf


Very nice, I think this has become my new reference for code in the
Clojure core.  Is the .clj or .tex file available as well?

The source documents are
http://daly.axiom-developer.org/clojure.pamphlet
http://daly.axiom-developer.org/clojure.sty

The instructions for running tangle are in the preface.
The tangle.c function is in the document but it is standalone here:

http://daly.axiom-developer.org/tangle.c

A pamphlet file IS a tex file. I just chose the name to distinguish
it as a literate document from other tex files I have.

You might find it interesting to change the pamphlet to use org-mode
(or change org-mode to read pamphlets :-) )

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


What am I not getting here?

2011-01-06 Thread new2clojure

Hi,

I am trying to store into a map the frequency of each [a-z]+ word in a
file. When I run this code in the repl the resulting dictionary is
empty. How should I adapt my code to get this functionality right?.

Thank you in advance

(import (java.io BufferedReader FileReader))

(def dictionary {})

(defn process-file [file-name]
  (with-open
[rdr (BufferedReader. (FileReader. file-name))]
(doseq
  [line (line-seq rdr)]
  (reduce #(assoc %1 %2 (inc (get %1 %2 1))) dictionary (re-seq
#"[a-z]+" (.toLowerCase line))

(process-file "src/SpellChecker.clj")

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


The human brain works the Lisp way!

2011-01-06 Thread Arie van Wingerden
Hi,

on this page
http://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to-build-one-video/
you
can find a video in which Ray Kurzweil speaks about the "reverse
engineering" of the human brain.

At 39:25 Ray states that "... the cerebral cortex is a Lisp processor." and
explains that later.

Maybe it is off topic, but I think it may be very interesting to a lot of
you.

Kind regards,
   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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: problem with stream

2011-01-06 Thread Hubert Iwaniuk
Shameless plug: or use http.async.client
http://neotyk.github.com/http.async.client/docs.html#sec-1_2_4_1
(let [resp (c/stream-seq :get url)]
  (doseq [s (string resp)]
(println s)))

Cheers,
Hubert.



On Thu, Jan 6, 2011 at 5:34 PM, Aaron Cohen  wrote:
> On Wed, Jan 5, 2011 at 5:13 PM, Ken Wesson  wrote:
>> On Wed, Jan 5, 2011 at 4:40 PM, rainerh  wrote:
>>> Hello everybody,
>>>
>>> I'm trying to use clojure to parse web sites. Unfortunately there is
>>> some problem with following code (used library is Apache Commons HTTP
>>> Client):
>>>
>>> (defn request [url]
>>>  (let [client (new org.apache.http.impl.client.DefaultHttpClient)]
>>>    (with-open [rdr (reader
>>>                     (.getContent
>>>                      (.getEntity
>>>                       (.execute client (new
>>> org.apache.http.client.methods.HttpGet url)
>>>                ]
>>
>
> As an aside, the following is an alternate way of writing that intializer:
>
> (-> client
>     (.execute (org.apache.http.client.methods.HttpGet. url))
>    .getEntity .getContent reader)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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


Re: probable bug in transients ..

2011-01-06 Thread Chas Emerick

On Jan 6, 2011, at 1:48 PM, Ken Wesson wrote:

> On Thu, Jan 6, 2011 at 1:08 PM, Raoul Duke  wrote:
>> On Thu, Jan 6, 2011 at 3:32 AM, Baishampayan Ghose  wrote:
>>> Haha! Same here. I have used transients many times too, but I fell
>>> into the trap this time :)
>> 
>> now if only there were some kind of programming language technology
>> that could help us figure out when we're mis-applying operations to
>> things... ;-)
> 
> A compiler warning if the return value from assoc!, disj!, or conj! is
> discarded could help in this particular case.

There's a plethora of established idioms that warrant a warning of some sort 
when violated.  This would ideally be the domain of a good Clojure linter, 
rather than playing whack-a-mole with particular violations by piling warnings 
into the compiler (for which there are surely higher priority TODOs).  Such a 
tool would ideally be implemented such that any development environment could 
apply it...and, when the compiler is revisited such that it becomes more easily 
extensible, it may well be able to make use of that linter as desired.

- Chas

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


Re: What am I not getting here?

2011-01-06 Thread Jason Wolfe
You're not capturing the output of the reduce anywhere; doseq is for
side-effects only.

If you wrapped the doseq in a "(def dictionary ...)" it would work,
but this is not recommended.
Instead, you should either use nested reductions, or produce a simple
list of tokens first (simpler):

(defn process-file [file-name]
  (with-open [rdr (BufferedReader. (FileReader. file-name))]
(reduce #(assoc %1 %2 (inc (get %1 %2 1))) {}
   (mapcat #(re-seq #"[a-z]+" (.toLowerCase %))
(line-seq rdr)

(def dictionary (process-file "src/SpellChecker.clj"))

(Untested).  Or, using clojure-contrib functions:

(defn process-file [file-name]
 (->> (clojure.contrib.duck-streams/read-lines file-name)
(mapcat #(re-seq #"[a-z]+" (.toLowerCase %)))
clojure.contrib.seq/frequencies))

(also untested).

Cheers, Jason


On Jan 6, 10:49 am, new2clojure  wrote:
> Hi,
>
> I am trying to store into a map the frequency of each [a-z]+ word in a
> file. When I run this code in the repl the resulting dictionary is
> empty. How should I adapt my code to get this functionality right?.
>
> Thank you in advance
>
> (import (java.io BufferedReader FileReader))
>
> (def dictionary {})
>
> (defn process-file [file-name]
>   (with-open
>     [rdr (BufferedReader. (FileReader. file-name))]
>     (doseq
>       [line (line-seq rdr)]
>       (reduce #(assoc %1 %2 (inc (get %1 %2 1))) dictionary (re-seq
> #"[a-z]+" (.toLowerCase line))
>
> (process-file "src/SpellChecker.clj")

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


Re: What am I not getting here?

2011-01-06 Thread Benny Tsai
I was typing up an answer, but Jason answered faster and better :)

The only thing I have to add is that 'frequencies' is also in clojure
core as of 1.2.

On Jan 6, 1:13 pm, Jason Wolfe  wrote:
> You're not capturing the output of the reduce anywhere; doseq is for
> side-effects only.
>
> If you wrapped the doseq in a "(def dictionary ...)" it would work,
> but this is not recommended.
> Instead, you should either use nested reductions, or produce a simple
> list of tokens first (simpler):
>
> (defn process-file [file-name]
>   (with-open [rdr (BufferedReader. (FileReader. file-name))]
>     (reduce #(assoc %1 %2 (inc (get %1 %2 1))) {}
>        (mapcat #(re-seq #"[a-z]+" (.toLowerCase %))
>                     (line-seq rdr)
>
> (def dictionary (process-file "src/SpellChecker.clj"))
>
> (Untested).  Or, using clojure-contrib functions:
>
> (defn process-file [file-name]
>  (->> (clojure.contrib.duck-streams/read-lines file-name)
>         (mapcat #(re-seq #"[a-z]+" (.toLowerCase %)))
>         clojure.contrib.seq/frequencies))
>
> (also untested).
>
> Cheers, Jason
>
> On Jan 6, 10:49 am, new2clojure  wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I am trying to store into a map the frequency of each [a-z]+ word in a
> > file. When I run this code in the repl the resulting dictionary is
> > empty. How should I adapt my code to get this functionality right?.
>
> > Thank you in advance
>
> > (import (java.io BufferedReader FileReader))
>
> > (def dictionary {})
>
> > (defn process-file [file-name]
> >   (with-open
> >     [rdr (BufferedReader. (FileReader. file-name))]
> >     (doseq
> >       [line (line-seq rdr)]
> >       (reduce #(assoc %1 %2 (inc (get %1 %2 1))) dictionary (re-seq
> > #"[a-z]+" (.toLowerCase line))
>
> > (process-file "src/SpellChecker.clj")

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


Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Tim Daly



On 1/6/2011 12:07 PM, Michael Wood wrote:

Hi

On 6 January 2011 07:33, Tim Daly  wrote:
[...]

Take a look at http://daly.axiom-developer.org/clojure.pdf

I like it :)

Some simple corrections:

You have a typo on the front page:

"Based on Version 1.3.0-alphs4" (alphs4 instead of alpha4).

In the foreword, "This is a literate fork of Clojure, invented by Rich
Hickey." sounds a little like Rich Hickey invented this fork of
Clojure rather than Clojure itself.

You're right. Rich did not invent the fork. The spoon, perhaps.
This is why projects need an Editor-in-Chief.

I have no idea what that "((iHy))" means after the date at the end of
the foreword.

It is an lisp joke between myself and certain others. Ignore it.

Page 2:

Last sentence of 1.3.2 says "We will look now look...".

In 1.3.3 the methods for updating the right member are identical to
the ones for the left member.  I suspect "left" should be replace with
"right" in all three lines?

Page 5:

Fourth paragraph of 1.3.5 contains a sentence with a missing "a":
"Since it is copy operation...".

Also in 1.3.5, the list of Black node types duplicates the information
in 1.3.3.  (Same with the list of Red nodes in 1.3.11.)

In the introductions to the Black, BlackVal, BlackBranch and
BlackBranchVal descriptions you say "This is constructed by
PersistenTreeMap's black method."  Are all of them constructed with
the black method?  If so, perhaps you should say that somewhere
instead of saying it separately for each one?  Perhaps 1.3.10 is
enough.  Just when I was reading through the introductions to Black,
BlackVal etc., I kept wondering if the next one was going to say it
was constructed by some method other than black, since you were
explicitly mentioning it every time.

Page 9:

There seems to be a spurious "new" in the first sentence: "If either
of the children exist but new have no value for this node..."

The second sentence of 1.3.11 is confusing to me.  It seems to me that
the colour of the node returned has nothing to do with whether or not
subtrees are balanced, so it doesn't make sense to me to contrast
these two things.  (Of course I know nothing about Red Black trees
other than what I've read so far in this document.)

The next paragraph is a little confusing to me too.  Why would Red
nodes have to be returned only because the default colour is Black?
Surely even if the default colour were Red, Red nodes would need to be
returned?  Perhaps I'm missing something fundamental about how Red
Black trees work.

One of the struggles about these paragraphs is that I am trying
to reverse engineer Rich's code. There are no comments to guide the
connection between ideas and code. I have to stare at it and guess
his intentions and mindset. Ideally code would be "born literate"
but that is not the case here.

The posted version

Page 13:

1.3.16 seems to be more or less a copy of 1.3.10 with Black replaced
with Red, so it also has the extraneous "new".

I did a self-study of errors once and found that 50 percent of all
the errors I ever make are caused by copy-pasting. You think I would
learn but apparently I don't.

Page 14:

The second sentence of 1.3.17 says "... all four cases all
balance...".  It would be better without the second "all".

The next paragraph says "Each cases shows the ML code...".  This
should of course be "Each case...".  Also, what is "ML code"?

You're right. I should define all my abbreviations like ML before
they are used. I added a line to define it along with two literature
references.


Page 16:

There's a missing "'s" in the second sentence: "... a black node (p5)
removeRight method..."

Anyway, that's as far as I've got so far.

Very useful feedback. Thanks.

Tim Daly

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


Re: What am I not getting here?

2011-01-06 Thread Ken Wesson
On Thu, Jan 6, 2011 at 1:49 PM, new2clojure  wrote:
>
> Hi,
>
> I am trying to store into a map the frequency of each [a-z]+ word in a
> file. When I run this code in the repl the resulting dictionary is
> empty. How should I adapt my code to get this functionality right?.
>
> Thank you in advance
>
> (import (java.io BufferedReader FileReader))
>
> (def dictionary {})
>
> (defn process-file [file-name]
>  (with-open
>    [rdr (BufferedReader. (FileReader. file-name))]
>    (doseq
>      [line (line-seq rdr)]
>      (reduce #(assoc %1 %2 (inc (get %1 %2 1))) dictionary (re-seq
> #"[a-z]+" (.toLowerCase line))

The main problem is (doseq ...) should be (loop [words {}] ...) or
(apply merge ...). But there's another bug: the third argument to get
should be 0 rather than 1. You could also use (merge-with + %1 {%2
1}). Or frequencies:

(frequencies (re-seq ...))

Try

(defn process-file [file-name]
  (with-open [rdr (BufferedReader. (FileReader. file-name))]
(apply merge-with +
  (for [line (line-seq rdr)]
(frequencies (re-seq #"[a-z]+" (.toLowerCase line)))

(untested, but should be closer).

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


Re: What am I not getting here?

2011-01-06 Thread Sean Corfield
On Thu, Jan 6, 2011 at 10:49 AM, new2clojure  wrote:
> I am trying to store into a map the frequency of each [a-z]+ word in a
> file. When I run this code in the repl the resulting dictionary is
> empty. How should I adapt my code to get this functionality right?.

Other people have offered up alternate solutions that should get you
pointed in the right direction but I wanted to highlight an important
issue which may be tripping you up, depending on your background:

> (def dictionary {})

This defines dictionary as an empty map. dictionary is immutable.

> (defn process-file [file-name]
>  (with-open
>    [rdr (BufferedReader. (FileReader. file-name))]
>    (doseq
>      [line (line-seq rdr)]
>      (reduce #(assoc %1 %2 (inc (get %1 %2 1))) dictionary (re-seq
> #"[a-z]+" (.toLowerCase line))

This does not change dictionary. The (assoc) call returns a new map.
The (reduce) call will ultimately return a new map (the result of
calling assoc several times).

The lack of side-effects / assignment can be quite hard to get your
head around if you're not used to functional programming.

As Ken noted, your (get) call needs to use 0 not one (since you always
(inc) it):

user=> (reduce #(assoc %1 %2 (inc (get %1 %2 1))) {} ["these" "are"
"some" "words" "with" "some" "words" "repeated"])
{"repeated" 2, "with" 2, "words" 3, "some" 3, "are" 2, "these" 2}

With (get %1 %2 0) we get the correct result:

user=> (reduce #(assoc %1 %2 (inc (get %1 %2 0))) {} ["these" "are"
"some" "words" "with" "some" "words" "repeated"])
{"repeated" 1, "with" 1, "words" 2, "some" 2, "are" 1, "these" 1}
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

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


Errors w/ dynamic symbols in macro-utils or monads?

2011-01-06 Thread Chris Riddoch
Hi, everyone.

With the changes to dynamic symbols in 1.3.0-snapshot, a number of
modules of contrib/ seem unable to function.  I'm trying to see if I
can get fnparse to run under the master branch, and it wants
contrib/monads, which in turn wants contrib/macro-utils.

The following error happens at the definition of m-fmap.  I'm
confused, because protected-symbols looks like it's marked ^:dynamic,
at line 48 of macro_utils.clj.

user=> (use 'clojure.contrib.macro-utils)
nil
user=> (use 'clojure.contrib.monads)
CompilerException java.lang.IllegalStateException: Can't dynamically
bind non-dynamic var: clojure.contrib.macro-utils/protected-symbols,
compiling:(clojure/contrib/monads.clj:195)

I'm having difficulty tracing this issue any further.  Can someone
shed some light on this?

In the meantime, I'll drop back to 1.2.0, but I'd prefer to stay current...

-- 
Chris Riddoch

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread Sean Corfield
On Thu, Jan 6, 2011 at 2:33 AM, LauJensen  wrote:
> Yes the two statements are equivalent. ClojureQL compiles everything
> to prepared
> statements, with every argument automatically paramterized.

Cool, that's what I'd hoped. But just to clarify...

If I have code that repeatedly calls this:

@(-> (table :user)
    (select (where (= :id user-id)))
    (project [:dateofbirth :gender :zipcode]))

it is going to construct that AST and compile it to SQL every time it
hits it, yes?
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

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


Re: The human brain works the Lisp way!

2011-01-06 Thread Michael Aldred
G'day Arie,

You have to be very careful about listening to things Ray Kurzweil
says when he's talking about the brain, etc.

I would think it would be better to listen to someone actually
conducting brain/AI research, for example, Jeff Hawkins.  His company
Numenta seems to be making great progress with HTM which he outlined
in his book 'On Intelligence'.

Papers are also available on numenta.com

Now I'm really not top notch on my computer science/math and AI, but
from what I understand of HTM, which is based off the biological
structure of the brain, I think that saying the brain is like a LISP
processor doesn't make sense.  But of course I haven't watched the
video, so he may explain his reasoning.  But without a bigger context
I'm very doubtful of such statements.

Thanks for the link though, I will look at it later.

Cheers

On Jan 6, 7:45 pm, Arie van Wingerden  wrote:
> Hi,
>
> on this 
> pagehttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to...
> you
> can find a video in which Ray Kurzweil speaks about the "reverse
> engineering" of the human brain.
>
> At 39:25 Ray states that "... the cerebral cortex is a Lisp processor." and
> explains that later.
>
> Maybe it is off topic, but I think it may be very interesting to a lot of
> you.
>
> Kind regards,
>    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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Loading JNI

2011-01-06 Thread ax2groin
Sorry for the late response, but I haven't had time to play with
things in a couple days.

First discovery is that I probably cannot use the library path
variable, because some of the DLLs have to be loaded in a specific
order. Specifically, there is a "clientswig.dll" that has to be loaded
last. Going back to the old style of loading them manually inside the
Clojure code, I still have a problem, though.

The problem now seems to be with the JAR file that I need to be using.
I get a NoClassDefFoundError on a class within the JAR: "Could not
initialize class ...ClientModuleJNI".

I have included the JAR in the build path as I traditionally would in
Eclipse (Properties -> Java Build Path -> Libraries -> Add JARs). I've
also tried launching from the command line and get the same error.

I've mangled the code below to hide company-specific information, but
this is what I'm doing right now.

--- In Clojure ---

(ns app)

(def path "C:\\SVN\\lib3rdParty\\")
(try (System/load (str path "client.dll")) (catch UnsatisfiedLinkError
e (println "Failed library load.")))
(try (System/load (str path "utils.dll")) (catch UnsatisfiedLinkError
e (println "Failed library load.")))
(try (System/load (str path "clientswig.dll")) (catch
UnsatisfiedLinkError e (println "Failed library load.")))

(import '(com.app Client ClientSession))

(def my-client (Client.))

--- In Java ---

public final class AlertClient extends Client {

// Load the JNI
static {
try {
path = "C:\\SVN\\lib3rdParty\\";
String[] libraries = { "client.dll", "utils.dll",
"csclientswig.dll" };
for (int i = 0; i < libraries.length; ++i) {
String libPath = path + libraries[i];
System.load(libPath);
}
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load.\n"
+ e);
System.exit(1);
}
}

public AlertClient() throws Exception {
super();
}
}

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


Re: ANN: Tom Faulhaber: "Lisp, Functional Programming, and the State of Flow" video available

2011-01-06 Thread Alan Dipert
Hi Chris, we were happy to provide them.  I'll see what we can do
synchronization-wise with the remaining videos.

Improving our technique around recording, editing, and releasing
videos is on the list of things we hope to do for the next Conj.

Alan

On Wed, Jan 5, 2011 at 1:48 PM, Chris Riddoch  wrote:
> On Mon, Jan 3, 2011 at 11:14 AM, Alan Dipert  wrote:
>> I'm happy to announce that Tom Faulhaber's Conj talk, "Lisp,
>> Functional Programming, and the State of Flow" is now available on
>> Clojure's blip.tv page: http://clojure.blip.tv/file/4521022/
>
> Thanks for your work on making the videos available!  I just watched
> this one, and one thing about the editing could use a little work: the
> video of the speaker in the corner and the audio isn't matched up with
> the video of the slides.  In this one, the video of the slides is a
> little behind the audio, which is okay, but the video of Luke
> VanderHart's slides on zippers is substantially ahead of the audio -
> by 20-30 seconds.  Seeing a different slide from the one actually
> being discussed makes it quite hard to follow!
>
> --
> Chris Riddoch
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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


Re: The human brain works the Lisp way!

2011-01-06 Thread Lee Spector

I just watched about 10 minutes leading up to the comment Arie flagged and it 
seems to me that Kurzweil is actually describing something very much like 
Hawkins's HTM model *at* a certain level of abstraction. He makes some other 
interesting comments about Lisp that might strike some here as bizarre but make 
sense to me in context of the Lisp & AI knowledge representation world of the 
70s and 80s.

 -Lee

On Jan 6, 2011, at 7:40 PM, Michael Aldred wrote:

> G'day Arie,
> 
> You have to be very careful about listening to things Ray Kurzweil
> says when he's talking about the brain, etc.
> 
> I would think it would be better to listen to someone actually
> conducting brain/AI research, for example, Jeff Hawkins.  His company
> Numenta seems to be making great progress with HTM which he outlined
> in his book 'On Intelligence'.
> 
> Papers are also available on numenta.com
> 
> Now I'm really not top notch on my computer science/math and AI, but
> from what I understand of HTM, which is based off the biological
> structure of the brain, I think that saying the brain is like a LISP
> processor doesn't make sense.  But of course I haven't watched the
> video, so he may explain his reasoning.  But without a bigger context
> I'm very doubtful of such statements.
> 
> Thanks for the link though, I will look at it later.
> 
> Cheers
> 
> On Jan 6, 7:45 pm, Arie van Wingerden  wrote:
>> Hi,
>> 
>> on this 
>> pagehttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to...
>> you
>> can find a video in which Ray Kurzweil speaks about the "reverse
>> engineering" of the human brain.
>> 
>> At 39:25 Ray states that "... the cerebral cortex is a Lisp processor." and
>> explains that later.
>> 
>> Maybe it is off topic, but I think it may be very interesting to a lot of
>> you.
>> 
>> Kind regards,
>>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
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

--
Lee Spector, Professor of Computer Science
Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspec...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread Ken Wesson
On Thu, Jan 6, 2011 at 7:33 PM, Sean Corfield  wrote:
> On Thu, Jan 6, 2011 at 2:33 AM, LauJensen  wrote:
>> Yes the two statements are equivalent. ClojureQL compiles everything
>> to prepared
>> statements, with every argument automatically paramterized.
>
> Cool, that's what I'd hoped. But just to clarify...
>
> If I have code that repeatedly calls this:
>
> @(-> (table :user)
>     (select (where (= :id user-id)))
>     (project [:dateofbirth :gender :zipcode]))
>
> it is going to construct that AST and compile it to SQL every time it
> hits it, yes?

I'd hope it has some kind of caching or memoization behind the scenes,
but if not, that'd be a great thing to add for version 1.1. I think a
typical database client app uses a finite variety of prepared
statements (each with potentially changing parameter values), so
straight memoization ought to do fine and clojure already natively
supports that, so ...

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


Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Ken Wesson
I've now had a quick look at this too.

Aside from the grammatical and spelling nitty-gritty, there are some
larger scale concerns, ones that unfortunately go to the heart of the
entire "literate programming" concept.

Namely, at the start it jumps very quickly into a red-black tree
implementation without really motivating it.

Now, it mentions wanting a binary search tree, and that a red-black
tree maintains certain invariants that limit how unbalanced it can
get, but the explicit motivation for this (avoiding the linear
worst-case performance of a fully unbalanced tree in favor of a tree
that gives guaranteed logarithmic bounds on its operations, other than
the obviously-linear-best-case full traversal of course).

More significantly, there's no explanation for introducing a binary
search tree in the first place -- and mention of Java but no direct
motivation for not using java.util.TreeMap or similar instead of
rolling our own. There's a brief mention of immutability and
persistence, without the connecting thoughts -- namely we want clojure
to have an immutable sorted-map type, and while we could use a factory
function that spits out (Collections/unmodifiableMap (doto (TreeMap.)
#(doseq [[k v] kvs] (.put % k v, every assoc would require copying
the entire map, in linear time and space, etc. etc. etc., vs. using a
"persistent" data structure specifically designed for structure
sharing with modified versions.

And then of course the overarching purpose of Clojure itself isn't
even given, let alone why it has sorted-map, and why it's an immutable
sorted-map ...

I know, I know, tall order, right? I hope you're at least thinking
about this stuff for the eventual final version, though. (And why
start with the red-black tree, anyway? After introducing Clojure I'd
probably start with getting a minimalist implementation that is
runnable first -- so the compiler and evaluator and repl and
s-expressions, lists and any other infrastructure these need under the
hood, and whatever else is needed for this -- some of the numerics
stuff, symbols and symbol interning, etc.; then with already a basic
Lisp environment in play, adding the other functions and data
structures in core that weren't needed just to get things up and
running with a basically functional repl. Maybe sorted-map (or a
persistent immutable binary search tree implemented in Java) is one of
the things that is needed to get the compiler working, but if so, I'd
think a truly literate version is going to explain what Clojure is,
and then how we're gonna implement it, and then details of the planned
compiler implementation, and why this needs a persistent immutable
binary search tree, and how that will also be useful later for making
the user-visible sorted-map and sorted-set features, and THEN get down
into the weeds of how we make a persistent immutable binary search
tree, how we can avoid the linear worst-time behavior of unbalanced
trees by ensuring the tree never gets too far out of balance (and even
what "balanced" means in this context), and that red-black trees are
among several kinds that have such properties, and then why red-black
trees were chosen over, say, two-three trees, etc.

Of course, you might need to ask Rich some questions to get some of
this information. It's pretty clear how a persistent immutable
balanced search tree is needed to make sorted-map and sorted-set work
well and in a pure-functional way; it may or may not be obvious on
close examination that a red-black tree is a superior choice over the
alternatives; maybe it isn't and Rich's choice was more or less
arbitrary, or based on what he already knew how to implement or had a
reference handy for; or Rich tried several alternatives and found that
he could make a Java implementation of a persistent, immutable
red-black tree faster than any of the others, or better at
structure-sharing; to really be sure, unless it really does become
obvious on looking into the code itself why, you'd have to ask Rich
why he chose red-black trees for this job. And there will probably be
many other similar points in the code where there's an implementation
choice that may not be obvious without Rich's input. And all of them
will need some explanation, if the program is to be truly literate --
even if there turn out to be cases where that explanation will be
something like "tests showed that X and Y were equally good
alternatives for implementing this, so Rich just flipped a coin and it
came up tails so he used Y". :)

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


Re: map destructuring with defaults

2011-01-06 Thread Seth
Ah. But a new map is being created with the default :or operation. I
guess the ability to get this entire map with defaults is not
available directly from clojure destructuring binding.

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


Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Tim Daly



On 1/6/2011 9:15 PM, Ken Wesson wrote:

I've now had a quick look at this too.

Aside from the grammatical and spelling nitty-gritty, there are some
larger scale concerns, ones that unfortunately go to the heart of the
entire "literate programming" concept.

Namely, at the start it jumps very quickly into a red-black tree
implementation without really motivating it.

Actually the document was released because it contained a complete
working version of Clojure so it was the initial starting point.

I started on the Red Black tree section so I could show an example
of how to reorganize the code presentation so that it fit the
presentation in text rather than fitting the requirements of Java.

Red Black trees are mentioned in one of Rich's lectures as an
implementation detail so I decided to try and reverse engineer
their use.

Clearly there needs to be some discussion about Persistence and
Okasaki and Rich's research references motivating why they were
chosen.

I did this with the section on Bit-partitioned hash tries.
That version has not been published yet.



Now, it mentions wanting a binary search tree, and that a red-black
tree maintains certain invariants that limit how unbalanced it can
get, but the explicit motivation for this (avoiding the linear
worst-case performance of a fully unbalanced tree in favor of a tree
that gives guaranteed logarithmic bounds on its operations, other than
the obviously-linear-best-case full traversal of course).

More significantly, there's no explanation for introducing a binary
search tree in the first place -- and mention of Java but no direct
motivation for not using java.util.TreeMap or similar instead of
rolling our own. There's a brief mention of immutability and
persistence, without the connecting thoughts -- namely we want clojure
to have an immutable sorted-map type, and while we could use a factory
function that spits out (Collections/unmodifiableMap (doto (TreeMap.)
#(doseq [[k v] kvs] (.put % k v, every assoc would require copying
the entire map, in linear time and space, etc. etc. etc., vs. using a
"persistent" data structure specifically designed for structure
sharing with modified versions.

And then of course the overarching purpose of Clojure itself isn't
even given, let alone why it has sorted-map, and why it's an immutable
sorted-map ...

There is very little that needs to be said about the overarching
purpose of Clojure for the expected target audience. Since this
includes detailed source code in two languages it is reasonable to
assume that it is being read by a programmer and, more specifically,
it is being read by a programmer who is interested in the details
of Clojure's implementation.

I know, I know, tall order, right? I hope you're at least thinking
about this stuff for the eventual final version, though. (And why
start with the red-black tree, anyway? After introducing Clojure I'd
probably start with getting a minimalist implementation that is
runnable first

The included implementation is runnable. I was not advocating
literate program at the introduction of Clojure 1.0 so the first
version is 1.3 which is not minimalist in any sense.


  -- so the compiler and evaluator and repl and
s-expressions, lists and any other infrastructure these need under the
hood, and whatever else is needed for this -- some of the numerics
stuff, symbols and symbol interning, etc.; then with already a basic
Lisp environment in play, adding the other functions and data
structures in core that weren't needed just to get things up and
running with a basically functional repl.

I wish Clojure was "factored" in terms of the implementation
to suit the I2I (ideas-to-implementation) approach but it isn't.
The literate goal here isn't to rewrite or refactor it but to
explain how the ideas are realized in code. A different goal
would be to factor Clojure in layers but that's someone else's book.

  Maybe sorted-map (or a
persistent immutable binary search tree implemented in Java) is one of
the things that is needed to get the compiler working, but if so, I'd
think a truly literate version is going to explain what Clojure is,
and then how we're gonna implement it, and then details of the planned
compiler implementation, and why this needs a persistent immutable
binary search tree, and how that will also be useful later for making
the user-visible sorted-map and sorted-set features, and THEN get down
into the weeds of how we make a persistent immutable binary search
tree, how we can avoid the linear worst-time behavior of unbalanced
trees by ensuring the tree never gets too far out of balance (and even
what "balanced" means in this context), and that red-black trees are
among several kinds that have such properties, and then why red-black
trees were chosen over, say, two-three trees, etc.

Of course, you might need to ask Rich some questions to get some of
this information.

Rich obviously knows the answers to these questions but he is
a valuable and highly constr

Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Ken Wesson
On Thu, Jan 6, 2011 at 11:05 PM, Tim Daly  wrote:
> On 1/6/2011 9:15 PM, Ken Wesson wrote:
>> And then of course the overarching purpose of Clojure itself isn't
>> even given, let alone why it has sorted-map, and why it's an immutable
>> sorted-map ...
>
> There is very little that needs to be said about the overarching
> purpose of Clojure for the expected target audience. Since this
> includes detailed source code in two languages it is reasonable to
> assume that it is being read by a programmer and, more specifically,
> it is being read by a programmer who is interested in the details
> of Clojure's implementation.

Perhaps, but I think it might be worth considering broadening the
potential target audience to include people with some Java knowledge
that are curious about Clojure, but don't necessarily know much about
Clojure.

>> I know, I know, tall order, right? I hope you're at least thinking
>> about this stuff for the eventual final version, though. (And why
>> start with the red-black tree, anyway? After introducing Clojure I'd
>> probably start with getting a minimalist implementation that is
>> runnable first
>
> The included implementation is runnable. I was not advocating
> literate program at the introduction of Clojure 1.0 so the first
> version is 1.3 which is not minimalist in any sense.

Oh, I wasn't suggesting to leave anything out entirely; just to
organize the text to put the bootstrap-necessary material first, until
the code up to that point can get you a working repl with some
functionality, and then after that fleshing out the rest of the
feature-set and standard (clojure.core; contrib would be biting off
more than anyone could probably chew) library.

>>  -- so the compiler and evaluator and repl and
>> s-expressions, lists and any other infrastructure these need under the
>> hood, and whatever else is needed for this -- some of the numerics
>> stuff, symbols and symbol interning, etc.; then with already a basic
>> Lisp environment in play, adding the other functions and data
>> structures in core that weren't needed just to get things up and
>> running with a basically functional repl.
>
> I wish Clojure was "factored" in terms of the implementation
> to suit the I2I (ideas-to-implementation) approach but it isn't.

I thought you had been saying all kinds of stuff about how your
literate-programming tools allow you to organize the material for the
benefit of human readers, rather than the requirements of the
compiling tools? This seems somewhat at odds with that.

>> Of course, you might need to ask Rich some questions to get some of
>> this information.
>
> Rich obviously knows the answers to these questions but he is
> a valuable and highly constrained resource. It would be nice if
> he provided some motivating material but I think that we, as programmers,
> can figure out how bit-partitioning works and how the code implements
> it. Every new developer needs to do that to make changes. Literate
> source code would decrease the time it takes to get up to speed.
> So while it would be nice if Rich contributed I think he has better
> things to do.
...
> Rich has provided a lot of discussion about his motivations
> in his videos.

Then those videos should prove a valuable resource for you.

> There was a discussion a while back about providing
> this same information in textual form and as a result of that
> I ended up advocating literate programming which led to this.

I seem to recall being involved in that discussion. :)

> I am hoping that showing an example of literate Clojure will
> motivate others to pick a section (e.g. agents) and work through
> the details. Once a section is written it can benefit from the
> "many eyes" of open source to improve the style and accuracy
> of presentation. In that way we all end up developing a document
> that quickly brings up the average quality material for developers.

That seems to me to suggest creating a wiki or similar for this
project. Why stop with half-measures? Let anyone contribute. Sections
can be marked as code-only, code and partial text, and code with
completed text; encourage people to flesh out the first two and
proofread and correct errors in the latter. Sections with "completed
text" would also have an uneditable "canonical version" that could be
added to the .pamphlet file, though still updated from time to time
with typo fixes and other corrections. (And the whole thing would
retain an uneditable history, like wikis commonly do, as a defense
against vandalism. Think of it as persistent, immutable text editing.
:))

There's also the need though for motivating sections that may not have
any code themselves but would preface some series of code-sections
related to implementing a particular larger element of the
architecture, such as the compiler, maps, or lazy sequences.

Any such wiki should probably allow such sections to be created, and
provide a discussion forum of some sort for debating which such
sections are ne

Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Tim Daly



On 1/6/2011 11:42 PM, Ken Wesson wrote:

On Thu, Jan 6, 2011 at 11:05 PM, Tim Daly  wrote:

On 1/6/2011 9:15 PM, Ken Wesson wrote:

And then of course the overarching purpose of Clojure itself isn't
even given, let alone why it has sorted-map, and why it's an immutable
sorted-map ...

There is very little that needs to be said about the overarching
purpose of Clojure for the expected target audience. Since this
includes detailed source code in two languages it is reasonable to
assume that it is being read by a programmer and, more specifically,
it is being read by a programmer who is interested in the details
of Clojure's implementation.

Perhaps, but I think it might be worth considering broadening the
potential target audience to include people with some Java knowledge
that are curious about Clojure, but don't necessarily know much about
Clojure.

I'm open to including such a section at the beginning of the book.
I'm not a Java programmer though, I come from the Lisp side.
If you're willing to write it, we can add it (Advocacy... :-) )

I know, I know, tall order, right? I hope you're at least thinking
about this stuff for the eventual final version, though. (And why
start with the red-black tree, anyway? After introducing Clojure I'd
probably start with getting a minimalist implementation that is
runnable first

The included implementation is runnable. I was not advocating
literate program at the introduction of Clojure 1.0 so the first
version is 1.3 which is not minimalist in any sense.

Oh, I wasn't suggesting to leave anything out entirely; just to
organize the text to put the bootstrap-necessary material first, until
the code up to that point can get you a working repl with some
functionality, and then after that fleshing out the rest of the
feature-set and standard (clojure.core; contrib would be biting off
more than anyone could probably chew) library.


  -- so the compiler and evaluator and repl and
s-expressions, lists and any other infrastructure these need under the
hood, and whatever else is needed for this -- some of the numerics
stuff, symbols and symbol interning, etc.; then with already a basic
Lisp environment in play, adding the other functions and data
structures in core that weren't needed just to get things up and
running with a basically functional repl.

I wish Clojure was "factored" in terms of the implementation
to suit the I2I (ideas-to-implementation) approach but it isn't.

I thought you had been saying all kinds of stuff about how your
literate-programming tools allow you to organize the material for the
benefit of human readers, rather than the requirements of the
compiling tools? This seems somewhat at odds with that.

Hmmm. I may have misunderstood your point. I thought you were suggesting
writing code that is not part of the distribution in order to get a
minimal running system and then working from that. If that is not what
you're suggesting then I'm confused.

Of course, you might need to ask Rich some questions to get some of
this information.

Rich obviously knows the answers to these questions but he is
a valuable and highly constrained resource. It would be nice if
he provided some motivating material but I think that we, as programmers,
can figure out how bit-partitioning works and how the code implements
it. Every new developer needs to do that to make changes. Literate
source code would decrease the time it takes to get up to speed.
So while it would be nice if Rich contributed I think he has better
things to do.

...

Rich has provided a lot of discussion about his motivations
in his videos.

Then those videos should prove a valuable resource for you.

Yes, I am reviewing the video and slides so the explanation
is as close to Rich's message as possible. These are Rich's
ideas. The goal is to write them down.

There was a discussion a while back about providing
this same information in textual form and as a result of that
I ended up advocating literate programming which led to this.

I seem to recall being involved in that discussion. :)


I am hoping that showing an example of literate Clojure will
motivate others to pick a section (e.g. agents) and work through
the details. Once a section is written it can benefit from the
"many eyes" of open source to improve the style and accuracy
of presentation. In that way we all end up developing a document
that quickly brings up the average quality material for developers.

That seems to me to suggest creating a wiki or similar for this
project. Why stop with half-measures? Let anyone contribute. Sections
can be marked as code-only, code and partial text, and code with
completed text; encourage people to flesh out the first two and
proofread and correct errors in the latter. Sections with "completed
text" would also have an uneditable "canonical version" that could be
added to the .pamphlet file, though still updated from time to time
with typo fixes and other corrections. (And the whole thing would
retain an un

Re: The human brain works the Lisp way!

2011-01-06 Thread Tim Daly

 Rich has suggested the book "Spikes" ISBN 0-262-68108-0
which is about exploring the neural code. This was
mentioned in his Whitehead video.

On 1/6/2011 7:40 PM, Michael Aldred wrote:

G'day Arie,

You have to be very careful about listening to things Ray Kurzweil
says when he's talking about the brain, etc.

I would think it would be better to listen to someone actually
conducting brain/AI research, for example, Jeff Hawkins.  His company
Numenta seems to be making great progress with HTM which he outlined
in his book 'On Intelligence'.

Papers are also available on numenta.com

Now I'm really not top notch on my computer science/math and AI, but
from what I understand of HTM, which is based off the biological
structure of the brain, I think that saying the brain is like a LISP
processor doesn't make sense.  But of course I haven't watched the
video, so he may explain his reasoning.  But without a bigger context
I'm very doubtful of such statements.

Thanks for the link though, I will look at it later.

Cheers

On Jan 6, 7:45 pm, Arie van Wingerden  wrote:

Hi,

on this 
pagehttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to...
you
can find a video in which Ray Kurzweil speaks about the "reverse
engineering" of the human brain.

At 39:25 Ray states that "... the cerebral cortex is a Lisp processor." and
explains that later.

Maybe it is off topic, but I think it may be very interesting to a lot of
you.

Kind regards,
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread Shantanu Kumar


On Jan 7, 6:49 am, Ken Wesson  wrote:
> On Thu, Jan 6, 2011 at 7:33 PM, Sean Corfield  wrote:
> > On Thu, Jan 6, 2011 at 2:33 AM, LauJensen  wrote:
> >> Yes the two statements are equivalent. ClojureQL compiles everything
> >> to prepared
> >> statements, with every argument automatically paramterized.
>
> > Cool, that's what I'd hoped. But just to clarify...
>
> > If I have code that repeatedly calls this:
>
> > @(-> (table :user)
> >     (select (where (= :id user-id)))
> >     (project [:dateofbirth :gender :zipcode]))
>
> > it is going to construct that AST and compile it to SQL every time it
> > hits it, yes?
>
> I'd hope it has some kind of caching or memoization behind the scenes,
> but if not, that'd be a great thing to add for version 1.1. I think a
> typical database client app uses a finite variety of prepared
> statements (each with potentially changing parameter values), so
> straight memoization ought to do fine and clojure already natively
> supports that, so ...

The tricky part is - a PreparedStatement object is created and is
valid only in the context of a Connection object (because statement
compilation is database specific, and often needs an extra roundtrip
to the database). So, unless we are reusing the Connection object
prepared statements need to be created repeatedly and nullifies the
benefit of caching/memoization across several database connections.
Good use-cases for PreparedStatement include batch queries.

An optimization thought: Instead of re-using a Connection object for
all queries (and re-create if necessary), use a DataSource and have
separate Connection objects for each major use-case so that
PreparedStatement objects can be memoized and remain valid for long.

Regards,
Shantanu

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


Re: Knuth's literate programming "tangle" function in Clojure

2011-01-06 Thread Ken Wesson
On Fri, Jan 7, 2011 at 12:07 AM, Tim Daly  wrote:
> Hmmm. I may have misunderstood your point. I thought you were suggesting
> writing code that is not part of the distribution in order to get a
> minimal running system and then working from that. If that is not what
> you're suggesting then I'm confused.

No, I was just suggesting that the order of the material put the stuff
in the distribution that's necessary to bootstrap a minimally
functional repl first, culminating in the eval function and the
command-line repl class, then flesh out the rest of Clojure's
feature-set with the rest of the stuff in the distribution. No new
code.

> The pamphlet sources are in a git repository so they are immutable.
>
> Wikis are fine for a lot of things but not for linearizing the
> ideas into a readable literate form. Books fulfill that role.

I suggested *maybe* letting the wiki users try to decide,
collectively, on a linearization; maybe that would prove workable and
maybe not. If not, you'd have to linearize it yourself to make the
book version. But if you're looking for section submissons and user
proof-reading a wiki can at least organize that activity, and can
provide "seeds" by having unwritten sections in there with just the
source code that is to be explained. And without potential
contributors maybe being put off by having to learn a whole extra set
of tools (namely, github and whatever client software) and get a login
at some site (github). Some might not have used git. A few might not
have used any code repository system. A wiki on the other hand can be
edited by anyone who can type stuff into a web form and can be
configured not to require a login (ala Wikipedia itself).

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread Ken Wesson
On Fri, Jan 7, 2011 at 12:22 AM, Shantanu Kumar
 wrote:
> On Jan 7, 6:49 am, Ken Wesson  wrote:
>> I'd hope it has some kind of caching or memoization behind the scenes,
>> but if not, that'd be a great thing to add for version 1.1. I think a
>> typical database client app uses a finite variety of prepared
>> statements (each with potentially changing parameter values), so
>> straight memoization ought to do fine and clojure already natively
>> supports that, so ...
>
> The tricky part is - a PreparedStatement object is created and is
> valid only in the context of a Connection object (because statement
> compilation is database specific, and often needs an extra roundtrip
> to the database).

That's icky. It's not common for one app to use two separate databases
in a single running instance, so the PreparedStatement should really
be valid across connections as long as they're to the same server.

Failing that, though, keeping the Connection object alive makes sense
anyway as another optimization. It's common for web browsers to keep
one or a few HTTP connections to a server alive for a while after
retrieving a page, in case the user browses repeatedly to links that
stay inside the one site. If a page has lots of images loaded from a
single server it also comes in handy to reuse a single connection for
the whole batch. It makes sense to do something similar with database
connections.

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


Re: map destructuring with defaults

2011-01-06 Thread Alan
No, no new map is created. The :or clause simply creates the local
binding for you if none existed in the map; there's no need for it to
create a second map to do this.

On Jan 6, 6:27 pm, Seth  wrote:
> Ah. But a new map is being created with the default :or operation. I
> guess the ability to get this entire map with defaults is not
> available directly from clojure destructuring binding.

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


Re: ANN: ClojureQL 1.0.0 now released

2011-01-06 Thread Shantanu Kumar


On Jan 7, 10:32 am, Ken Wesson  wrote:
> On Fri, Jan 7, 2011 at 12:22 AM, Shantanu Kumar
>
>  wrote:
> > On Jan 7, 6:49 am, Ken Wesson  wrote:
> >> I'd hope it has some kind of caching or memoization behind the scenes,
> >> but if not, that'd be a great thing to add for version 1.1. I think a
> >> typical database client app uses a finite variety of prepared
> >> statements (each with potentially changing parameter values), so
> >> straight memoization ought to do fine and clojure already natively
> >> supports that, so ...
>
> > The tricky part is - a PreparedStatement object is created and is
> > valid only in the context of a Connection object (because statement
> > compilation is database specific, and often needs an extra roundtrip
> > to the database).
>
> That's icky. It's not common for one app to use two separate databases
> in a single running instance, so the PreparedStatement should really
> be valid across connections as long as they're to the same server.

It should be really good if that's true - please let me know the
source if you have. However, the JDBC spec doesn't seem to indicate so
(I guess that's because Connections can be created with custom
parameters to change some runtime attributes):

http://download.oracle.com/javase/6/docs/api/java/sql/Connection.html#prepareStatement(java.lang.String)

http://www.javaperformancetuning.com/tips/jdbc_prepared.shtml#REF14

http://www.java-blog.com/prepared-statements-jdbc


Regards,
Shantanu

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


possible bug in `case'

2011-01-06 Thread Eric Schulte
Hi,

The following case statement

  #+begin_src clojure
(defn buggy-case [n]
  (case (int n)
0  :null
1  :load
0x7000 :loproc))
  #+end_src

throws the following error

  No distinct mapping found
[Thrown class java.lang.IllegalArgumentException]

However removing any of the cases alleviates the problem.  Am I missing
something obvious, or is this a bug in the case statement?

Thanks -- Eric

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


Re: possible bug in `case'

2011-01-06 Thread Alan
It looks like a problem in clojure.core/min-hash to me. case depends
on min-hash to generate ahead-of-time hashes of all the test clauses,
and while I can't easily follow what's going on, it seems to be trying
to find a shift/mask combination that is...somehow related to the
hashes of the test clauses. I speculate that it's easier to perform
this operation on N values than N+1; with (0,0x7000) it's hard,
but with another 1 it becomes unmanageable with the simple algorithm.

On Jan 6, 10:49 pm, "Eric Schulte"  wrote:
> Hi,
>
> The following case statement
>
>   #+begin_src clojure
>     (defn buggy-case [n]
>       (case (int n)
>             0          :null
>             1          :load
>             0x7000 :loproc))
>   #+end_src
>
> throws the following error
>
>   No distinct mapping found
>     [Thrown class java.lang.IllegalArgumentException]
>
> However removing any of the cases alleviates the problem.  Am I missing
> something obvious, or is this a bug in the case statement?
>
> Thanks -- Eric

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