Re: SLIME REPL broken
Stefan put in words what I was thinking earlier today. For those of us that use both CL and clojure, keeping swank-clojure up to date wrt the slime HEAD is a good thing, if you ask me. It is, however, a two-way street and I would imagine that the swank-clojure implementors don't want to spend too much time chasing SLIME's tail, as it were. Keeping the clojure backend on the radar of the core SLIME development team is probably a good thing. I think it would be unfortunate if swank-clojure were to require a different SLIME emacs piece than the CL swank (and scheme48, etc...) backends. cyrus On Nov 16, 2009, at 2:15 PM, Stefan Kamphausen wrote: > Hi, > > Phil Hagelberg wrote: >> Unless there are some really great features added upstream in slime, >> fixing swank-clojure to work with their latest changes is a low priority. > > this is a pity, at least for those of us, who also use Slime to do > some CL hacking. For that setup it is quite common to always update > to CVS head because that may be the only version working with current > releases of, e.g., SBCL. Well, currently I don't really do CL stuff, > it's just that I set up another machine doing lots of VC-checkouts... > I could just copy an older version of Slime there. > > I'll take a look at it the next few days (er, evenings that is), if I > find the time. No promises ;-) > > Over there at Slime's people are thinking, the Clojure family forked > Slime, maybe that's not the worst idea. Things would probably get > easier if there were only one backend to support. > > Best regards, > Stefan > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: SLIME REPL broken
Hi, Stefan Kamphausen wrote: > I'll take a look at it the next few days (er, evenings that is), if I > find the time. No promises ;-) Not that I'm close to a solution, but at least I have stacktrace... After some digging in the clojure-swank code I came across this piece in swank.clj: (defn- connection-serve [conn] (let [control (dothread-swank (thread-set-name "Swank Control Thread") (try (control-loop conn) (catch Exception e ;; fail silently nil))) and I didn't like that comment. So I changed that to (defn- connection-serve [conn] (let [control (dothread-swank (thread-set-name "Swank Control Thread") (try (control-loop conn) (catch Exception e ;; fail silently (.printStackTrace e) (.printStackTrace (.getCause e)) nil))) Then after typing just "(+" into the SLIME-REPL-Buffer (obviously without the quotes) I see a stacktrace in the *inferior-lisp*-Buffer: user=> user=> Connection opened on local port 37693 # user=> user=> java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer $ConditionObject.reportInterruptAfterWait (AbstractQueuedSynchronizer.java:1899) at java.util.concurrent.locks.AbstractQueuedSynchronizer $ConditionObject.await(AbstractQueuedSynchronizer.java:1934) at java.util.concurrent.LinkedBlockingQueue.take (LinkedBlockingQueue.java:358) at swank.util.concurrent.mbox$receive__214.invoke(mbox.clj:28) at swank.core$control_loop__249.invoke(core.clj:258) at swank.swank$connection_serve__365$fn__397$fn__399.invoke(swank.clj: 29) at clojure.lang.AFn.applyToHelper(AFn.java:171) at clojure.lang.AFn.applyTo(AFn.java:164) at clojure.core$apply__4305.invoke(core.clj:420) at swank.swank$connection_serve__365$fn__397.doInvoke(swank.clj:26) at clojure.lang.RestFn.invoke(RestFn.java:402) at clojure.lang.AFn.run(AFn.java:37) at java.lang.Thread.run(Thread.java:619) Exception in thread "Swank Control Thread" java.lang.RuntimeException: java.lang.NullPointerException at clojure.lang.AFn.run(AFn.java:41) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at swank.swank$connection_serve__365$fn__397$fn__399.invoke(swank.clj: 33) at clojure.lang.AFn.applyToHelper(AFn.java:171) at clojure.lang.AFn.applyTo(AFn.java:164) at clojure.core$apply__4305.invoke(core.clj:420) at swank.swank$connection_serve__365$fn__397.doInvoke(swank.clj:26) at clojure.lang.RestFn.invoke(RestFn.java:402) at clojure.lang.AFn.run(AFn.java:37) ... 1 more (I hope, google-group-posting will not mess with the pasted code, I can see no preview-button on the posting-page) And sending a SIGQUIT to the java-process shows that at least the "Swank Control Thread" died (I think some other swank-threads, too). What's most annoying is that I have not yet found a way to debug this without restarting the JVM every few minutes. Still working on this... If anyone can give me a pointer where to look next, the help will be highly appreciated. Kind regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
A typo on the website about vars
Hi, I'm wondering what part is missing in "which provides a means for nested contexts to communicate with code before it the call stack." at http://clojure.org/vars? I think the wording is broken at the end. Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
No names with trailing % allowed but with a leading one?
Hi, during some examinations about the broken REPL with current Slime I found that I can't create names with a trailing %: Clojure 1.1.0-alpha-SNAPSHOT user=> (def %thisworks 11) #'user/%thisworks user=> %thisworks 11 user=> (def %thisdoesnt% 22) java.lang.Exception: Too many arguments to def (NO_SOURCE_FILE:3) user=> According to http://clojure.org/reader : "Symbols begin with a non- numeric character and can contain alphanumeric characters and *, +, !, -, _, and ? (other characters will be allowed eventually, but not all macro characters have been determined)" So, am I right, that "non-numeric character" for the first char includes the percent-sign whereas the explicit list for all following characters doesn't. Rather peculiar, I think. Not? Kind regards, Stefan PS: The background of this is, that Slime is sending a "%CURSOR-MARKER %" down the line. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Web Libraries
On Nov 16, 8:03 pm, ngocdaothanh wrote: > Could someone provide an example about using Clojure with Restlet? > > I found:http://github.com/stuartsierra/altlaw-clojure-restlet > but don't understand how the code works as a web application. It doesn't. That's just a few helper functions I wrote to work with Restlet. To use Clojure with Restlet, you have to proxy or gen-class your own implementations of its API classes like Restlet, Resource, Filter, etc. -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Datatypes and Protocols - early experience program
On Nov 16, 11:57 am, Jonas Enlund wrote: > I made count return the number of rows because that way (count > a-matrix) == (count (seq a-matrix)). I don't know if it's the right > thing to do, maybe rows*cols would make more sense. Good point. I don't know which is better. -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.xml/parse of XHTML yields a 503 on the DTD
I'm having this same problem. Did you find a way around it? I want to try changing the User-Agent, but I can't figure out how to do that. What's a "catalog file"? any ideas? thanks, paul w -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Remote REPL problem when connecting to RMI Client VM
Jon, Thanks for the reply. You are correct. When my compiled code tries to run "(eval (+ 1 1))" I get the same exception that I got when I tried "(+ 1 1)" from the repl. Since I only need to be able to interact with the REPL when the client is running on my development machine, I am going to try to dynamically add clojure.jar to the classpath at runtime using add-classpath. It seems unlikely, but worth a shot. Any other ideas? Thanks. Kent. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure & Terracotta - TIM
Hi Paul, the code from [1] does not work under the latest Terracotta (3.1.1) with clojure-slim.jar's in the following combinations: 1) branch "1.0.x" from [3] 2) branch "1.0.x" from [3] + modified ClojureTerracottaConfigurator.java (uncommented lines) 3) [2] svn revision 1335 + modified ClojureTerracottaConfigurator.java (uncommented lines) 4) [2] svn revision 1310 + modified ClojureTerracottaConfigurator.java (uncommented lines) Terracotta writes messages like "Non-portable field name : clojure.lang.Var.root Unshareable class : clojure.lang.XMLHandler " [1] http://github.com/pjstadig/tim-clojure-1.0-snapshot [2] http://clojure.googlecode.com/svn [3] http://github.com/richhickey/clojure -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.xml/parse of XHTML yields a 503 on the DTD
On Tue, Nov 17, 2009 at 08:03:59AM -0800, pkw wrote: >I'm having this same problem. Did you find a way around it? >I want to try changing the User-Agent, but I can't figure out >how to do that. I suspect that the Sax parser by default is configured to not allow fetching of the DTD over the net. I worked around this by replacing the URL in the DOCTYPE declaration with a file one and fetching the files myself. But, admittedly that's not a good solution. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A typo on the website about vars
On Tue, Nov 17, 2009 at 8:40 AM, Jacek Laskowski wrote: > Hi, > > I'm wondering what part is missing in "which provides a means for > nested contexts to communicate with code before it the call stack." at > http://clojure.org/vars? I think the wording is broken at the end. > Probably "in": "which provides a means for nested contexts to communicate with code before it in the call stack." -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Datatypes and Protocols - early experience program
A quick aside about matrices. Every dense matrix algorithm is measured by the number of rows (n). LU factorization is O(n^3), as is QR. If memory serves, Eigenvalues are usually O(n^2). Determinants are O(n^3), too. These estimates change if the matrix is banded, they usually become O(n). The point is, mathematicians care about the number of rows. I'd recommend that. Sean On Nov 17, 10:09 am, Stuart Sierra wrote: > On Nov 16, 11:57 am, Jonas Enlund wrote: > > > I made count return the number of rows because that way (count > > a-matrix) == (count (seq a-matrix)). I don't know if it's the right > > thing to do, maybe rows*cols would make more sense. > > Good point. I don't know which is better. > -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
I *THINK* what is meant by the "non-numeric" is anything that matches #"[a-zA-z]" Just my $.02 Sean On Nov 17, 9:30 am, Stefan Kamphausen wrote: > Hi, > > during some examinations about the broken REPL with current Slime I > found that I can't create names with a trailing %: > > Clojure 1.1.0-alpha-SNAPSHOT > user=> (def %thisworks 11) > #'user/%thisworks > user=> %thisworks > 11 > user=> (def %thisdoesnt% 22) > java.lang.Exception: Too many arguments to def (NO_SOURCE_FILE:3) > user=> > > According tohttp://clojure.org/reader: "Symbols begin with a non- > numeric character and can contain alphanumeric characters and *, +, !, > -, _, and ? (other characters will be allowed eventually, but not all > macro characters have been determined)" > > So, am I right, that "non-numeric character" for the first char > includes the percent-sign whereas the explicit list for all following > characters doesn't. > > Rather peculiar, I think. Not? > > Kind regards, > Stefan > > PS: The background of this is, that Slime is sending a "%CURSOR-MARKER > %" down the line. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
On Tue, Nov 17, 2009 at 1:46 PM, Sean Devlin wrote: > I *THINK* what is meant by the "non-numeric" is anything that matches > > #"[a-zA-z]" > Nah, it'll be anything that's allowed elsewhere AND is not a digit. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
Hi, On Nov 17, 8:12 pm, John Harrop wrote: > On Tue, Nov 17, 2009 at 1:46 PM, Sean Devlin wrote: > > > I *THINK* what is meant by the "non-numeric" is anything that matches > > > #"[a-zA-z]" > > Nah, it'll be anything that's allowed elsewhere AND is not a digit. Does that mean, the % as the first char should not be allowed, whereas at it is in the Version I use (did that change in branch new, BTW?). And, wouldn't it be nice to get a clearer error-message? :-) Best regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A typo on the website about vars
On Tue, Nov 17, 2009 at 8:40 AM, Jacek Laskowski wrote: > > I'm wondering what part is missing in "which provides a means for > nested contexts to communicate with code before it the call stack." at > http://clojure.org/vars? I think the wording is broken at the end. Fixed, thanks. --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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
On Tue, Nov 17, 2009 at 2:17 PM, Stefan Kamphausen
wrote:
> Hi,
>
> On Nov 17, 8:12 pm, John Harrop wrote:
> > On Tue, Nov 17, 2009 at 1:46 PM, Sean Devlin >wrote:
> >
> > > I *THINK* what is meant by the "non-numeric" is anything that matches
> >
> > > #"[a-zA-z]"
> >
> > Nah, it'll be anything that's allowed elsewhere AND is not a digit.
>
> Does that mean, the % as the first char should not be allowed, whereas
> at it is in the Version I use (did that change in branch new, BTW?).
>
The docs say that letters and *, +, !, -, _, and ? should work anywhere, and
letters, numbers, and *, +, !, -, _, and ? elsewhere than the first
character, while making no guarantees about most other characters and
specifically indicating that / and . will NOT work. (And delimiters -- (, ),
{, }, [, and ] -- won't work, nor will whitespace (including commas), since
they act as token separators.)
In practice, most other characters seem to work, but characters used in
reader macros (#, %, ;, ', `, ~, @, etc.) may not. It is rather odd that %
acts up outside of the #() reader macro though.
And, wouldn't it be nice to get a clearer error-message? :-)
>
Wouldn't it always?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: SLIME REPL broken
Hi, On Nov 17, 1:47 pm, Stefan Kamphausen wrote: [...] > user=> user=> Connection opened on local port 37693 > # [addr=0.0.0.0/0.0.0.0,port=0,localport=37693]> > user=> user=> java.lang.InterruptedException > [...] > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.NullPointerException > [...] > And sending a SIGQUIT to the java-process shows that at least the > "Swank Control Thread" died (I think some other swank-threads, too). By now, I think the NPE is the thread that was killed. Actually I have made some progress in gettings things into a working state again, but that would need some changes on the Slime-side. So I asked over there: http://article.gmane.org/gmane.lisp.slime.devel/9197 Kind regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A typo on the website about vars
On Tue, Nov 17, 2009 at 2:31 PM, Chouser wrote: > On Tue, Nov 17, 2009 at 8:40 AM, Jacek Laskowski > wrote: > > > > I'm wondering what part is missing in "which provides a means for > > nested contexts to communicate with code before it the call stack." at > > http://clojure.org/vars? I think the wording is broken at the end. > > Fixed, thanks. But there's another problem: "Note - you cannot assign to function params or local bindings. Only Java fields, Vars, Refs and Agents are mutable in Clojure." Er, what about Atoms? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A macro for flexible keyword argument handling
On Nov 16, 4:28 pm, Chouser wrote:
> 'let' is also careful to always have the user provide the symbol
> being bound as a symbol. That is you say {:keys [a b c]} not
> {:keys [:a :b :c]}. What do you think of having let-kw take
> symbols instead of keywords for the names being bound?
I think that's a good idea.
Updated version:
(defmacro let-kw
"Adds flexible keyword handling to any form which has a parameter
list: fn, defn, defmethod, letfn, and others. Keywords may be
passed to the surrounding form as & rest arguments, lists, or
maps. Lists or maps must be used for functions with multiple
arities if more than one arity has keyword parameters. Keywords are
bound inside let-kw as symbols, with default values either
specified in the keyword spec or nil. Keyword specs may consist of
just the bare keyword symbol, which defaults to nil, or may have
the general form [keyword-name keyword-default-value*
keyword-supplied?*]. keyword-supplied? is an optional symbol
bound to true if the keyword was supplied, and to false otherwise."
[kw-spec-raw kw-args & body]
(let [kw-spec (map #(if (sequential? %) % [%]) kw-spec-raw)
symbols (map first kw-spec)
keywords (map (comp keyword name) symbols)
defaults (map second kw-spec)
destrmap {:keys (vec symbols) :or (zipmap symbols defaults)}
supplied (reduce
(fn [m [k v]] (assoc m k v)) (sorted-map)
(remove (fn [[_ val]] (nil? val))
(partition 2 (interleave
keywords
(map (comp second rest)
kw-spec)
kw-args-map (gensym)]
`(let [kw-args# ~kw-args
~kw-args-map (if (map? kw-args#)
kw-args#
(apply hash-map kw-args#))
~destrmap ~kw-args-map]
~@(if (empty? supplied)
body
`((apply (fn [~@(vals supplied)]
~...@body)
(map (fn [x#] (contains? ~kw-args-map x#))
[~@(keys supplied)])))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: SLIME REPL broken
Stefan, Thanks for pursuing this so adamantly :) For a long time (more than a year) it was possible to use SLIME tip. It would be great for that to continue. David On Tue, Nov 17, 2009 at 2:44 PM, Stefan Kamphausen wrote: > Hi, > > On Nov 17, 1:47 pm, Stefan Kamphausen wrote: > > [...] > > user=> user=> Connection opened on local port 37693 > > # > [addr=0.0.0.0/0.0.0.0,port=0,localport=37693]> > > user=> user=> java.lang.InterruptedException > > [...] > >at java.lang.Thread.run(Thread.java:619) > > Caused by: java.lang.NullPointerException > > [...] > > > And sending a SIGQUIT to the java-process shows that at least the > > "Swank Control Thread" died (I think some other swank-threads, too). > > By now, I think the NPE is the thread that was killed. Actually I > have made some progress in gettings things into a working state again, > but that would need some changes on the Slime-side. So I asked over > there: > > http://article.gmane.org/gmane.lisp.slime.devel/9197 > > Kind regards, > Stefan > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
Hi John, On Nov 17, 8:40 pm, John Harrop wrote: > The docs say that letters and *, +, !, -, _, and ? should work anywhere, do you read it that way? I think the doc (if you are referring to http://clojure.org/reader) are a little vague here: "Symbols begin with a non-numeric character". > and > letters, numbers, and *, +, !, -, _, and ? elsewhere than the first > character, while making no guarantees about most other characters I understood that other characters weren't allowed at all. So I wondered that I could create a variable-name starting with a %. But the vagueness about the first char jumped right in, since it allows the % there. But then, it just feels like an accident and not like purpose, so I thought, I'd better ask. >> And, wouldn't it be nice to get a clearer error-message? :-) > > Wouldn't it always? Sure, that's the reason for that :-) up there. Best regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
def a generated symbol?
How do you def a symbol that you make using (symbol)? I.E. if I try to do (def (symbol "x") 2) I get: java.lang.Exception: Second argument to def must be a Symbol. (And why does it say the \second argument must be a symbol?) Thanks, Nick. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: def a generated symbol?
On Tue, Nov 17, 2009 at 3:59 PM, nchubrich wrote: > How do you def a symbol that you make using (symbol)? I.E. if I try > to do (def (symbol "x") 2) I get: > java.lang.Exception: Second argument to def must be a Symbol. (And > why does it say the \second argument must be a symbol?) > Special forms and macros don't evaluate their arguments. So def's second argument here is a list of the symbol "symbol" and the string literal "x". There are two ways to do what you want: macros and eval. Macro: (defmacro def-from-string [sym-name-string initial-value] `(def ~(symbol sym-name-string) ~initial-value)) will let you use (def-from-string "x" 2) to achieve what you attempted above. (Making the initial binding optional, as in "def", is left as an exercise for the reader. So is providing a way to attach metadata.) Eval: (eval (list 'def (symbol "x") 2)) will intern the symbol in some namespace or another when executed. You might also (eval `(binding [*ns* foo] (def ~(symbol "x") 2))) to have absolute and certain control over exactly what namespace. This has the disadvantage of using the perilous "eval", but the advantage that you can even intern the symbol at run-time; the string "x" can even come from the network or user or otherwise not have been known at compile-time, or the initial root binding 2, or the namespace even. (Similar constructs can be used to create whole namespaces on the fly at runtime. But that's serious metaprogramming.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: def a generated symbol?
On Tue, Nov 17, 2009 at 4:11 PM, John Harrop wrote: > On Tue, Nov 17, 2009 at 3:59 PM, nchubrich > wrote: >> >> How do you def a symbol that you make using (symbol)? I.E. if I try >> to do (def (symbol "x") 2) I get: >> java.lang.Exception: Second argument to def must be a Symbol. (And >> why does it say the \second argument must be a symbol?) > > Special forms and macros don't evaluate their arguments. So def's second > argument here is a list of the symbol "symbol" and the string literal "x". > > There are two ways to do what you want: macros and eval. You might also want to look at the 'intern' function. --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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: No names with trailing % allowed but with a leading one?
Hi, Am 17.11.2009 um 19:46 schrieb Sean Devlin: I *THINK* what is meant by the "non-numeric" is anything that matches #"[a-zA-z]" Along with !,+,*,.,?,... Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Proposal: Extend behavior of hash-map
Hey everyone,
I was working with an object that implements java.util.Map today, and
I had to turn it into a Clojure map.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Map.html
I cam up with this utility fn
(defn read-map
"Designed to turn a java.util.Map into a Clojure map."
[a-map]
(into {}
(map
#(hash-map (.getKey %) (.getValue %))
(seq a-map
What if hash-map automatically cast a java.util.Map to a Clojure map?
Here's a proposed hash-map*
(defn hash-map*
([] (hash-map))
([& keyvals]
(if (= (count keyvals) 1)
(if (instance? java.util.Map (first keyvals))
(read-map (first keyvals))
(apply hash-map keyvals)) ;throws proper exception
(apply hash-map keyvals
Is this auto-casting a desired behavior? If not, does anyone want
read-map in contrib (c.c.map-utils)?
Sean
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Sean,
If the class implements Map, then it already behaves as an associative
data structure in Clojure. E.g.,
(map (fn [[k v]] (println v))
(doto (java.util.HashMap.)
(.put "foo" "bar")
(.put "baz" "noo")))
(get (doto (java.util.HashMap.)
(.put "foo" "bar")
(.put "baz" "noo")) "foo")
=> "bar"
That means you can write read-map as
(defn read-map [m]
(merge {} m))
-R
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Heh. Learn something new every day.
This also works
(into {} (System/getProperties))
On Nov 17, 4:56 pm, Richard Newman wrote:
> Sean,
>
> If the class implements Map, then it already behaves as an associative
> data structure in Clojure. E.g.,
>
> (map (fn [[k v]] (println v))
> (doto (java.util.HashMap.)
> (.put "foo" "bar")
> (.put "baz" "noo")))
>
> (get (doto (java.util.HashMap.)
> (.put "foo" "bar")
> (.put "baz" "noo")) "foo")
> => "bar"
>
> That means you can write read-map as
>
> (defn read-map [m]
> (merge {} m))
>
> -R
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
user=> (import 'java.util.HashMap)
java.util.HashMap
user=> (def m (doto (HashMap.) (.put 'a :a) (.put 'b :b)))
#'user/m
user=> m
#
user=> (into {} m)
{b :b, a :a}
user=> (class *1)
clojure.lang.PersistentArrayMap
user=>
On Tue, Nov 17, 2009 at 1:56 PM, Richard Newman wrote:
> Sean,
>
> If the class implements Map, then it already behaves as an associative
> data structure in Clojure. E.g.,
>
> (map (fn [[k v]] (println v))
> (doto (java.util.HashMap.)
> (.put "foo" "bar")
> (.put "baz" "noo")))
>
> (get (doto (java.util.HashMap.)
> (.put "foo" "bar")
> (.put "baz" "noo")) "foo")
> => "bar"
>
> That means you can write read-map as
>
> (defn read-map [m]
> (merge {} m))
>
> -R
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
> Heh. Learn something new every day. Heh. Incidentally, because of this property there are only three situations in which you need conversion at all: * To get some additional interface that Clojure's maps provides (e.g., to use them as functions) * To get persistence * To have them print readably. To just get values out, or walk the map, you don't need to do the conversion. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Sean Devlin wrote:
> Hey everyone,
> I was working with an object that implements java.util.Map today, and
> I had to turn it into a Clojure map.
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Map.html
>
> I cam up with this utility fn
>
> (defn read-map
> "Designed to turn a java.util.Map into a Clojure map."
> [a-map]
> (into {}
>(map
> #(hash-map (.getKey %) (.getValue %))
> (seq a-map
Why the (map) and seq? Does (into {} a-map) not work for some
implementations java.util.Map?
(into {}
(doto (java.util.HashMap.)
(.put :a 1)
(.put :b 2)))
;; => {:a 1, :b 2}
> What if hash-map automatically cast a java.util.Map to a Clojure map?
That'd really be changing the meaning of (hash-map) -- it doesn't even
do that with Clojure maps, you can't do (hash-map {:a 1}).
Better to stick with (into {}) -- it's actually both one character
shorter and more generally applicable.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Wow.
So this works
user=>(get (System/getProperties) "os.arch")
"x86_64"
And this does not
user=>((System/getProperties) "os.arch")
java.lang.ClassCastException: java.util.Properties cannot be cast to
clojure.lang.IFn (NO_SOURCE_FILE:0)
but this does
user=>((into {} (System/getProperties)) "os.arch")
"x86_64"
Just when I thought I knew the API... wonder what else is out there?
Sean
On Nov 17, 5:09 pm, Richard Newman wrote:
> > Heh. Learn something new every day.
>
> Heh.
>
> Incidentally, because of this property there are only three situations
> in which you need conversion at all:
>
> * To get some additional interface that Clojure's maps provides (e.g.,
> to use them as functions)
> * To get persistence
> * To have them print readably.
>
> To just get values out, or walk the map, you don't need to do the
> conversion.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Okay golfers. Is there a better way to do this?
(defn put-all!
[java-map clj-map]
(do
(doseq [entry clj-map]
(.put java-map (key entry) (val entry)))
java-map))
user=>(put-all (java.util.HashMap. ) {:a 1 :b 2 :c 3})
#
I already tried into :)
On Nov 17, 5:14 pm, Sean Devlin wrote:
> Wow.
>
> So this works
>
> user=>(get (System/getProperties) "os.arch")
> "x86_64"
>
> And this does not
>
> user=>((System/getProperties) "os.arch")
> java.lang.ClassCastException: java.util.Properties cannot be cast to
> clojure.lang.IFn (NO_SOURCE_FILE:0)
>
> but this does
>
> user=>((into {} (System/getProperties)) "os.arch")
> "x86_64"
>
> Just when I thought I knew the API... wonder what else is out there?
> Sean
>
> On Nov 17, 5:09 pm, Richard Newman wrote:
>
>
>
> > > Heh. Learn something new every day.
>
> > Heh.
>
> > Incidentally, because of this property there are only three situations
> > in which you need conversion at all:
>
> > * To get some additional interface that Clojure's maps provides (e.g.,
> > to use them as functions)
> > * To get persistence
> > * To have them print readably.
>
> > To just get values out, or walk the map, you don't need to do the
> > conversion.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Sean Devlin wrote:
> Okay golfers. Is there a better way to do this?
>
> (defn put-all!
> [java-map clj-map]
> (do
> (doseq [entry clj-map]
> (.put java-map (key entry) (val entry)))
> java-map))
>
> user=>(put-all (java.util.HashMap. ) {:a 1 :b 2 :c 3})
> #
>
> I already tried into :)
(java.util.HashMap. {:a 1 :b 2 :c 3})
=> #
Clojure maps implement java.util.Map so you can use them where'd you'd
(immutably) use most java maps.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
How about?:
(java.util.HashMap. {:a 1 :b 2 :c 3})
=> #
Mark
Sean Devlin writes:
> Okay golfers. Is there a better way to do this?
>
> (defn put-all!
> [java-map clj-map]
> (do
> (doseq [entry clj-map]
> (.put java-map (key entry) (val entry)))
> java-map))
>
> user=>(put-all (java.util.HashMap. ) {:a 1 :b 2 :c 3})
> #
>
> I already tried into :)
--
Mark Triggs
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Alex Osborne wrote:
> Sean Devlin wrote:
>> Okay golfers. Is there a better way to do this?
>>
>> (defn put-all!
>> [java-map clj-map]
>> (do
>> (doseq [entry clj-map]
>> (.put java-map (key entry) (val entry)))
>> java-map))
>>
>> user=>(put-all (java.util.HashMap. ) {:a 1 :b 2 :c 3})
>> #
>>
>> I already tried into :)
>
> (java.util.HashMap. {:a 1 :b 2 :c 3})
> => #
>
> Clojure maps implement java.util.Map so you can use them where'd you'd
> (immutably) use most java maps.
>
Although, perhaps what you were looking for is:
(doto (java.util.HashMap.)
(.putAll {:a 1 :b 2 :c 3}))
=> #
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
Very awesome. So this means you can (almost) use the putAll method.
The only catch is putAll return void (WHY!)
(defn put-all
[java-map clj-map]
(doto java-map
(.putAll clj-map)))
Sean
On Nov 17, 5:29 pm, Alex Osborne wrote:
> Sean Devlin wrote:
> > Okay golfers. Is there a better way to do this?
>
> > (defn put-all!
> > [java-map clj-map]
> > (do
> > (doseq [entry clj-map]
> > (.put java-map (key entry) (val entry)))
> > java-map))
>
> > user=>(put-all (java.util.HashMap. ) {:a 1 :b 2 :c 3})
> > #
>
> > I already tried into :)
>
> (java.util.HashMap. {:a 1 :b 2 :c 3})
> => #
>
> Clojure maps implement java.util.Map so you can use them where'd you'd
> (immutably) use most java maps.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
> The only catch is putAll return void (WHY!)
Apparently Java people like having more LOC :)
> (defn put-all
> [java-map clj-map]
> (doto java-map
>(.putAll clj-map)))
Note that this isn't limited to Clojure maps, so 'clj-map' is probably
a bad variable name. It works just as well for combining two Java maps.
(import 'java.util.Map 'java.util.HashMap)
(defn put-all
[#^Map java-map #^Map clj-map]
(doto java-map
(.putAll clj-map)))
user=> (put-all (HashMap. {:foo :bar}) (HashMap. {:bar :baz}))
#
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: def a generated symbol?
On Tue, Nov 17, 2009 at 4:22 PM, Chouser wrote: > On Tue, Nov 17, 2009 at 4:11 PM, John Harrop wrote: > > On Tue, Nov 17, 2009 at 3:59 PM, nchubrich > > wrote: > >> > >> How do you def a symbol that you make using (symbol)? I.E. if I try > >> to do (def (symbol "x") 2) I get: > >> java.lang.Exception: Second argument to def must be a Symbol. (And > >> why does it say the \second argument must be a symbol?) > > > > Special forms and macros don't evaluate their arguments. So def's second > > argument here is a list of the symbol "symbol" and the string literal > "x". > > > > There are two ways to do what you want: macros and eval. > > You might also want to look at the 'intern' function. I didn't say there were ONLY two ways. In fact I expected there'd be at least some ways involving calling Java APIs on some Clojure objects such as namespaces, though mucking about in the guts like that is even more perilous (and, particularly, prone to break when Clojure changes its internals). How stable is the intern function likely to be? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
On Tue, Nov 17, 2009 at 5:06 PM, Sean Devlin wrote:
> Heh. Learn something new every day.
>
> This also works
>
> (into {} (System/getProperties))
And I'd much prefer it. Passing a mutable Java map around to functions that
expect a map but assume it will never change out from under them creates a
grave risk that the map WILL be changed out from under them at some point.
I wonder if perhaps (into {} a-java-map) should work but no other
substitutions of a potentially-mutable map for a Clojure map.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Deep deref
> In the example I made up Tina has the friend Karl. > I can not simply store a copy of the Karl person in Tinas :friends > slot, > because when Karl gets one year older, then I don‘t want to go through > all persons, looking for Karls, and have their age updated. > Instead it is preferred to have > (defn update-age [#^String person new-age] > (dosync > (alter (get @*persons* person) assoc :age new-age))) > > When we then (update-age "Karl" 25), then the Karl in Tinas :friends > slot will also be 25. I'm just watching Rich's Value/Identity/State lecture and it occurs to me that the problem here stems from the fact that you do not have a clear idea of what a person is. Karl is still Karl, even when he gets a year older. Tina is still Tina whether she is friends with Karl or not. Yet with your representation this is not true. Karl at age 41 is not equal to Karl at age 42, because you have his age has an intrinsic part of his identity. I would suggest modelling a person as a set of properties that are immutable (at least in the model), e.g. name and date of birth. As others have suggested, I would suggest modelling the mutable relationships between people and people (friendship) or between people and other things (e.g. favourite food) as maps between immutable people objects and other immutable objects. Not as mutable fields in the person instances. http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Deep deref
On Nov 15, 9:05 am, Danny Woods wrote:
> > Danny, could you maybe hack up a possible very simple example of what
> > you mean?
>
>
>
> > I can not simply store a copy of the Karl person in Tinas :friends
> > slot,
> > because when Karl gets one year older, then I don‘t want to go through
> > all persons, looking for Karls, and have their age updated.
>
> Hi André,
>
> Your shared instance constraint does make things a little more
> interesting than in my application, but I think John's suggestion
> about not storing friend instances directly is a good thing. If you
> were to instead assign an id to each created person, and have each
> friend list be a list of ids, the entity referred to by the id can
> still be immutable for a given dereference. Not sure how much sense
> that makes, so here's something crude that I've hacked up:
>
> (def *everyone* (ref {}))
> (def *global-id* (ref 0))
>
> (defn next-id [] (dosync (commute *global-id* inc)))
>
> (defstruct person :name :friend-ids :id)
>
> (defn make-person [name] (struct person name [] (next-id)))
>
> (defn make-and-add-person [name]
> (let [person (make-person name)]
> (dosync (alter *everyone* assoc (:id person) person
>
> (defnbefriend[person friend]
> (let [new-friend-list (conj (:friend-ids person) (:id friend))
> new-person (assoc person :friend-ids new-friend-list)]
> (dosync
> (alter *everyone* assoc (:id person) new-person
>
> The 'down side' here is simply that you refer to people by ids, rather
> than directly, but the up side is that a given deref of *everyone* is
> immutable and consistent.
>
> Cheers,
> Danny.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
> I wonder if perhaps (into {} a-java-map) should work but no other
> substitutions of a potentially-mutable map for a Clojure map.
Baby, bathwater. Making a persistent map out of a Java map is
expensive. Not everything that implements Map is concrete; e.g.,
spending several seconds making a local persistent Clojure map out of
a distributed hash table proxy, just to get a value, would cause
programmers to drop down to Java to avoid this pointless restriction.
Why bother?
Shooting at targets gives you the opportunity to shoot yourself in the
foot, and that's not a bad thing.
If you want the guarantees of persistence, then by all means use
persistent structures. Programming is the act of making these choices.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
JScheme
Can anyone defend Clojure in comparision to JScheme? I want to see all pros why to learn Clojure instead of JScheme. I've found out that the java methods invocation and rest of syntax is very similar, which satisfies me since it is easier to work with lisp family languages. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Proposal: Extend behavior of hash-map
On Tue, Nov 17, 2009 at 6:24 PM, Richard Newman wrote:
> > I wonder if perhaps (into {} a-java-map) should work but no other
> > substitutions of a potentially-mutable map for a Clojure map.
>
> Baby, bathwater. Making a persistent map out of a Java map is
> expensive. Not everything that implements Map is concrete; e.g.,
> spending several seconds making a local persistent Clojure map out of
> a distributed hash table proxy, just to get a value, would cause
> programmers to drop down to Java to avoid this pointless restriction.
> Why bother?
Better let "get" still work on them too, then. :)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Datatypes and Protocols - early experience program
can anyone explain why this doesn't work?
(defprotocol arrow
(>>> ([f g] [f g & fs]) "compose left to right"))
(extend clojure.lang.Fn
arrow
{:>>> (fn
([f g] #(g (f %)))
([f g & fs] (apply >>> (>>> f g) fs)))})
(>>> inc inc inc)
; gives this error:
; java.lang.IllegalArgumentException: Wrong number of args passed to:
user$eval--21$fn--23$G--10 (test.clj:3)
this does work, however:
(>>> inc inc)
(>>> inc inc 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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: JScheme
Well, what are your needs or objectives? If you just want to do Scheme on top of Java, JScheme will be fine. The rationale behind Clojure is functional programming and concurrency: http://clojure.org/rationale For a more comprehensive answer, I'll let the man himself speaks 8) Rich does a detailed presentation of why He developed Clojure instead of using another Lisp in this presentation: http://www.lispnyc.org/wiki.clp?page=past-meetings ftp://lispnyc.org/meeting-assets/2007-11-13_clojure/clojure.mp3 If you listen to about the first 30 minutes, you'll have a clear idea of why Clojure versus any other Lisp. I bet you won't stop after 30 minutes, though, it's pretty fascinating 8) Happy exploring -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A Clojure Highlife
On Nov 16, 2:49 pm, John Harrop wrote: > For a real challenge, try implementing Hashlife using Clojure's immutable > data structures. :) This might help. http://www.ddj.com/hpc-high-performance-computing/184406478 To quote the author, Tomas G. Rokicki : "This decision lets you use a completely functional approach on an immutable data structure, assuming you enjoy such things." 8) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: JScheme
My history man be wrong, but wasn't JScheme the original starting point for DotLisp? http://dotlisp.sourceforge.net/dotlisp.htm -m -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: def a generated symbol?
On Nov 17, 5:57 pm, John Harrop wrote: > How stable is the intern function likely to be? Quite stable, I think. It's a documented function in clojure.core, not a Java method. -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: SLIME REPL broken
On Nov 17, 2:52 pm, David Nolen wrote: > Thanks for pursuing this so adamantly :) For a long time (more than a year) > it was possible to use SLIME tip. It would be great for that to continue. You can still use SLIME; just avoid the slime-autodoc contrib. Use (slime-setup '(slime-repl)) to initialize SLIME. At least, this works for me. Make sure you don't use (slime-setup '(slime-fancy)), because slime-fancy includes slime- autodoc. You lose the nicer minibuffer function argument display, but at least the basic environment works. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: def a generated symbol?
I always wondered what "intern" was for; the answer was staring me in the face On Nov 17, 9:08 pm, Stuart Sierra wrote: > On Nov 17, 5:57 pm, John Harrop wrote: > > > How stable is the intern function likely to be? > > Quite stable, I think. It's a documented function in clojure.core, > not a Java method. > > -SS -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A macro for flexible keyword argument handling
Suppose one went for broke and made a variable binding form that was 1) Maximally permissive and 2) Notationally minimal Without saying whether this is \advisable, we might agree it would be an interesting exercise. It might look like this: \All arguments are potentially keywords; and since you can't bind a value to anything but a symbol, anything in the argument list that is not a symbol is interpreted as the default value of the preceding symbol. So if you wrote (dfnsk demo1 [x y 1 z u ~x] ..) it could be called either by (demo1 1 2 3 4) or something like (demo1 :z 3 :x 2). (If you left the arguments incomplete and unkeyworded it would apply what you put preferentially to the first arguments in the list without a default value. Thus (demo1 1) would specify x and (demo1 1 2) would specify x and z.) There needs to be another way of specifying defaults, because you may want to apply the same defaults to many different values. So at the end of the list, after any &rest arguments, you could put any number of triplet vectors like [0 5 nil] or [p w 10]; where the last element is the default, and the first two are the range for the default to be applied to, specified either as a position or a variable name. When you mix keyword arguments and positional, there could be two potential interpretations. Consider (dfnsk demo2 [p q r s t u v w x y z [p z 0]] ...) If you called it like (demo2 :u 1 2 4 7), you could mean either 1) skip ahead in the list to u and fill the rest of the arguments from there or 2) 'consume' u from the list and then continue to call the list as ordered with a gap at u. So you would need an additional notation such as (demo2 :skip :u 1 2 4 7), but I'm not sure how to do that without potential name conflicts. Finally, you would have a set of predicates that tell you 1) how many arguments have been supplied and 2) whether a given argument has been supplied (as Constantine has done). You could make your defaults if expressions or cond expressions using these predicates (and whatever else you might want to pend on). You could say, "if x has not been supplied, make y 2, etc." This could be an alternative (and I guess more general) way of notating variable arity argument lists. . I'm not trying to start an argument over whether this would be too complicated or tricky to use in practice (though this is a good argument to have too); my immediate question is, can it be any more general or minimal than this? Maybe there is some really neat way of encoding arbitrary preference rules and priorities in an argument list. It's not occurring to me though. In any case, the 'complication' is mostly an artifact of the way we program. If we move a little away from a pure program text and nothing-but while programming (as IDE's effectively do), we get all sorts of feedback and help on argument lists, so that it becomes in part like filling out a form when that helps; and hopefully this feedback ends up being not too intrusive or distracting. That, however, is a question for the \en\clojure list. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A macro for flexible keyword argument handling
(preceding message, re-formatted) Suppose one went for broke and made a variable binding form that was 1) Maximally permissive and 2) Notationally minimal Without saying whether this is \advisable, we might agree it would be an interesting exercise. It might look like this: \All arguments are potentially keywords; and since you can't bind a value to anything but a symbol, anything in the argument list that is not a symbol is interpreted as the default value of the preceding symbol. So if you wrote (dfnsk demo1 [x y 1 z u ~x] ..) it could be called either by (demo1 1 2 3 4) or something like (demo1 :z 3 :x 2) (If you left the arguments incomplete and unkeyworded it would apply what you put preferentially to the first arguments in the list without a default value. Thus (demo1 1) would specify x and (demo1 1 2) would specify x and z.) There needs to be another way of specifying defaults, because you may want to apply the same defaults to many different values. So at the end of the list, after any &rest arguments, you could put any number of triplet vectors like [0 5 nil] or [p w 10]; where the last element is the default, and the first two are the range for the default to be applied to, specified either as a position or a variable name. When you mix keyword arguments and positional, there could be two potential interpretations. Consider (dfnsk demo2 [p q r s t u v w x y z [p z 0]] ...) If you called it like (demo2 :u 1 2 4 7) you could mean either 1) skip ahead in the list to u and fill the rest of the arguments from there or 2) 'consume' u from the list and then continue to call the list as ordered with a gap at u. So you would need an additional notation such as (demo2 :skip :u 1 2 4 7) but I'm not sure how to do that without potential name conflicts. Finally, you would have a set of predicates that tell you 1) how many arguments have been supplied and 2) whether a given argument has been supplied (as Constantine has done). You could make your defaults if expressions or cond expressions using these predicates (and whatever else you might want to pend on). You could say, "if x has not been supplied, make y 2, etc." This could be an alternative (and I guess more general) way of notating variable arity argument lists. . I'm not trying to start an argument over whether this would be too complicated or tricky to use in practice (though this is a good argument to have too); my immediate question is, can it be any more general or minimal than this? Maybe there is some really neat way of encoding arbitrary preference rules and priorities in an argument list. It's not occurring to me though. In any case, the 'complication' is mostly an artifact of the way we program. If we move a little away from a pure program text and nothing-but while programming (as IDE's effectively do), we get all sorts of feedback and help on argument lists, so that it becomes in part like filling out a form when that helps; and hopefully this feedback ends up being not too intrusive or distracting. That, however, is a question for the \en\clojure list. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why a defn- but not a def- ?
On Sat, Nov 14, 2009 at 14:55, Albert Cardona wrote:
> On Fri, Nov 13, 2009 at 11:26 PM, Mike Hogye wrote:
>> Why is there an easy way to def a private function (defn-), but no
>> similarly easy way to def an arbitrary var as private?
>
>
> The way I see it, def- would encourage gratuitous variable declaration
> imperative style.
Not necessarily.
I find myself quite often writing code like this:
(defn some-general-fn [a b c d] ...)
(def some-concrete-application-of-fn-above (partial some-general-fn 42))
Having def- would be cool for such constructs.
For example this converts values in a map to json-encoded strings:
(defn- vals-lift [f m]
(reduce (fn [acc [k v]] (assoc acc k (f v))) {} (seq m)))
(def #^{:private true} vals2json (partial vals-lift json-str))
[
http://github.com/kunley/clojure-couchdb/blob/master/src/couchdb/client.clj#L206
]
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: why a defn- but not a def- ?
On Nov 14, 1:50 pm, John Harrop wrote: > On Sat, Nov 14, 2009 at 8:55 AM, Albert Cardona wrote: > > On Fri, Nov 13, 2009 at 11:26 PM, Mike Hogye > > wrote: > > > Why is there an easy way to def a private function (defn-), but no > > > similarly easy way to def an arbitrary var as private? > > > The way I see it, def- would encourage gratuitous variable declaration > > imperative style. > > > By private var what one means is a local variable. > > > If you want a private variable use a let binding: > > > (let [my-private-var "Something not to be shared"] > > (defn my-public-fn > > "Do something" > > [a b] > > (str a b my-private-var))) > > > If you need the private variable to be mutable, use a ref and dosync > > changes on it. That goes a long way towards correctness. > > I find top-level lets to be messy compared to defining global constants like > this: > > (def +the-constant+ value) > > There's a defvar that adds docstring capability to def, and a private-making > version defvar-, in clojure.contrib.def. > > My own style preference would be to put important constants in defs at the > top of the file, rather than use let or (worse) embed "magic numbers" or the > like in individual functions that might need to be tweaked. Constants that > are truly constant because they're forced to be by math, the algorithm used, > or whatever might be locally letted in the function that uses them, to name > them while keeping them with the rest of the algorithm, though. Whether or not top level lets are messy, don't you take a performance hit for using a def? Semantically, I would think that the let is also closer to a constant, as it can't be rebound (whereas a def can be rebound thread-locally). Although I suppose the most constant-like solution would be to use a symbol macro (I think there is a version in contrib). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: SLIME REPL broken
Stefan Kamphausen writes: >> Unless there are some really great features added upstream in slime, >> fixing swank-clojure to work with their latest changes is a low priority. > > this is a pity, at least for those of us, who also use Slime to do > some CL hacking. For that setup it is quite common to always update > to CVS head because that may be the only version working with current > releases of, e.g., SBCL. Well, currently I don't really do CL stuff, > it's just that I set up another machine doing lots of VC-checkouts... > I could just copy an older version of Slime there. > > I'll take a look at it the next few days (er, evenings that is), if I > find the time. No promises ;-) Cool. I don't mean to discourage this work, I just mean that I have little personal motivation to implement it myself. > Over there at Slime's people are thinking, the Clojure family forked > Slime, maybe that's not the worst idea. Things would probably get > easier if there were only one backend to support. Honestly I don't know the server-side bit of swank-clojure that well; I've mostly been focusing on the elisp side. So I don't know the protocol that well myself; the server-side stuff was mostly written by jochu, the original author. -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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] leiningen - a Clojure build tool
I'm pleased to announce the initial release of Leiningen. Leiningen is a build tool for Clojure designed to not set your hair on fire. Building Clojure projects with tools designed for Java can be an exercise in frustration. If you use Ant, you end up copying around a lot of the same tasks around between XML files on all your projects; there's a lot of repetition. Maven avoids repetition, but provides very little transparency into what's really going on behind the scenes and forces you to become a Maven expert to script a nontrivial build. Either way you end up writing far more XML than is necessary. With Leiningen, your build is described using Clojure. You can put any code you like in your project.clj file; the only requirement is that it includes a call to defproject. You can define your own tasks in there if you need to, but the majority of projects should be able to get by on the tasks that are provided with Leiningen. If you do find a common task that you need to add, you can implement it as a plugin rather than copying and pasting among each of your projects. Projects are defined with Clojure syntax, (not XML!) in project.clj: (defproject leiningen "0.5.0" :description "A build tool designed not to set your hair on fire." :main leiningen.core :dependencies [[org.clojure/clojure "1.1.0-alpha-SNAPSHOT"] [org.clojure/clojure-contrib "1.0-SNAPSHOT"] [ant/ant-launcher "1.6.2"] [org.apache.maven/maven-ant-tasks "2.0.10"]] :dev-dependencies [[org.clojure/swank-clojure "1.0"]]) A number of tasks are provided: $ lein deps # install dependencies in lib/ $ lein test [PRED] # run the project's tests, optionally filtered on PRED $ lein compile # ahead-of-time compile into classes/ $ lein repl # launch a REPL with the project classpath configured $ lein clean # remove all build artifacts $ lein jar # create a jar of the project $ lein uberjar # create a standalone jar that contains all dependencies $ lein pom # output a pom.xml file for interop with Maven $ lein install # install in local repo (currently requires mvn) $ lein help [TASK] # show a list of tasks or help for a given TASK Leiningen is extensible, you can define new tasks in project.clj or in plugins. Add your plugin as a dev-dependency of your project, and you'll be able to call "lein $YOUR_COMMAND". See the lein-swank directory for an example of a plugin. To install simply download the shell script, place it somewhere on your $PATH, and run "lein self-install": http://github.com/technomancy/leiningen/raw/master/bin/lein Many people have expressed frustration at trying to use a tool designed for Java with their Clojure projects, especially when dealing with dependencies. I hope this can move things forward and ease the pain. Note that it's still a very young project, (started about two weeks ago), but in classic Clojure fashion it is able to leverage a lot of functionality from other JVM tools. Please try it out and let me know how it works for your project! thanks, Phil Bonus: Leiningen also integrates with the Clojars open-source clojure-specific repository coming soon at http://clojars.org. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] leiningen - a Clojure build tool
Awesomeness. On Wed, Nov 18, 2009 at 2:29 AM, Phil Hagelberg wrote: > > I'm pleased to announce the initial release of Leiningen. > > Leiningen is a build tool for Clojure designed to not set your hair on > fire. > > Building Clojure projects with tools designed for Java can be an > exercise in frustration. If you use Ant, you end up copying around a > lot of the same tasks around between XML files on all your projects; > there's a lot of repetition. Maven avoids repetition, but provides > very little transparency into what's really going on behind the scenes > and forces you to become a Maven expert to script a nontrivial > build. Either way you end up writing far more XML than is necessary. > > With Leiningen, your build is described using Clojure. You can put any > code you like in your project.clj file; the only requirement is that > it includes a call to defproject. You can define your own tasks in > there if you need to, but the majority of projects should be able to > get by on the tasks that are provided with Leiningen. If you do find a > common task that you need to add, you can implement it as a plugin > rather than copying and pasting among each of your projects. > > Projects are defined with Clojure syntax, (not XML!) in project.clj: > >(defproject leiningen "0.5.0" > :description "A build tool designed not to set your hair on fire." > :main leiningen.core > :dependencies [[org.clojure/clojure "1.1.0-alpha-SNAPSHOT"] > [org.clojure/clojure-contrib "1.0-SNAPSHOT"] > [ant/ant-launcher "1.6.2"] > [org.apache.maven/maven-ant-tasks "2.0.10"]] > :dev-dependencies [[org.clojure/swank-clojure "1.0"]]) > > > A number of tasks are provided: > >$ lein deps # install dependencies in lib/ > >$ lein test [PRED] # run the project's tests, optionally filtered on > PRED > >$ lein compile # ahead-of-time compile into classes/ > >$ lein repl # launch a REPL with the project classpath configured > >$ lein clean # remove all build artifacts > >$ lein jar # create a jar of the project > >$ lein uberjar # create a standalone jar that contains all dependencies > >$ lein pom # output a pom.xml file for interop with Maven > >$ lein install # install in local repo (currently requires mvn) > >$ lein help [TASK] # show a list of tasks or help for a given TASK > > Leiningen is extensible, you can define new tasks in project.clj or in > plugins. Add your plugin as a dev-dependency of your project, and you'll > be able to call "lein $YOUR_COMMAND". See the lein-swank directory for > an example of a plugin. > > To install simply download the shell script, place it somewhere on your > $PATH, and run "lein self-install": > > http://github.com/technomancy/leiningen/raw/master/bin/lein > > Many people have expressed frustration at trying to use a tool designed > for Java with their Clojure projects, especially when dealing with > dependencies. I hope this can move things forward and ease the > pain. Note that it's still a very young project, (started about two > weeks ago), but in classic Clojure fashion it is able to leverage a lot > of functionality from other JVM tools. > > Please try it out and let me know how it works for your project! > > thanks, > Phil > > Bonus: Leiningen also integrates with the Clojars open-source > clojure-specific repository coming soon at http://clojars.org. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
