Re: How to make function that derefs vars and refs?

[Anand Patil]

On Jan 19, 1:05 am, Stuart Sierra  wrote:
> On Jan 18, 6:56 pm, Anand Patil 
> wrote:
>
> > Would it make any sense to make @ polymorphic so that @x return x's
> > value when x is a var rather than raising an error?
>
> Actually, it already is:
>
> user> (def x 5)
> #'user/x
> user> (deref (var x))
> 5
> user> @(var x)
> 5
>
> @x is just shorthand for (deref x), which resolves to (deref 5), which
> doesn't make sense.

Stuart,

Sorry, I was not being clear. Why not just let (deref 5) return 5? I
would consider that syntactic sugar, as it would make it easier to
deref a mixed vector of refs, constants, agents and atoms without
keeping track of which indices correspond to (ref, agent, atom)s and
which to constants.

Thanks,
Anand


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

defmacro returns nil

[Christophe Grand]

Hello,

While playing with clojure.contrib.test-is/with-test I realized that I 
was unable to use with-test with macros because the form (defmacro foo 
[bar]) returns nil and not #'foo.
Please find attached a patch.

Christophe

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

Index: C:/Documents and Settings/Christophe/workspaces/clojure/clojure/src/clj/clojure/core.clj
===
--- C:/Documents and Settings/Christophe/workspaces/clojure/clojure/src/clj/clojure/core.clj	(revision 1215)
+++ C:/Documents and Settings/Christophe/workspaces/clojure/clojure/src/clj/clojure/core.clj	(working copy)
@@ -274,7 +274,8 @@
  defmacro (fn [name & args]
 (list 'do
   (cons `defn (cons name args))
-  (list '. (list 'var name) '(setMacro)
+  (list '. (list 'var name) '(setMacro))
+  (list 'var name
 
 (. (var defmacro) (setMacro))
 

A couple of questions concerning syntax-quote

[Rock]

I'm trying to make the documentation (still awaiting approval) in the
"Learning Clojure" WikiBook regarding syntax-quote expansion as
accurate as possible (like in the CL HyperSpec).

I've recently noticed something. In "The Reader" section of the
Clojure Reference, where it explains syntax-quotes, it says:

"For all forms other than Symbols, Lists, Vectors and Maps, `x is the
same as 'x."

Yet, I noticed that for *values* such as numbers, strings etc...
that's not exactly so. Let's expand a syntax-quote expression like the
following:

`(x 5) ===> (clojure.core/concat (clojure.core/list (quote user/x))
(clojure.core/list 5))

See the difference between what happens to the symbol x ===> (quote
user/x) and what happens to 5?

It looks like `5 gets expanded to 5 and not (quote 5). Now I know that
they evaluate to the same identical thing. But what I'm interested in,
is the precise expansion algorithm.

So my first question is:

1) Is it true that, for values, we have for instance `5 ===> 5 in a
syntax-quote expansion (not evaluation!).

There's another thing I'm curious about. Syntax-quotes are there to
simplify such things as wiriting macros (especially) for us. Now I'm
trying to be rigorous in the docs so that everything is clear. But the
whole reason for syntax-quotes is to make life easier, so there's no
point in someone having to mentally expand those expressions every
time even if he/she knows the precise rules.

Paul Graham discusses this in Ansi Common Lisp. He also illustrates
there an equivalent way of expanding backquote expressions which is
truly useful and possibly less confusing for a human mind especially
when dealing with notoriously difficult nested backquotes (or syntax-
quotes in our own terminology :-) ). I think it was taken from Scheme,
but I'm not certain. Anyway it's pretty simple and straightforward. It
works like this:

"To evaluate a backquoted expression, you remove the backquote
and each matching comma, and replace the expression following each
matching
comma with its value. Evaluating an expression that begins with a
comma causes an
error.
A comma matches a backquote if there are the same number of commas
as
backquotes between them, where b is between a and c if a is prepended
to an expression
containing b, and b is prepended to an expression containing c. This
means that in a
well-formed expression the outermost backquote matches the innermost
comma(s).
Suppose that x evaluates to a, which evaluates to 1; and that y
evaluates to b,
which evaluates to 2. To evaluate the expression

``(w ,x ,,y )

we remove the first backquote and evaluate what follows any matching
comma. The
rightmost comma is the only one that matches the first backquote. If
we remove it and
replace the expression it's prepended to, y, with its value, we get:

`(w ,x ,b)

and if we evaluate that in turn we get:

(w a 2)"

That's Common Lisp notation so mentally replace commas with ~. It took
me some getting used too! :-)

Now my other question is this:

2) Given that in Clojure a syntax-quote (`) doesn't just quote a
*symbol* but *resolves* it in the current context, would the above
method still be applicable or is it compromised because of this?
That's something that isn't clear to me yet.

Thanks.

Rock

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

Yet another html templating library

[Christophe Grand]

Hello group!

Enlive (http://github.com/cgrand/enlive/tree/master) is a selector based 
templating library.
The main design goal was to decouple html and presentation code, that's 
why enlive templates are plain old html files (it will ease 
roundtripping with designers).
In code, you have to declare where and how to alter the html template 
using CSS-like selectors.
The resulting templatings functions are compiled (the html tree isn't 
transformed at runtime) and yields a seq of strings.

Here is an example:
http://github.com/cgrand/enlive/blob/2a15c466048f7e0311243b3d7a669705bbcbe072/src/net/cgrand/enlive_html/examples.clj

(Disclaimer: original idea by Ozzilee, 
http://clojure-log.n01se.net/date/2008-05-30.html#09:19)

Christophe

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

Re: Yet another html templating library

[lpetit]

Hello,

Is it somehow related to the way Wicket does templating  ?

On Jan 19, 11:34 am, Christophe Grand  wrote:
> Hello group!
>
> Enlive (http://github.com/cgrand/enlive/tree/master) is a selector based
> templating library.
> The main design goal was to decouple html and presentation code, that's
> why enlive templates are plain old html files (it will ease
> roundtripping with designers).
> In code, you have to declare where and how to alter the html template
> using CSS-like selectors.
> The resulting templatings functions are compiled (the html tree isn't
> transformed at runtime) and yields a seq of strings.
>
> Here is an 
> example:http://github.com/cgrand/enlive/blob/2a15c466048f7e0311243b3d7a669705...
>
> (Disclaimer: original idea by 
> Ozzilee,http://clojure-log.n01se.net/date/2008-05-30.html#09:19)
>
> Christophe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

2 Cents Calculator

[janus]

Being new to Clojure , I started off playing with the codes ,and this
is the result, a 2cents calculator. It is not yet a done deal,
however, my laptop got fried, so I would be redundant for few days,
that's why I' ve decided to 'outsource' :).I invite your comments and
any code that might make this toy to worth 2 cents in today's market.

Emeka

(import '(javax.swing JFrame JLabel JTextField JButton)
'(java.awt.event ActionListener)
'(java.awt GridLayout)
'(java.awt BorderLayout))
(def gool (ref ""))
(def perm1 (ref 0))
(def perm2 (ref  0))
(def sign-to (ref 0))
(defn twocents []
;; setting up buttons
(let [frame (new JFrame "2Cents Calculator" )
temp-text (new JTextField )
clear-button (new JButton "C")
one-button (new JButton "1")
two-button (new JButton "2")
three-button (new JButton "3")
four-button (new JButton "4")
five-button (new JButton "5")
six-button (new JButton "6")
seven-button (new JButton "7")
eight-button (new JButton "8")
nine-button (new JButton "9")
zero-button (new JButton "0")
plus-button (new JButton "+")
minus-button (new JButton "-")
calculate-button (new JButton "=")
divide-button (new JButton "/")]
;; Adding event listeners to buttons
(. plus-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(let [c (. Double (parseDouble (. temp-text (getText]
(. temp-text
(setText (str " ")) ) (dosync (ref-set perm1 c)))(dosync (ref-set gool
(str )) (ref-set sign-to +))
(. minus-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(let [c (. Double (parseDouble (. temp-text (getText]
(. temp-text
(setText (str " ")) ) (dosync (ref-set perm1 c)))(dosync (ref-set gool
(str )) (ref-set sign-to -))
(. divide-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(let [c (. Double (parseDouble (. temp-text (getText]
(. temp-text
(setText (str " ")) ) (dosync (ref-set perm1 c)))(dosync (ref-set gool
(str )) (ref-set sign-to /))
(. calculate-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(let [c (. Double (parseDouble (. temp-text (getText]
(. temp-text
(setText (str (sign-to @perm1  c)
(. clear-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(let [c nil]
(. temp-text
(setText (str " "))) (dosync (ref-set perm1 c)) (dosync (ref-set gool
c)) )
(. one-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str   @gool "1")
(. two-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str  @gool "2")
(. three-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str  @gool "3")
(. four-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str @gool "4")
(. five-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str  @gool "5")
(. six-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str  @gool "6")
(. seven-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str @gool "7")
(. eight-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str @gool "8")
(. nine-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(. temp-text
(setText (dosync (ref-set gool (str @gool "9")
(. zero-button
(addActionListener
(proxy [ActionListener] []
(actionPerformed [evt]
(if (empty? @gool)
(do
(. temp-text
(setText (dosync (ref-set gool (str "0"  @gool)))
(doto frame
(.setLayout (new GridLayout 4 2 3 3))
;; setting up the layout.
(.add temp-text)
(.add one-button)
(.add two-button)
(.add three-button)
(.add four-button)
(.add five-button)
(.add six-button)
(.add seven-button)
(.add eight-button)
(.add nine-button)
(.add zero-button)
(.add plus-button)
(.add divide-button)
(.add minus-button)
(.add calculate-button)
(.add clear-button)
(.setSize 250 300)
(.setVisible true
(twocents)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Inheritance & multiple inheritance using structs

[Emeka]

Great job!

Emeka

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

Re: Yet another html templating library

[Christophe Grand]

lpetit a écrit :
> Hello,
>
> Is it somehow related to the way Wicket does templating  ?
>   
After looking at Wicket examples, I say no: Wicket requires the template 
author to add namespaced attributes or elements to the html code and 
Enlive doesn't try to provide a component system.
Enlive is conceptually closer to XSLT or jQuery.

Christophe



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

Re: Runtime exception when agent calls sort

[mbrodersen]

Thanks Steve. The code is called by another function that handles the
agent state so no it is not called directly. Here is the additional
code (it is a simple Newbie web server learning project):

Here is how the web server is run:

(ws-run 3000 wh-handler)

The web server:
===

(import '(java.io BufferedReader InputStreamReader PrintWriter))

;***;

(defn reader-make-from-socket [socket]
(BufferedReader. (InputStreamReader. (.getInputStream socket

;***;

(def lines-read-max 100)

(defn lines-read [reader lines]
(let [line (.readLine reader)]
(cond
(= line nil)
[]
(= line "") 
lines
(> (count lines) lines-read-max)lines
true
(lines-read reader (concat lines [line])

;***;

(defn http-line-to-arg [cmd line]
(let [key (first (re-seq #"\S+:" line))]
(let [value (apply str (drop (count key) line))]
(conj cmd {(apply str (drop-last key)) (apply str (drop 1
value))}

(defn http-line-to-url [line]
(let [[cmd url http] (re-seq #"\S+" line)]
{"Cmd" cmd "Url" url "Http" http}))

;***;

(defn cmd-make-from-http-lines2 [cmd lines]
(if (= (first lines) nil)
cmd
(cmd-make-from-http-lines2 (http-line-to-arg cmd (first lines))
(rest lines

(defn cmd-make-from-http-lines [lines]
(if (= (first lines) nil)
{}
(cmd-make-from-http-lines2 (http-line-to-url (first lines)) 
(rest
lines

(defn cmd-print [cmd]
(let [ks (sort (keys cmd))]
(println "Cmd:")
(doseq [k ks]
(println (format "  \"%s\" => \"%s\"" k (cmd k))

(defn cmd-read [socket]
(let [reader (reader-make-from-socket socket) lines (lines-read
reader []) cmd (cmd-make-from-http-lines lines)]
(cmd-print cmd)
(conj cmd {:socket socket})))

;***;

(defn ws-agent [agentCounter socket fn]
(let [cmd (cmd-read socket)]
(fn cmd)
(.close socket)
(+ agentCounter 1)))

(defn ws-accept [socket tasks fn]
(println (format "Server accepting (clients done %d)" (deref tasks)))
(let [client (.accept socket)]
(send-off tasks ws-agent client fn)))

(defn ws-run [port fn]
(let [socket (java.net.ServerSocket. port) tasks (agent 0)]
(dotimes [i 3] (ws-accept socket tasks fn))
(await tasks)
(println (format "Server done (%d clients)" (deref tasks)))
(.close socket)))

The web handler


(load-file "Web Server.clj")

;***;

(defn http-write-ok [out]
(.write out "HTTP/1.1 200 OK\r\n\r\n"))

;***;

(defn html-write-head [out]
(.write out ""))

(defn html-write-tail [out]
(.write out ""))

; THIS IS WHERE IT GOES WRONG IF I CHANGE (keys cmd) to (sort (keys
cmd)):

(defn html-write-cmd [out cmd]
(doseq [key (keys cmd)]
(.write out
(format "\"%s\" => \"%s\"" key (cmd key)

(defn html-write-test [out cmd]
(http-write-ok out)
(html-write-head out)
(.write out "Hello from Clojure!")
(.write out (str "" (System/currentTimeMillis) ""))
(html-write-cmd out cmd)
(html-write-tail out))

;***;

(defn wh-make-writer [socket]
(PrintWriter. (.getOutputStream socket)))

(defn wh-write-test [cmd]
(let [out (wh-make-writer (cmd :socket))]
(html-write-test out cmd)
(.flush out)))

;***;

(defn wh-handler [cmd]
(wh-write-test cmd))

;***;

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

Re: How to make function that derefs vars and refs?

[Chouser]

On Mon, Jan 19, 2009 at 4:07 AM, Anand Patil
 wrote:
>
> Sorry, I was not being clear. Why not just let (deref 5) return 5? I
> would consider that syntactic sugar, as it would make it easier to
> deref a mixed vector of refs, constants, agents and atoms without
> keeping track of which indices correspond to (ref, agent, atom)s and
> which to constants.

You can do this yourself quite easily:

(defn my-deref [x] (if (instance? clojure.lang.IRef x) @x x))

(my-deref 5)  ==> 5
(my-deref (var filter))  ==> #
(my-deref filter)  ==> #
(my-deref (agent 99))  ==> 99

I don't know if the builtin 'deref' should do this -- it seems like it
might make things more confusing rather then less.

--Chouser

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

Re: Yet another html templating library

[lpetit]

Ok, thanks for the precision. It's always very bad when I make false
comparisons .. very difficult to get rid of them.

Merci Christophe, A bientôt,

--
Laurent

On 19 jan, 13:53, Christophe Grand  wrote:
> lpetit a écrit :> Hello,
>
> > Is it somehow related to the way Wicket does templating  ?
>
> After looking at Wicket examples, I say no: Wicket requires the template
> author to add namespaced attributes or elements to the html code and
> Enlive doesn't try to provide a component system.
> Enlive is conceptually closer to XSLT or jQuery.
>
> Christophe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

function equivalents of macro characters

[Mark Volkmann]

Many macro characters and reader forms have equivalent functions.
For example, (set ...) is the same as #{...} and (quote form) is the
same as 'form.

What are the equivalent functions, if any, for these?

\ - character literal
#"..." - regular expression - re-pattern?
#^ - metadata
#' - var-quote
 ` - syntax quote
~@ - unquote splicing

-- 
R. Mark Volkmann
Object Computing, Inc.

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

Re: JScrollPane + JTextPane trouble.

[MikeM]

This might be helpful:

http://os-lists.sun.com/thread.jspa?messageID=457986
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: How to make function that derefs vars and refs?

[Anand Patil]

On Jan 19, 1:25 pm, Chouser  wrote:
> On Mon, Jan 19, 2009 at 4:07 AM, Anand Patil
>
>  wrote:
>
> > Sorry, I was not being clear. Why not just let (deref 5) return 5? I
> > would consider that syntactic sugar, as it would make it easier to
> > deref a mixed vector of refs, constants, agents and atoms without
> > keeping track of which indices correspond to (ref, agent, atom)s and
> > which to constants.
>
> You can do this yourself quite easily:
>
> (defn my-deref [x] (if (instance? clojure.lang.IRef x) @x x))
>
> (my-deref 5)  ==> 5
> (my-deref (var filter))  ==> # clojure.core$filter__3...@1e1be92>
> (my-deref filter)  ==> #
> (my-deref (agent 99))  ==> 99
>
> I don't know if the builtin 'deref' should do this -- it seems like it
> might make things more confusing rather then less.
>
> --Chouser

Thanks Chouser, I'll take your word for it & use a specialized
function.

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

Another socket repl

[Craig McDaniel]

In case this is of use to anybody else, I thought I'd share my version
of a socket REPL: http://clojure.googlegroups.com/web/socket-repl.clj

Unlike the socket repl on the Wiki Example page, it does the
following:

- uses the repl from clojure.main
- keeps track of connections, closing the sockets when they go away
- redirects exception messages (*err*) to the socket stream
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Another socket repl

[Stephen C. Gilardi]

On Jan 19, 2009, at 9:38 AM, Craig McDaniel wrote:


In case this is of use to anybody else, I thought I'd share my version
of a socket REPL: http://clojure.googlegroups.com/web/socket-repl.clj

Unlike the socket repl on the Wiki Example page, it does the
following:

- uses the repl from clojure.main
- keeps track of connections, closing the sockets when they go away
- redirects exception messages (*err*) to the socket stream


That looks really nice, Craig. I see you're a registered contributor.  
Would you be up for including this in clojure-contrib? If so, and if  
we hear no objection here, could you please put on the appropriate EPL  
license header and your copyright notice (see other contribs for  
examples) and I'll be happy to check it in.


--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: Another socket repl

[Craig McDaniel]

Correction: http://clojure.googlegroups.com/web/socket-repl+(2).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
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: Another socket repl

[Craig McDaniel]

On Jan 19, 9:55 am, "Stephen C. Gilardi"  wrote:

> Would you be up for including this in clojure-contrib? If so, and if  
> we hear no objection here, could you please put on the appropriate EPL  
> license header and your copyright notice (see other contribs for  
> examples) and I'll be happy to check it in.
>

Sure, I posted an updated version that includes the EPL license
header: http://clojure.googlegroups.com/web/socket-repl.clj

Thanks,
Craig

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

Re: Another socket repl

[Craig McDaniel]

Well, somehow that link points to an old version. I guess the delete
and rename functions in Google groups do some strange things. Just
look for the file in the Files section.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Another socket repl

[Rich Hickey]

On Jan 19, 9:55 am, "Stephen C. Gilardi"  wrote:
> On Jan 19, 2009, at 9:38 AM, Craig McDaniel wrote:
>
> > In case this is of use to anybody else, I thought I'd share my version
> > of a socket REPL:http://clojure.googlegroups.com/web/socket-repl.clj
>
> > Unlike the socket repl on the Wiki Example page, it does the
> > following:
>
> > - uses the repl from clojure.main
> > - keeps track of connections, closing the sockets when they go away
> > - redirects exception messages (*err*) to the socket stream
>
> That looks really nice, Craig. I see you're a registered contributor.
> Would you be up for including this in clojure-contrib? If so, and if
> we hear no objection here, could you please put on the appropriate EPL
> license header and your copyright notice (see other contribs for
> examples) and I'll be happy to check it in.
>

It's very important to follow the protocol that patches only come from
registered contributors and are posted *by them* as patches through
the issue system. Only in that way is their contribution recorded.

Thanks,

Rich

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

Re: A couple of questions concerning syntax-quote

[David Nolen]

The multiple syntax-quote and unqote behavior above seems to work in Clojure
just fine and like CL as well.

On Mon, Jan 19, 2009 at 5:58 AM, Rock  wrote:

>
> I'm trying to make the documentation (still awaiting approval) in the
> "Learning Clojure" WikiBook regarding syntax-quote expansion as
> accurate as possible (like in the CL HyperSpec).
>
> I've recently noticed something. In "The Reader" section of the
> Clojure Reference, where it explains syntax-quotes, it says:
>
> "For all forms other than Symbols, Lists, Vectors and Maps, `x is the
> same as 'x."
>
> Yet, I noticed that for *values* such as numbers, strings etc...
> that's not exactly so. Let's expand a syntax-quote expression like the
> following:
>
> `(x 5) ===> (clojure.core/concat (clojure.core/list (quote user/x))
> (clojure.core/list 5))
>
> See the difference between what happens to the symbol x ===> (quote
> user/x) and what happens to 5?
>
> It looks like `5 gets expanded to 5 and not (quote 5). Now I know that
> they evaluate to the same identical thing. But what I'm interested in,
> is the precise expansion algorithm.
>
> So my first question is:
>
> 1) Is it true that, for values, we have for instance `5 ===> 5 in a
> syntax-quote expansion (not evaluation!).
>
> There's another thing I'm curious about. Syntax-quotes are there to
> simplify such things as wiriting macros (especially) for us. Now I'm
> trying to be rigorous in the docs so that everything is clear. But the
> whole reason for syntax-quotes is to make life easier, so there's no
> point in someone having to mentally expand those expressions every
> time even if he/she knows the precise rules.
>
> Paul Graham discusses this in Ansi Common Lisp. He also illustrates
> there an equivalent way of expanding backquote expressions which is
> truly useful and possibly less confusing for a human mind especially
> when dealing with notoriously difficult nested backquotes (or syntax-
> quotes in our own terminology :-) ). I think it was taken from Scheme,
> but I'm not certain. Anyway it's pretty simple and straightforward. It
> works like this:
>
> "To evaluate a backquoted expression, you remove the backquote
> and each matching comma, and replace the expression following each
> matching
> comma with its value. Evaluating an expression that begins with a
> comma causes an
> error.
>A comma matches a backquote if there are the same number of commas
> as
> backquotes between them, where b is between a and c if a is prepended
> to an expression
> containing b, and b is prepended to an expression containing c. This
> means that in a
> well-formed expression the outermost backquote matches the innermost
> comma(s).
>Suppose that x evaluates to a, which evaluates to 1; and that y
> evaluates to b,
> which evaluates to 2. To evaluate the expression
>
> ``(w ,x ,,y )
>
> we remove the first backquote and evaluate what follows any matching
> comma. The
> rightmost comma is the only one that matches the first backquote. If
> we remove it and
> replace the expression it's prepended to, y, with its value, we get:
>
> `(w ,x ,b)
>
> and if we evaluate that in turn we get:
>
> (w a 2)"
>
> That's Common Lisp notation so mentally replace commas with ~. It took
> me some getting used too! :-)
>
> Now my other question is this:
>
> 2) Given that in Clojure a syntax-quote (`) doesn't just quote a
> *symbol* but *resolves* it in the current context, would the above
> method still be applicable or is it compromised because of this?
> That's something that isn't clear to me yet.
>
> Thanks.
>
> Rock
>
> >
>

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

Re: Another socket repl

[Stephen C. Gilardi]

On Jan 19, 2009, at 10:45 AM, Rich Hickey wrote:


It's very important to follow the protocol that patches only come from
registered contributors and are posted *by them* as patches through
the issue system. Only in that way is their contribution recorded.


So to get Craig's socket-repl.clj into clojure-contrib, is this one  
correct route?


	[1] Craig opens an issue requesting socket-repl.clj be made a part of  
clojure-contrib

[2] Craig attaches his file to the issue
[3] Someone decides that it's an appropriate thing for clojure-contrib
[4] Someone checks it into clojure-contrib
[5] Someone closes the issue

For steps 3, 4, and 5, could you please tell me which individuals or  
groups are able to accomplish each task?


Thanks,

--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: is it type hint?

[Michael Reid]

On Fri, Jan 16, 2009 at 9:57 PM, David Nolen  wrote:
> Just made sense to me today as well.
> #^Class
> is short form for saying set the metadata for the symbol being defined (in
> this case list) to the map {:tag Class}.
> #^ is a reader macro for setting metadata for the compiler.  That code is
> simple tagging the symbol clojure/list.
> (meta #'list)
> will give you the map representing the metadata.  :tag is used by the
> compiler, but it's not clear to me in what cases...
>

The most common case where :tag is used by the compiler is to generate
direct method calls into Java code rather than using reflection to do
the call, which is much slower, e.g:

(defn index-of [s substr]
  (.indexOf s substr))

The call to String.indexOf will likely be compiled as a reflective
call because in the general case, the compiler doesn't know that 's'
and 'substr' are meant to be instances of java.lang.String. If however
you add a couple of type hints:

 (defn index-of [#^String s #^String substr]
   (.indexOf s substr))

Then the compiler will generate an optimized code path that directly
invokes String.indexOf(String,String), and the other which will fall
back to the reflective invocation. The reason that two code paths are
needed is because Clojure is dynamically typed. Therefore it is
perfectly legal to pass in any type of objects as the parameter in
which case you want the call to .indexOf to succeed if the passed in
instance does in fact have a method named indexOf that can accept
'substr' as its argument.

To see where the compiler needs to help you can use the
*warn-on-reflection* flag to ask for warnings where the compiler can't
resolve the calls. See:

 http://clojure.org/java_interop#toc35

for example usage.

/mike.

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

Re: is it type hint?

[David Nolen]

Thanks much.

On Mon, Jan 19, 2009 at 11:03 AM, Michael Reid  wrote:

>
> On Fri, Jan 16, 2009 at 9:57 PM, David Nolen 
> wrote:
> > Just made sense to me today as well.
> > #^Class
> > is short form for saying set the metadata for the symbol being defined
> (in
> > this case list) to the map {:tag Class}.
> > #^ is a reader macro for setting metadata for the compiler.  That code is
> > simple tagging the symbol clojure/list.
> > (meta #'list)
> > will give you the map representing the metadata.  :tag is used by the
> > compiler, but it's not clear to me in what cases...
> >
>
> The most common case where :tag is used by the compiler is to generate
> direct method calls into Java code rather than using reflection to do
> the call, which is much slower, e.g:
>
> (defn index-of [s substr]
>  (.indexOf s substr))
>
> The call to String.indexOf will likely be compiled as a reflective
> call because in the general case, the compiler doesn't know that 's'
> and 'substr' are meant to be instances of java.lang.String. If however
> you add a couple of type hints:
>
>  (defn index-of [#^String s #^String substr]
>   (.indexOf s substr))
>
> Then the compiler will generate an optimized code path that directly
> invokes String.indexOf(String,String), and the other which will fall
> back to the reflective invocation. The reason that two code paths are
> needed is because Clojure is dynamically typed. Therefore it is
> perfectly legal to pass in any type of objects as the parameter in
> which case you want the call to .indexOf to succeed if the passed in
> instance does in fact have a method named indexOf that can accept
> 'substr' as its argument.
>
> To see where the compiler needs to help you can use the
> *warn-on-reflection* flag to ask for warnings where the compiler can't
> resolve the calls. See:
>
>  http://clojure.org/java_interop#toc35
>
> for example usage.
>
> /mike.
>
> >
>

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

Re: Another socket repl

[Craig McDaniel]

I am a registered contributor...even though I haven't contributed
anything so far. I opened an issue on clojure-contrib and attached the
file. Let me know if that is not the correct procedure.

-Craig

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

Re: A couple of questions concerning syntax-quote

[Rock]

On Jan 19, 4:57 pm, David Nolen  wrote:
> The multiple syntax-quote and unqote behavior above seems to work in Clojure
> just fine and like CL as well.

Thanks. That's what I'm hoping for. The technique Graham illustrates
in ACL is very helpful. Its value is in the fact that it makes is
simpler for a human being to see what's going on in a nested
backquote.

The algorithms employed by Clojure and Common Lisp, though surely
effective, are less intuitive. They literally translate the syntax-
quote expression in what one would have to write in order to get the
same result by using concat, list, and quote. But that's precisely
what we're trying to avoid in the first place!

So I'm very happy to write down in the WikiBook how Clojure expands
syntax-quotes precisely, but I'm also concerned about having other
valid, more human-comprehensible alternative ways of achieving an
equivalent result.

As far as CL goes, there's no standard way of doing it. The HyperSpec
only suggests one which is to be used as a sort of reference (very
similar to what we have in Clojure by the way, where it is THE
standard procedure of course :-) ). The one Graham illustrates is
equivalent. I believe SBCL adopts something along those lines
actually. Anyway I think it's much easier to *see* what's going on
with the latter.

Rock.

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

Re: Another socket repl

[Rich Hickey]

On Jan 19, 2009, at 10:59 AM, Stephen C. Gilardi wrote:

>
> On Jan 19, 2009, at 10:45 AM, Rich Hickey wrote:
>
>> It's very important to follow the protocol that patches only come  
>> from
>> registered contributors and are posted *by them* as patches through
>> the issue system. Only in that way is their contribution recorded.
>
> So to get Craig's socket-repl.clj into clojure-contrib, is this one  
> correct route?
>
>   [1] Craig opens an issue requesting socket-repl.clj be made a part  
> of clojure-contrib
>   [2] Craig attaches his file to the issue

Yup.

>   [3] Someone decides that it's an appropriate thing for clojure- 
> contrib
>   [4] Someone checks it into clojure-contrib
>   [5] Someone closes the issue
>
> For steps 3, 4, and 5, could you please tell me which individuals or  
> groups are able to accomplish each task?
>

As long as they've verified Craig is on this list (he is):

http://clojure.org/contributing

then any member of clojure-contrib can do 3,4,5

Thanks,

Rich


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

Re: Another socket repl

[Phil Hagelberg]

"Stephen C. Gilardi"  writes:

> That looks really nice, Craig. I see you're a registered
> contributor. Would you be up for including this in clojure-contrib?

I noticed that very little of this code is specific to the REPL; the
bulk of it is just dealing with creating and doing things with server
sockets. Perhaps it could be included in clojure-contrib as a
generalized server-sockets library if instead of calling (repl) it could
take an optional argument for a different function to use?

(I say this as someone who just yesterday was adapting the old
socket-repl code from the wiki for a different non-repl purpose.)

-Phil

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

[Chouser]

On Sat, Jan 17, 2009 at 8:03 PM, pc  wrote:
>
> This is very useful. For me it was useful to be able to limit the
> output to lines that contained a few selected letters.
>
> (show String "pper")
> ===  public final java.lang.String  ===
> [82] toUpperCase : String ()
> [83] toUpperCase : String (Locale)
> nil

This is a good idea, thanks.  I've got a version here that allows
a full regex match, and is by default case-insensitive.  I think both
these are good.

But my version also only allows matches on the method name (not on
return value or argument class names).  At first I thought this was
also good, but now I'm less sure.  How often do you think you'd want
to be able to search on a method's argument names, vs. how many
unhelpful matches you'd get doing (show String "string") ?  Opintions?

--Chouser

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

Re: repl-utils show

[Michael Reid]

On Mon, Jan 19, 2009 at 11:59 AM, Chouser  wrote:
>
> On Sat, Jan 17, 2009 at 8:03 PM, pc  wrote:
>>
>> This is very useful. For me it was useful to be able to limit the
>> output to lines that contained a few selected letters.
>>
>> (show String "pper")
>> ===  public final java.lang.String  ===
>> [82] toUpperCase : String ()
>> [83] toUpperCase : String (Locale)
>> nil
>
> This is a good idea, thanks.  I've got a version here that allows
> a full regex match, and is by default case-insensitive.  I think both
> these are good.
>
> But my version also only allows matches on the method name (not on
> return value or argument class names).  At first I thought this was
> also good, but now I'm less sure.  How often do you think you'd want
> to be able to search on a method's argument names, vs. how many
> unhelpful matches you'd get doing (show String "string") ?  Opintions?
>
> --Chouser
>

My feeling is that you'd want to search on arguments infrequently
enough compared to searching on method name that its worth defaulting
to only search on the method name.

For the case where you might want to search on method names maybe we
could look at some sort of composable approach. I'm thinking along the
lines of the Unix pipeline approach. Extremely rough pseudo-code of
what I'm getting at:

(-> (show String "case") (grep "locale"))

to find the methods containing the regexp 'case' and then further
constraining that to those entries that match the regexp 'locale'.
I've also assumed case insensitivity here as I think that makes sense
in this context.

Then again maybe this is a classic case of overdesign.

Perhaps it is easier in the short term to just be pragmatic and create
an overload for show that accepts a third argument to search on
argument/return  names and types:

(show String "case" "locale")

or:

(show String "*" "locale")

for all methods dealing with arguments or return types of locale or
arguments named locale.

/mike.

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

Re: function equivalents of macro characters

[Chouser]

On Mon, Jan 19, 2009 at 9:10 AM, Mark Volkmann
 wrote:
>
> What are the equivalent functions, if any, for these?
>
> \ - character literal

I came up with a couple options:
((into {} (map (comp vec reverse) char-name-string)) "newline")
(read-string "\\newline")

> #"..." - regular expression - re-pattern?

're-pattern' is correct, but remember that literal strings have
different quoting rules than literal regex.

> #^ - metadata

#^ adds metadata at read-time, so there's no way for a function to do
exactly the same thing, though 'with-meta' does something similar at
runtime.

> #' - var-quote

'var'
That is, (var ensure) is the same as #'ensure

>  ` - syntax quote
> ~@ - unquote splicing

Those and ~ as well translate to a complex set of clojure
data-structure-building functions, all of which are available as
functions.  These include 'list', 'cons', 'concat', etc.

--Chouser

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

Re: is it type hint?

[Chouser]

On Mon, Jan 19, 2009 at 11:03 AM, Michael Reid  wrote:
>
>  (defn index-of [#^String s #^String substr]
>   (.indexOf s substr))
>
> Then the compiler will generate an optimized code path that directly
> invokes String.indexOf(String,String), and the other which will fall
> back to the reflective invocation. The reason that two code paths are
> needed is because Clojure is dynamically typed.

When sufficient hints are provided for the compiler to find exactly
one matching function, only one path is produced.

(defn get-first-char [#^String s]
  (let [buf (make-array Character/TYPE 1)]
(.getChars s 0 1 buf 0) (first buf)))

Calling this with a String works fine:
user=> (get-first-char "foo")
\f

But using a StringBuffer, causes an exception:
user=> (get-first-char (StringBuffer. "foo"))
java.lang.ClassCastException: java.lang.StringBuffer cannot be cast to
java.lang.String (NO_SOURCE_FILE:0)

If you remove the #^String type hint, you'll see that both String and
StringBuffer work fine.

--Chouser

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

Re: fit for contribution to clojure.contrib.ns-utils?

[Michael Reid]

On Sat, Jan 17, 2009 at 8:25 PM, Dan Larkin  wrote:
>
>
> On Jan 17, 2009, at 6:29 PM, Stephen C. Gilardi wrote:
>>
>> Hi Dan,
>>
>> That's interesting. I've given it some thought and I've come to see
>> it as a version of resolve that tries harder than the default.
>> Here's an implementation that makes its capabilities purely a
>> superset of those of resolve. This version works well even with
>> definitions that don't come from libs like those in clojure.core:
>>
>> (defn resolve*
>>  [sym]
>>  (let [ns (namespace sym)
>>name (name sym)
>>ns (if ns (symbol ns) (ns-name *ns*))
>>name (symbol name)]
>>(or (and (find-ns ns) (ns-resolve ns name))
>>(do
>>  (require ns)
>>  (ns-resolve ns name)
>>
>> This version takes a symbol just like resolve does. It doesn't
>> support passing in a string. I think any string to symbol
>> transformation is easy one for a caller to make if it needs to. I
>> had an interim version that supported separating the namespace and
>> name into two arguments, but that would be more like ns-resolve* and
>> resolve* is every bit as capable.
>
> Hi Stephen,
>
> Yes, you're right, this does make sense as a superset of clojure.core/
> resolve -- also resolve* is a name that fits much better.
>
>>
>>
>> I'm interested in hearing any thoughts you may have on this version
>> as it relates to the problem you're trying to solve. I like that in
>> Clojure we now have a canonical way to load in a namespace
>> definition: require. This idea of yours leverages that. Together
>> with that, we also have a canonical way for one namespace to declare
>> and satisfy its dependence on another: (ns (:require...)). Given
>> those two facilities, I wonder what use case you envision for
>> require-resolve (or resolve*). Is this intended to be used at the
>> repl? Does it offer a compelling advantage for some kind of work
>> over calling require directly and then letting the default symbol
>> resolution mechanism do the work?
>
> I like how you phrase that.  Yes, you're correct, for dependencies you
> can identify at coding time (ns (:require ..)) works just fine, but
> for runtime-introduced dependencies a (require ...) is necessary.
>
> My first use case is a "settings file".  The settings file (clojure
> code itself) defines a bunch of settings (duh) which include
> middleware functions, "template loader" functions (and more to come
> for sure).  So without resolve* there are two options:
>
> 1) Import all of the functions to which I need to refer and then
> identify them directly.
> 2) Give a two-tuple with namespace and var symbols, which can
> then be (require ..) and (ns-resolve ..)'d later on.
>
> So basically option #1 sucks and #2 is just a more verbose version of
> using resolve*.
>
>
> My second use case is an url-dispatching system.  It's a port (mostly
> -- java's regex doesn't have named groups and clojure doesn't have
> keyword arguments) of django's url dispatching system.  Basically you
> define a list of regexes and which function you want to be called when
> the url matches that regex.
>
> So it's the same conundrum as with the settings file, really.  Either
> I can require all of the functions I want to call or give two-tuples
> of namespace and var -- or use require*
>
>
>>
>>
>>> Stephen, if you think this is something suitable for
>>> clojure.contrib.ns-utils then I'll submit my CA to Rich and you can
>>> pull it in, otherwise it's here for anyone to use.
>>
>> I think it's interesting experimental code. Please do send in a CA
>> and let's get something like this into ns-utils.
>>
>> --Steve
>>

Forgive me I am probably missing something, but if your use case is in
a configuration file, why can't you just to a regular (ns .. (:require
..)) so that your configuration file can declare its dependencies in
the same way other code does?

But I also wanted to add that this could be a very useful function for
an IDE/tools to use.

I'm thinking of the case where the user is editing code and wants to
examine a reference to a var in their source file. This enhanced
"resolve*" could be called to load and resolve the reference and then
the IDE/tool can do whatever it might do for the result--examine it
for a docstring, or load up an inspector or whatever.

/mike

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

Re: is it type hint?

[Michael Reid]

On Mon, Jan 19, 2009 at 12:34 PM, Chouser  wrote:
>
> On Mon, Jan 19, 2009 at 11:03 AM, Michael Reid  wrote:
>>
>>  (defn index-of [#^String s #^String substr]
>>   (.indexOf s substr))
>>
>> Then the compiler will generate an optimized code path that directly
>> invokes String.indexOf(String,String), and the other which will fall
>> back to the reflective invocation. The reason that two code paths are
>> needed is because Clojure is dynamically typed.
>
> When sufficient hints are provided for the compiler to find exactly
> one matching function, only one path is produced.
>
> (defn get-first-char [#^String s]
>  (let [buf (make-array Character/TYPE 1)]
>(.getChars s 0 1 buf 0) (first buf)))
>
> Calling this with a String works fine:
> user=> (get-first-char "foo")
> \f
>
> But using a StringBuffer, causes an exception:
> user=> (get-first-char (StringBuffer. "foo"))
> java.lang.ClassCastException: java.lang.StringBuffer cannot be cast to
> java.lang.String (NO_SOURCE_FILE:0)
>
> If you remove the #^String type hint, you'll see that both String and
> StringBuffer work fine.
>
> --Chouser

Interesting, I did not know this. But this seems to remove some
flexibility in allowing for "duck" typing.

For example, this prevents me from writing a class that implements a
method with a signature identical to
String.getChars(int,int,char[],int) and substituting that for argument
to get-first-char. Of course I could remove the type hint to allow
such a scenario but then I lose the direct invocation for the case
when I pass in a String.

I thought this would be allowed. Thanks for the clarification.

/mike.

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

Re: how to know which version of clojure?

[Nathan Kitchen]

On Jan 18, 11:48 am, wubbie  wrote:
> Hi,
> Just tried a piece of code from here...
> (defn my-deref [x]
>   (if (or (isa? clojure.lang.Ref (class x))
>           (isa? clojure.lang.Agent (class x))
>           (isa? clojure.lang.Atom (class x)))
>     @x
>     x))
> java.lang.ClassNotFoundException: clojure.lang.Atom (NO_SOURCE_FILE:
> 22)
>
> But I think I used atom before and working...
> If my version is older I may have to download newer one.
> I think I downloaded about a month ago.

Atoms used to be implemented using
java.util.concurrent.AtomicReference before the clojure.lang.Atom
class was created. If you don't have the file Atom.java in clojure/src/
jvm/clojure/lang, you can try using the old class name in the
definition of my-deref. Personally, I think it would be better to
update to a newer version of clojure because you'll get bug fixes and
other recent improvements.

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

Re: repl-utils show

[Stuart Sierra]

On Jan 19, 11:59 am, Chouser  wrote:
> But my version also only allows matches on the method name (not on
> return value or argument class names).  At first I thought this was
> also good, but now I'm less sure.  How often do you think you'd want
> to be able to search on a method's argument names, vs. how many
> unhelpful matches you'd get doing (show String "string") ?  Opintions?

 Would it be possible to separate "show" into two functions, one of
which returns a sequence of method signatures and another which prints
them?  Then you could filter the sequence however you like.

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

#^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

On Mon, Jan 19, 2009 at 12:24 PM, Chouser  wrote:

> > #^ - metadata
>
> #^ adds metadata at read-time, so there's no way for a function to do
> exactly the same thing, though 'with-meta' does something similar at
> runtime.
>

I've noticed this as well.  It seems to me that this prevents you from
dynamically defining a var (like in a macro) that has metadata attached to
it or it's arguments (if it's a function).  Is there no way around how the
reader works?  Can the reader delay processing #^ until after all macros
have been expanded?  Seems to me it could be useful behavior since one might
want to dynamically create functions with tagged arguments and return values
right?

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

Re: Yet another html templating library

[Stuart Sierra]

 Very interesting, Christophe. I've been playing with StringTemplate
 lately, but this separates design
from code even further. Can it do conditionals, as in "if this
variable is true, includes this HTML element"?

-Stuart Sierra


On Jan 19, 5:34 am, Christophe Grand  wrote:
> Hello group!
>
> Enlive (http://github.com/cgrand/enlive/tree/master) is a selector based
> templating library.
> The main design goal was to decouple html and presentation code, that's
> why enlive templates are plain old html files (it will ease
> roundtripping with designers).
> In code, you have to declare where and how to alter the html template
> using CSS-like selectors.
> The resulting templatings functions are compiled (the html tree isn't
> transformed at runtime) and yields a seq of strings.
>
> Here is an 
> example:http://github.com/cgrand/enlive/blob/2a15c466048f7e0311243b3d7a669705...
>
> (Disclaimer: original idea by 
> Ozzilee,http://clojure-log.n01se.net/date/2008-05-30.html#09:19)
>
> Christophe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: post on test-is and testing styles

[Luke Amdor]

Thanks Stuart for the with-test macro. It will make my life much
easier. I have been putting my tests in the :test metadata and running
them with (run-tests). The with-tests macro will make it much more
readable. I was also having problems with old test metadata hanging
around.

I am all in favor of putting the tests right next to the function
being tested. The anti-"side effect" nature of Clojure promotes this
in fact. If I can have a test suite ran upon loading with no required
assistance from the caller, that would be great.

I also think that if your test needs a description of what it's doing,
then that's a smell. It's an excuse for easily readable code and I
think we can all agree that we should try to make our code as easily
readable as possible.

Luke

On Jan 18, 3:03 pm, James Reeves  wrote:
> On Jan 18, 4:24 pm, Stuart Sierra  wrote:
>
> > After thinking a while about the discussion about test-is  > groups.google.com/group/clojure/browse_thread/thread/59e9cebbe67cab3f/
> > 508f1e8de753455c>, here's a short article with my current thoughts:
>
> >http://stuartsierra.com/2009/01/18/tests-are-code
>
> > Comments welcome here or on the blog.
>
> I've written an RSpec-like testing framework in Clojure, so I have a
> few opinions on this.
>
> 1. I don't like the idea of putting tests next to the functions
> they're testing. There's an argument that says tests make good
> documentation, but I'm of the opinion that tests are too repetitive to
> be effective in that capacity. A good piece of documentation will
> provide several common examples; a thorough test will go through
> dozens of edge-conditions. So if tests aren't documentation, putting
> them next to the functions they test just clutters up the source code
> with unnecessary information.
>
> 2. Test should come with a description of what scenario they are
> testing, so I favour the RSpec approach of using short descriptive
> strings to identify tests, rather than symbols.
>
> 3. The biggest problem I've had with tests is generating test data. I
> like the Quickcheck approach of generating lists of random values
> (because it's easy for me), but when trying to use that approach in my
> Fact testing framework I've found that really only works with a
> minority of problems. I haven't figured out a good solution for easily
> generating test data, but I think it's one of the most important
> problems for a unit testing framework to overcome.
>
> 4. I lean toward the idea that a test should contain a single
> predicate that's tested with numerous inputs. But again, I haven't
> figured out a way of doing this that works well in all situations :)
>
> - James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: is it type hint?

[Stuart Sierra]

On Jan 19, 12:47 pm, Michael Reid  wrote:
> Interesting, I did not know this. But this seems to remove some
> flexibility in allowing for "duck" typing.

Yes, that's a disadvantage with duck typing in most dynamic languages
-- types have to be resolved at run-time.  In the case of Java, that
means you have to accept reflection-based method calls.

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

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[Meikel Brandmeyer]

Hi,

Am 19.01.2009 um 19:15 schrieb David Nolen:
I've noticed this as well.  It seems to me that this prevents you  
from dynamically defining a var (like in a macro) that has metadata  
attached to it or it's arguments (if it's a function).  Is there no  
way around how the reader works?  Can the reader delay processing #^  
until after all macros have been expanded?  Seems to me it could be  
useful behavior since one might want to dynamically create functions  
with tagged arguments and return values right?


In a macro you can do:

1:20 user=> (defmacro foo [x] `(def ~(with-meta x (assoc (meta  
x) :foo :bar

nil
1:21 user=> (foo #^{:some :metadata} bar)
#'user/bar
1:22 user=> (meta #'bar)
{:ns #, :name bar, :file "repl-1", :line  
21, :foo :bar, :some :metadata}


Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature

Re: post on test-is and testing styles

[Stuart Sierra]

Hi James,

On Jan 18, 4:03 pm, James Reeves  wrote:
> 1. I don't like the idea of putting tests next to the functions
> they're testing.

That's cool with me, I won't force you to do it one way or the other.

> 2. Test should come with a description of what scenario they are
> testing, so I favour the RSpec approach of using short descriptive
> strings to identify tests, rather than symbols.

I figure you can use symbols and still make your test names as
descriptive as you like. I did this in the tests for the library
itself, like this:

(deftest can-test-=
  (is (= 2 (+ 1 1)) "Should pass")
  (is (= 3 (+ 2 2)) "Should fail"))

I think that's how the earliest implementations of behavior-driven
development in Java worked -- they used descriptive method names.
Sure, it's not as pretty, but it works.  I also added the "testing"
macro for adding descriptive strings to tests.  These can be nested,
as in RSpec:

(deftest arithmetic
  (testing "Addition"
   (testing "with integers"
(= 2 (+ 1 1))
(= 4 (+ 2 2)))
   (testing "with floats"
(= 2.5 (+ 1.0 1.5)

This can replace the "test-that" macro that J. McConnell wrote in
clojure/contrib/test_clojure/evaluation.clj.  The top-level test name
still has to be a symbol so it can be bound to a Var.

> 3. The biggest problem I've had with tests is generating test data.

Can't help you there, it least not right now. I'm open to suggestions.

> 4. I lean toward the idea that a test should contain a single
> predicate that's tested with numerous inputs.

I've attempted to allow for this with the "are" macro, which takes a
template expression and applies it to a collection of values. The
interface is a little tricky though, so I'm not sure if I should keep
it or not:

(deftest test-my-predicate
  (are (my-predicate _1 _2)
   ... all your test values ...))

The alternative is to use a simple loop:

(deftest test-my-predicate
  (let [my-predicate (fn [x y] (is ...whatever...))]
(doseq [[x y] [ ...all your test values ...]]
  (my-predicate x y

Peace, and happy testing.
-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: post on test-is and testing styles

[Stuart Sierra]

Thanks for the comments, Luke, glad we're thinking along the same
lines!
-Stuart Sierra

On Jan 19, 1:24 pm, Luke Amdor  wrote:
> Thanks Stuart for the with-test macro. It will make my life much
> easier. I have been putting my tests in the :test metadata and running
> them with (run-tests). The with-tests macro will make it much more
> readable. I was also having problems with old test metadata hanging
> around.
>
> I am all in favor of putting the tests right next to the function
> being tested. The anti-"side effect" nature of Clojure promotes this
> in fact. If I can have a test suite ran upon loading with no required
> assistance from the caller, that would be great.
>
> I also think that if your test needs a description of what it's doing,
> then that's a smell. It's an excuse for easily readable code and I
> think we can all agree that we should try to make our code as easily
> readable as possible.
>
> Luke
>
> On Jan 18, 3:03 pm, James Reeves  wrote:
>
> > On Jan 18, 4:24 pm, Stuart Sierra  wrote:
>
> > > After thinking a while about the discussion about test-is  > > groups.google.com/group/clojure/browse_thread/thread/59e9cebbe67cab3f/
> > > 508f1e8de753455c>, here's a short article with my current thoughts:
>
> > >http://stuartsierra.com/2009/01/18/tests-are-code
>
> > > Comments welcome here or on the blog.
>
> > I've written an RSpec-like testing framework in Clojure, so I have a
> > few opinions on this.
>
> > 1. I don't like the idea of putting tests next to the functions
> > they're testing. There's an argument that says tests make good
> > documentation, but I'm of the opinion that tests are too repetitive to
> > be effective in that capacity. A good piece of documentation will
> > provide several common examples; a thorough test will go through
> > dozens of edge-conditions. So if tests aren't documentation, putting
> > them next to the functions they test just clutters up the source code
> > with unnecessary information.
>
> > 2. Test should come with a description of what scenario they are
> > testing, so I favour the RSpec approach of using short descriptive
> > strings to identify tests, rather than symbols.
>
> > 3. The biggest problem I've had with tests is generating test data. I
> > like the Quickcheck approach of generating lists of random values
> > (because it's easy for me), but when trying to use that approach in my
> > Fact testing framework I've found that really only works with a
> > minority of problems. I haven't figured out a good solution for easily
> > generating test data, but I think it's one of the most important
> > problems for a unit testing framework to overcome.
>
> > 4. I lean toward the idea that a test should contain a single
> > predicate that's tested with numerous inputs. But again, I haven't
> > figured out a way of doing this that works well in all situations :)
>
> > - James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: #^ Reader Macro Issues was Re: function equivalents of macro characters

[Stuart Sierra]

On Jan 19, 1:15 pm, David Nolen  wrote:
> I've noticed this as well.  It seems to me that this prevents you from
> dynamically defining a var (like in a macro) that has metadata attached to
> it or it's arguments (if it's a function).  

You can also use the new alter-meta! function, which works on
anything:

-
clojure.core/alter-meta!
([iref f & args])
  Atomically sets the metadata for a namespace/var/ref/agent/atom to
be:

  (apply f its-current-meta args)

  f must be free of side-effects


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

Re: post on test-is and testing styles

[Mark Engelberg]

Seems like is/are are somewhat gratuitous.  Why not leave them out
completely in a deftest, and get the syntax as minimalist as possible?

(deftest test-plus
  (= (+ 1 1) 2)
  (= (+ 2 3) 5))

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

Bug in (try (dosync ...) (finally (dosync ...)))?

[John D. Hume]

With the latest from svn, I'm seeing the following weird behavior.

(def r (ref :old))
(let [old-value @r]
  (try
(dosync (ref-set r :new))
(finally
  (dosync (ref-set r old-value))
  )))
(println "@r is" @r)

This prints "@r is nil" whereas I'd expect it to print "@r is :old".
But the following prints "@r is :old" as expected:

(def r (ref :old))
(let [old-value @r]
  (try
(dosync (ref-set r :new))
(finally
  old-value   ; This line is the only difference
  (dosync (ref-set r old-value))
  )))
(println "@r is" @r)

The only difference is the do-nothing expression old-value that
immediately follows the finally. Am I missing something or is this a
bug?

I realize this is a very weird thing to be doing. In the real world
you'd want to have one (dosync ...) block, but this is for a macro for
unit tests where I want to be able to restore the proper value of a
ref after a test has had a chance to mess it up.

Thanks.
-hume.

-- 
http://elhumidor.blogspot.com/

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

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Wow, nice!
On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
wrote:

>
> On Jan 19, 1:15 pm, David Nolen  wrote:
> > I've noticed this as well.  It seems to me that this prevents you from
> > dynamically defining a var (like in a macro) that has metadata attached
> to
> > it or it's arguments (if it's a function).
>
> You can also use the new alter-meta! function, which works on
> anything:
>
> -
> clojure.core/alter-meta!
> ([iref f & args])
>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
> be:
>
>  (apply f its-current-meta args)
>
>  f must be free of side-effects
>
>
> -Stuart Sierra
> >
>

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

Re: JScrollPane + JTextPane trouble.

[Christian Vest Hansen]

Excellent!

The getScrollableTracksViewportWidth() trick did it :)

On Mon, Jan 19, 2009 at 3:26 PM, MikeM  wrote:
>
> This might be helpful:
>
> http://os-lists.sun.com/thread.jspa?messageID=457986
> >
>



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

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

Re: post on test-is and testing styles

[John D. Hume]

On Mon, Jan 19, 2009 at 1:44 PM, Stuart Sierra
 wrote:
> I've attempted to allow for this with the "are" macro, which takes a
> template expression and applies it to a collection of values. The
> interface is a little tricky though, so I'm not sure if I should keep
> it or not:

Stuart,
For what it's worth, I'm a fan of the (are ...) macro. The examples
always seem to show something like
  (are (= _1 _2)
"a" (myfunc :a)
"b" (myfunc :b))
but I generally do something more like
  (are (= _1 (myfunc _2))
"a" :a
"b" :b)
which gives you a nicely DRY yet readable presentation of expected
results and their respective inputs.

Thanks.
-hume.

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

Re: Another socket repl

[Craig McDaniel]

On Jan 19, 11:45 am, Phil Hagelberg  wrote:
> I noticed that very little of this code is specific to the REPL; the
> bulk of it is just dealing with creating and doing things with server
> sockets. Perhaps it could be included in clojure-contrib as a
> generalized server-sockets library if instead of calling (repl) it could
> take an optional argument for a different function to use?

Thanks, that's a good point. I'm posting a new file server-socket.clj
that is more generic and includes the REPL as an example case.

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

Re: Yet another html templating library

[Christophe Grand]

Stuart Sierra a écrit :
>  Very interesting, Christophe. I've been playing with StringTemplate
>  lately, but this separates design
> from code even further. Can it do conditionals, as in "if this
> variable is true, includes this HTML element"
In the only example, I use 'when-not to conditionally display an element.

(deftemplate microblog-template "net/cgrand/enlive_html/example.html" 
[title posts]
  [:title] title
  [:h1] title
  [:div.no-msg] (when-not (seq posts) ~(html/show))
  [:div.post] (for [{:keys [title body]} posts]
   ~(at
  [:h2] title
  [:p] body)))

see:

net.cgrand.enlive-html.examples=> (apply str (microblog-template "Hello user!"
 [{:title "post #1"
   :body "hello with dangerous chars: <>&"}
  {:title "post #2"
   :body "dolor ipsum"}]))
/"Hello user!
Hello user!
post #1
hello with dangerous chars: <>&
post #2
dolor ipsum"

and:
/net.cgrand.enlive-html.examples=> (apply str (microblog-template "Hello 
Stuart!" []))

"Hello Stuart!Hello Stuart!
Sorry, I'm too lazy to post."


But I'm not sure that's what you are asking for. Do you mean something 
else?
(Right now there's no facility to use another element than the currently 
selected one but it's planned if that's what you are interested in.)

Christophe

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

Re: fit for contribution to clojure.contrib.ns-utils?

[Dan Larkin]

On Jan 19, 2009, at 12:39 PM, Michael Reid wrote:
>
> Forgive me I am probably missing something, but if your use case is in
> a configuration file, why can't you just to a regular (ns .. (:require
> ..)) so that your configuration file can declare its dependencies in
> the same way other code does?

Configurations can be loaded at runtime, in my system. Loading a  
configuration file updates a *settings* Atom (might change to a Var,  
actually).

Sure, the configuration file could (require ...) all the namespaces it  
needs, but isn't resolve* nicer? :)

Also, due to the late-binding nature of using resolve* I gain some  
performance benefits of not evaluating top-level forms in the required  
namespaces until they're actually needed.

>
>
> But I also wanted to add that this could be a very useful function for
> an IDE/tools to use.
>
> I'm thinking of the case where the user is editing code and wants to
> examine a reference to a var in their source file. This enhanced
> "resolve*" could be called to load and resolve the reference and then
> the IDE/tool can do whatever it might do for the result--examine it
> for a docstring, or load up an inspector or whatever.
>
> /mike
>
> >


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

Re: Mysterious performance anomalies

[Mark H.]

On Jan 18, 8:48 am, e  wrote:
> That's a great argument.  I need arguments like these.  I work with people
> who dismiss JVM.  Even though there are many non-Sun JVM's, folks say, "Sun
> is dead -> java is dead -> jvm is dead." . even though Java is the most
> popular language right 
> now.http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

A lot of people agree that having some kind of VM is very helpful.  It
may not necessarily be the JVM in the future, but right now the JVM is
popular enough that it's worth using it rather than relying on some
other VM that might also go away.  VMs provide portability, can do a
lot of low-level optimizations (that would otherwise have to go into
the compiler), and have useful services (like garbage collection) that
save folks like Rich a lot of trouble when implementing a new
language.

Saying we shouldn't use the JVM because Sun might go away is like
saying we shouldn't bother improving gas mileage in cars because
gasoline might go away.  (Of course it pays to think about the long
term, but shorter-term gains are worth the work.)

mfh



>
> I wonder if there will ever be a JM ... that is a chip that natively
> executes byte code.  I wonder what they'd have to say, then.  I think I'll
> do a Google search.  I also wonder if it was a tough decision for Rich to
> cut the CLI support.  I know he feels fine looking back.
>
> On Sun, Jan 18, 2009 at 12:23 AM, Mark H.  wrote:
>
> > On Jan 16, 6:47 am, e  wrote:
> > > Is it much much easier to make byte code than assembly code?
>
> > I'll chime in too to say that x86 is only king of the desktop / laptop
> > world -- many portable devices are ARM-based (and a lot of Windows
> > apps run on ARM), and there are other architectures used for
> > enterprise and HPC servers.  Plus it's not clear to me that x86 will
> > win, esp. in power-constrained arenas.  (All those legacy instructions
> > and the translation from x86 ops into reasonable microops eat power
> > and area.)  I've dealt with at least six different instruction sets in
> > my HPC work and the JVM runs on at least five of them:  instant
> > portability!
>
> > mfh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: post on test-is and testing styles

[.Bill Smith]

> 3. The biggest problem I've had with tests is generating test data. I
> like the Quickcheck approach of generating lists of random values
> (because it's easy for me), but when trying to use that approach in my
> Fact testing framework I've found that really only works with a
> minority of problems. I haven't figured out a good solution for easily
> generating test data, but I think it's one of the most important
> problems for a unit testing framework to overcome.

Would you mind elaborating on that point?  At a previous job, I worked
on a corporate banking application that had numerous configuration
settings.  Thousands of companies used the application.   It was
impractical to test the application with every possible configuration
vector (i.e. every combination of configuration settings), or even for
every set of configuration vectors that were actually in use.  It was
a challenge to decide which configuration vectors to test against.

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

Re: post on test-is and testing styles

[James Reeves]

On Jan 19, 6:24 pm, Luke Amdor  wrote:
> I also think that if your test needs a description of what it's doing,
> then that's a smell. It's an excuse for easily readable code and I
> think we can all agree that we should try to make our code as easily
> readable as possible.

The code can tell you what a test does, but not necessarily its
purpose. No matter how readable your code is, it can only tell you the
what and how, not the why. So my personal preference is pair a test up
with a description of it's purpose; the description is the theory, the
test code is the evidence that backs it up.

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

[James Reeves]

On Jan 19, 6:44 pm, Stuart Sierra  wrote:
> > 1. I don't like the idea of putting tests next to the functions
> > they're testing.
>
> That's cool with me, I won't force you to do it one way or the other.

And here I was ready to start a holy crusade against you ;)

Honestly, it's cool with me too. I just figured it was worth
mentioning an alternative viewpoint.

> I think that's how the earliest implementations of behavior-driven
> development in Java worked -- they used descriptive method names.
> Sure, it's not as pretty, but it works.

I like pretty enough that this matters to me, but to each their own.

> > 3. The biggest problem I've had with tests is generating test data.
>
> Can't help you there, it least not right now. I'm open to suggestions.

I was planning on creating a function to generate random strings out
of a regular expression, though I'll first need to write a good
parsing library first. I think my current focus, at least in the realm
of testing, is to create functions for generating random test data.

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

[James Reeves]

On Jan 19, 8:12 pm, ".Bill Smith"  wrote:
> Would you mind elaborating on that point?  At a previous job, I worked
> on a corporate banking application that had numerous configuration
> settings.  Thousands of companies used the application.   It was
> impractical to test the application with every possible configuration
> vector (i.e. every combination of configuration settings), or even for
> every set of configuration vectors that were actually in use.  It was
> a challenge to decide which configuration vectors to test against.

I'm not sure there's much to elaborate on. It's a problem, and one I
haven't solved, but I have some ideas. Ideally, I'd like to be able to
write something like:

(defn rnd-valid-name []
  (rnd-str "[A-Za-z][A-Za-z0-9_]*")

(defn rnd-user []
  {:uid (rnd-int 1 100)
   :name(rnd-valid-name)
   :created (rnd-past-date (weeks 3))})

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

[.Bill Smith]

> I'm not sure there's much to elaborate on. It's a problem, and one I
> haven't solved, but I have some ideas. Ideally, I'd like to be able to
> write something like:
>
> (defn rnd-valid-name []
>   (rnd-str "[A-Za-z][A-Za-z0-9_]*")
>
> (defn rnd-user []
>   {:uid     (rnd-int 1 100)
>    :name    (rnd-valid-name)
>    :created (rnd-past-date (weeks 3))})

Ok, so you're focused at the level of "here's what characterizes a
test vector, go generate some for me."

I was thinking more about this kind of thing: http://www.pairwise.org/.

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

Re: Yet another html templating library

[Stuart Sierra]

On Jan 19, 2:18 pm, Christophe Grand  wrote:
> In the only example, I use 'when-not to conditionally display an element.

Got it, I didn't recognize at first what html/show was doing.
-S
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Actually, so this can't be used on structs for fns?

On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
wrote:

>
> On Jan 19, 1:15 pm, David Nolen  wrote:
> > I've noticed this as well.  It seems to me that this prevents you from
> > dynamically defining a var (like in a macro) that has metadata attached
> to
> > it or it's arguments (if it's a function).
>
> You can also use the new alter-meta! function, which works on
> anything:
>
> -
> clojure.core/alter-meta!
> ([iref f & args])
>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
> be:
>
>  (apply f its-current-meta args)
>
>  f must be free of side-effects
>
>
> -Stuart Sierra
> >
>

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

Re: Another socket repl

[Stephen C. Gilardi]

On Jan 19, 2009, at 2:15 PM, Craig McDaniel wrote:


Thanks, that's a good point. I'm posting a new file server-socket.clj
that is more generic and includes the REPL as an example case.


I checked in server_socket.clj - thanks!

--Steve



smime.p7s
Description: S/MIME cryptographic signature

Re: Yet another html templating library

[Daniel Jomphe]

Stuart Sierra wrote:

>  Very interesting, Christophe. I've been playing with StringTemplate
>  lately, but this separates design
> from code even further. Can it do conditionals, as in "if this
> variable is true, includes this HTML element"?

...and the following posts establishing that it can.

Therefore, this feels a bit misleading to me: "this separates design
from code even further". I just want to point out StringTemplate helps
separating design from code, but its main goal is separating the View
from Controller and Model in a formally strict way. In the case of
enlive, this main goal is not achieved, so it couldn't be done "even
further". So my point is we must understand your phrase in a biased
way because it appears to be more separated from design, but is less
in fact.

Disclosure: I have no interest in StringTemplate, other than the fact
I read its formal paper today. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: is it type hint?

[Colin Walters]

On Jan 19, 12:34 pm, Chouser  wrote:
>
> If you remove the #^String type hint, you'll see that both String and
> StringBuffer work fine.

In this specific case, one would use CharSequence, an interface both
String and StringBuffer implement.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Possible feature: consider aliases when reading namespace-qualified keywords.

[Jason Wolfe]

I've been doing some OO-type Clojure programming, and have run into
the following (quite minor) annoyance:

I've defined a struct with a :class of ::Foo in namespace
my.long.namespace.foo.

In another namespace my.long.namespace.bar, I want to define a
subclass of this struct.
In this namespace, I require [...foo :as foo], so that I can refer to
multimethods like foo/method1.

However, it seems I'm still required to write
(derive ::Bar :my.long.namespace.foo/Foo)
when I'd like to write
(derive ::Bar :foo/Foo)

 I'm not sure if this is even feasible, since given my limited
experience it seems that aliases for symbols are handled at resolution-
time and not read-time, and that wouldn't work for keywords.   On the
other hand, this state of affairs seems to be possibly-confusing and a
perhaps-needless difference between symbols and keywords.  What do
others think about this?

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

Re: Mysterious performance anomalies

[e]

That's a solid arg, too . . . but it would be stronger if we weren't
importing things from java all the time.  If we said like, "(gui-frame
"hello"), which happened to be implemented as a JFrame . . . then that'd be
even stronger.  Drop in a different REPL and you'd still get a JFrame-like
thing even if it weren't from a java lib via a JVM.


On Mon, Jan 19, 2009 at 2:23 PM, Mark H.  wrote:

>
> On Jan 18, 8:48 am, e  wrote:
> > That's a great argument.  I need arguments like these.  I work with
> people
> > who dismiss JVM.  Even though there are many non-Sun JVM's, folks say,
> "Sun
> > is dead -> java is dead -> jvm is dead." . even though Java is the
> most
> > popular language right now.
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> A lot of people agree that having some kind of VM is very helpful.  It
> may not necessarily be the JVM in the future, but right now the JVM is
> popular enough that it's worth using it rather than relying on some
> other VM that might also go away.  VMs provide portability, can do a
> lot of low-level optimizations (that would otherwise have to go into
> the compiler), and have useful services (like garbage collection) that
> save folks like Rich a lot of trouble when implementing a new
> language.
>
> Saying we shouldn't use the JVM because Sun might go away is like
> saying we shouldn't bother improving gas mileage in cars because
> gasoline might go away.  (Of course it pays to think about the long
> term, but shorter-term gains are worth the work.)
>
> mfh
>
>
>
> >
> > I wonder if there will ever be a JM ... that is a chip that natively
> > executes byte code.  I wonder what they'd have to say, then.  I think
> I'll
> > do a Google search.  I also wonder if it was a tough decision for Rich to
> > cut the CLI support.  I know he feels fine looking back.
> >
> > On Sun, Jan 18, 2009 at 12:23 AM, Mark H. 
> wrote:
> >
> > > On Jan 16, 6:47 am, e  wrote:
> > > > Is it much much easier to make byte code than assembly code?
> >
> > > I'll chime in too to say that x86 is only king of the desktop / laptop
> > > world -- many portable devices are ARM-based (and a lot of Windows
> > > apps run on ARM), and there are other architectures used for
> > > enterprise and HPC servers.  Plus it's not clear to me that x86 will
> > > win, esp. in power-constrained arenas.  (All those legacy instructions
> > > and the translation from x86 ops into reasonable microops eat power
> > > and area.)  I've dealt with at least six different instruction sets in
> > > my HPC work and the JVM runs on at least five of them:  instant
> > > portability!
> >
> > > mfh
> >
>

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

Re: fit for contribution to clojure.contrib.ns-utils?

[e]

can someone explain to a newby like me what we are talking about here?  :)
This is totally over my head.  Only do so if you think it's a valuable
lesson to be had.  Otherwise, I fully accept that if I don't get it, then
I'm not the intended audience.

Thanks.

On Mon, Jan 19, 2009 at 2:23 PM, Dan Larkin  wrote:

>
>
> On Jan 19, 2009, at 12:39 PM, Michael Reid wrote:
> >
> > Forgive me I am probably missing something, but if your use case is in
> > a configuration file, why can't you just to a regular (ns .. (:require
> > ..)) so that your configuration file can declare its dependencies in
> > the same way other code does?
>
> Configurations can be loaded at runtime, in my system. Loading a
> configuration file updates a *settings* Atom (might change to a Var,
> actually).
>
> Sure, the configuration file could (require ...) all the namespaces it
> needs, but isn't resolve* nicer? :)
>
> Also, due to the late-binding nature of using resolve* I gain some
> performance benefits of not evaluating top-level forms in the required
> namespaces until they're actually needed.
>
> >
> >
> > But I also wanted to add that this could be a very useful function for
> > an IDE/tools to use.
> >
> > I'm thinking of the case where the user is editing code and wants to
> > examine a reference to a var in their source file. This enhanced
> > "resolve*" could be called to load and resolve the reference and then
> > the IDE/tool can do whatever it might do for the result--examine it
> > for a docstring, or load up an inspector or whatever.
> >
> > /mike
> >
> > >
>
>
> >
>

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

[ANN] Dejcartes

[Mark Fredrickson]

Hello friends,

I would like to announce a super-pre-alpha release of Dejcartes, a  
Clojure wrapper around the JFreeChart charting library. From the readme:

Dejcartes is a Clojure interface to the JFreeChart charting and graphing
library. A simple interface to be sure, but practical for graphing  
many data
sources. Dejcartes is mostly a wrapper around the ChartFactory static  
methods.
This interface suits Clojure's functional paradigm very well.

Chart supports using native Clojure collections for data sources. This  
makes
graphing from Clojure applications very intuitive. Lists, vectors, and
hash-maps are translated into JFreeChart's native data types behind  
the scenes
as needed. A demo showing many of the supported functions and Clojure  
native data
structures is included and can be run from the command line with "ant  
demo". Here
is a brief excerpt:

 (require '[com.markmfredrickson.dejcartes :as chart])

 ;; a simple function for making windows -- wrapper coming soon
 (import '(org.jfree.chart chartframe))
 (defn make-window [title chart]
   (doto (new chartframe title chart)
 (.pack)
 (.setvisible true)))

 ; first, some categorical data
 (def editor-survey
   {2009
 {"emacs" 312 "vim" 234 "eclipse" 193 "netbeans" 82 "other" 26}
2008
 {"vim" 192 "emacs" 267 "eclipse" 297 "other" 75}})

 ;; a pie chart of the 2009 data
 (make-window "Editor Survey"
   (chart/pie "2009 Results" (editor-survey 2009)))

Dejcartes is a young project and is lacking in comprehensive  
documentation. The
best reference right now is the demo.clj example code and the  
JFreeChart API
documentation. Future improvements will include more documentation, an  
Agent
based interface for interacting with chart windows, and a persistent  
(read:
non-mutating) interface for annotations and other more powerful chart  
features.

Dejcartes is licensed under the GNU Lesser GPL, which is consistent with
JFreeChart's license.

The code can be found at: http://www.markmfredrickson.com/code/

Best wishes,
- Mark Fredrickson
mark.m.fredrick...@gmail.com
http://www.markmfredrickson.com







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

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Works. amazing.

On Mon, Jan 19, 2009 at 4:51 PM, David Nolen  wrote:

> Actually, so this can't be used on structs for fns?
>
> On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra <
> the.stuart.sie...@gmail.com> wrote:
>
>>
>> On Jan 19, 1:15 pm, David Nolen  wrote:
>> > I've noticed this as well.  It seems to me that this prevents you from
>> > dynamically defining a var (like in a macro) that has metadata attached
>> to
>> > it or it's arguments (if it's a function).
>>
>> You can also use the new alter-meta! function, which works on
>> anything:
>>
>> -
>> clojure.core/alter-meta!
>> ([iref f & args])
>>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
>> be:
>>
>>  (apply f its-current-meta args)
>>
>>  f must be free of side-effects
>>
>>
>> -Stuart Sierra
>> >>
>>
>

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

Re: Possible feature: consider aliases when reading namespace-qualified keywords.

[David Nolen]

My OO example from earlier deals with this case by completely removing any
need to manually derive tags.  This is done by having CLJOS keep it's own
internal hierarchy (via make-hierarchy) rather than using the default one.
 By modifying metadata on the vars holding structs created by defclass
(using alter-meta!) and tagging instances as described in existing Clojure
literature you can provide functions to shuffle away the annoyance of
dealing with keywords and their namespaces entirely.
On Mon, Jan 19, 2009 at 7:29 PM, Jason Wolfe  wrote:

>
> I've been doing some OO-type Clojure programming, and have run into
> the following (quite minor) annoyance:
>
> I've defined a struct with a :class of ::Foo in namespace
> my.long.namespace.foo.
>
> In another namespace my.long.namespace.bar, I want to define a
> subclass of this struct.
> In this namespace, I require [...foo :as foo], so that I can refer to
> multimethods like foo/method1.
>
> However, it seems I'm still required to write
> (derive ::Bar :my.long.namespace.foo/Foo)
> when I'd like to write
> (derive ::Bar :foo/Foo)
>
>  I'm not sure if this is even feasible, since given my limited
> experience it seems that aliases for symbols are handled at resolution-
> time and not read-time, and that wouldn't work for keywords.   On the
> other hand, this state of affairs seems to be possibly-confusing and a
> perhaps-needless difference between symbols and keywords.  What do
> others think about this?
>
> Thanks,
> Jason
> >
>

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

Unexpected binding behavior

[Hugh Winkler]

Hi all. Is this a bug or a feature? When I bind the var *num* to a new
value, in one case it appears the lambda uses the original value, not
the newly bound one.

(def *num* 16)

(defn f1 []
 ( map (fn [x]  *num* ) [1]))


(defn f2 []   ;; same as f1 but calls first on the map
 (first
  ( map (fn [x]  *num* ) [1])))


user> (f1)
(16)   <--ok
user> (f2)
16 <--ok
user> (binding [*num* 1024] (f1))
(16)  <-- expected 1024
user> (binding [*num* 1024] (f2))
1024 <--ok after
all, in spite of the fact the above gave list (16)

Thanks,
Hugh

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

Re: Unexpected binding behavior

[Stuart Halloway]

Lazy evaluation is a harsh mistress.

user=> (def b1 (binding [*num* 1024] (f1)))
#'user/b1
user=> (def b2 (binding [*num* 1024] (f1)))
#'user/b2
user=> b1
(16)
user=> b2
(16)

The difference between the example above and your example is the  
interaction with the REPL. Your f1 is lazy, and is not realized until  
outside the binding, when the REPL needs it. Your f2, also lazy, is  
realized inside the binding because of the call to first.

Cheers,
Stuart

> Hi all. Is this a bug or a feature? When I bind the var *num* to a new
> value, in one case it appears the lambda uses the original value, not
> the newly bound one.
>
> (def *num* 16)
>
> (defn f1 []
> ( map (fn [x]  *num* ) [1]))
>
>
> (defn f2 []   ;; same as f1 but calls first on the map
> (first
>  ( map (fn [x]  *num* ) [1])))
>
>
> user> (f1)
> (16)   <--ok
> user> (f2)
> 16 <--ok
> user> (binding [*num* 1024] (f1))
> (16)  <--  
> expected 1024
> user> (binding [*num* 1024] (f2))
> 1024 <--ok after
> all, in spite of the fact the above gave list (16)
>
> Thanks,
> Hugh
>
> >


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

Re: per-defmulti hierarchies

[Mark Fredrickson]

On the subject of per defmulti hierarchies:

The recent CLJOS thread got me thinking about this problem again.  
While allowing per-multimethod hierarchies solves a large number  
problems, I think it might be lacking for a class of needs. I think I  
have solution that can provide for multiple hierarchies and meet this  
larger class to which I allude. Allow me to provide an illustration.  
Say I have a step-wise mathematical function. From less than or equal  
to zero, return zero. From more than zero to less than equal to five,  
return the value. Above 5, square the value.

I could implement that as multimethod:

(defmulti stepwise (fn [n] (cond (>= 0 n) :zero (and (> n 0) (< n  
5)) :zero-five :else :above-five)))
(defmethod stepwise :zero [_] 0)
(defmethod stepwise :zero-five [x] x)
(defmethod stepwise :above-five [x] (* x x))

I've left an intentional programming error in to show how easy it is  
to make an error with such (cond ...) based dispatch. Yuck.

But there is a better way. What if I could supply my own function to  
decide which key matched the multimethod (not what the key is for the  
value, but how the key maps to a multimethod). Currently all we have  
is isa?, but if this were only the default? My example might look  
something like:

(defmulti stepwise identity <=)
(defmethod stepwise 0 [_] 0)
(defmethod stepwise 5 [n] n)
(defmethod stepwise :default [n] (* n n))
(prefer-method stepwise 0 5) ; since -1 < 0 and -1 < 5

I find this much cleaner, and the subtle error above was been  
eliminated. And if I want to add another case, its not too hard  
(though the number of prefer-methods might increase exponentially).  
This is a rather trivial case, but I think it makes the need clear:  
per-multi comparison functions.

For multiple hierarchies, this would be a common idiom:
(defmulti mymulti dispatch-function (fn [object-key method-key] (isa?  
*my-hiearchy* object-key method-key))

A user could use a ref or atom as needed, no special casing in the  
Clojure code.

What do people think?
-Mark


On Jan 7, 2009, at 10:44 AM, Meikel Brandmeyer wrote:

> Hi Rich,
>
> Am 07.01.2009 um 17:10 schrieb Rich Hickey:
>
>> Thanks Meikel. I have a couple of points:
>>
>> First, making derive and underive act on vars instead of the
>> hierarchies directly is not good - it reduces the generality
>> needlessly. Good practice is to make pure fns, then do the reference
>> part, not mix the two.
>>
>> Second, there's no reason to bind MultiFn to Var - any IRef will do.
>> Then people can put their hierarchies in Atoms/Refs or whatever.
>>
>> Third, I don't see the need for defhierarchy at this point.
>
> Ok. My problem is, that passing the hierarchy directly
> doesn't allow adding further derivations. The only idea
> I had, was to use Vars. I didn't like the idea, but I
> couldn't come up with another one. The solution is again
> an abstraction: IRef. Changing (un)derive and adding
> defhierarchy, was just some try to help the user with
> the limitations of this approach.
>
> But (dosync (alter ref-to-hierarchy derive ::Foo ::Bar))
> works perfectly. :) Much cleaner indeed. This shows
> again: ugly solutions and special cases are a sign,
> that one does it wrong...
>
> Please find attached another patch going for IRef instead
> of Var directly. And without the other cruft.
>
> Sincerely
> Meikel
>
> 

- Mark Fredrickson
mark.m.fredrick...@gmail.com
http://www.markmfredrickson.com







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

Re: 2 Cents Calculator

[Timothy Pratley]

Hi Emeka,

On Jan 19, 11:17 pm, janus  wrote:
> that's why I' ve decided to 'outsource' :).I invite your comments and
> any code that might make this toy to worth 2 cents in today's market.

Reducing the amount of repetition :)
http://groups.google.com/group/clojure/web/2c-calculator.clj


Regards,
Tim.

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

Automatic upcasting from int to double.

[CuppoJava]

Just wondering if this behavior is by design:

(Math/min 0 0.2)
java.lang.IllegalArgumentException: No matching method found: min
(NO_SOURCE_FILE:0)

(Math/min 0.0 0.2)
0.0

Coming from Java, it just stuck out to me, since Java has automatic
upcasting.

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

Re: Unexpected binding behavior

[Michael Wood]

Hi

On Tue, Jan 20, 2009 at 7:01 AM, Stuart Halloway
 wrote:
>
> Lazy evaluation is a harsh mistress.
>
> user=> (def b1 (binding [*num* 1024] (f1)))
> #'user/b1
> user=> (def b2 (binding [*num* 1024] (f1)))
> #'user/b2

Did you mean b1 and b2 to have the same definition?  If so, I don't
understand what you are trying to demonstrate by doing that.

> user=> b1
> (16)
> user=> b2
> (16)
>
> The difference between the example above and your example is the
> interaction with the REPL. Your f1 is lazy, and is not realized until
> outside the binding, when the REPL needs it. Your f2, also lazy, is
> realized inside the binding because of the call to first.

I thought this stuff was supposed to be easier to reason about! :)
Would it perhaps make sense to save the environment that f1 was called
in and use that during the realisation of its result?  That would seem
to be far more sensible, but maybe there's a reason it would not work.

How would one go about fixing f1 (or b1)?

-- 
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
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: Automatic upcasting from int to double.

[Timothy Pratley]

While it doesn't answer your more general question, just pointing out
there is a Clojure min:
user=> (min 0 0.2)
0

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

Re: Unexpected binding behavior

[Timothy Pratley]

> How would one go about fixing f1 (or b1)?

Depends what you want to achieve... here are two possible 'fixes':

; don't use lazy evaluation
(defn f1 []
  (doall (map (fn [x]  *num* ) [1])))

; use lazy evaluation, but preserve the binding when the lazy sequence
is created
(defn f1 []
  (let [mynum *num*]
(map (fn [x] mynum) [1])))


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