Primitive arithmetic and mod
I'm trying to speed up computing terms of a simple recurrence where the terms are computed modulo some value each iteration, (defn NF-mod-limit [p q limit] (loop [n 0, nf 0, z 0, S 290797] (if (= n (inc q)) nf (recur (inc n) (mod (+ nf (* (mod S p) z)) limit) (mod (inc (* p z)) limit) (mod (* S S) 50515093)) So I added in some type hinting, (defn NF-mod-limit [p q limit] (let [p (long p) q (long q) limit (long limit)] (loop [n (long 0), nf (long 0), z (long 0), S (long 290797)] (if (= n (inc q)) nf (recur (inc n) (long (mod (+ nf (* (long (mod S p)) z)) limit)) (long (mod (inc (* p z)) limit)) (long (mod (* S S) 50515093))) But it doesn't run any faster. Also it doesn't work without casting to long within the recur. Is that maybe a problem with mod and primitive arithmetic or does this simply not speed up any more in 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: rand-int with bignums
Per Alex Osborne's reference to BigInteger constructors, here's a random BigInteger function: (defn rand-bigint [#^BigInteger bign, #^Random rnd] (let [bits (inc (.bitLength bign)) bigr (BigInteger. bits rnd)] (-> bign (.multiply bigr) (.shiftRight bits -- You 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: Any Clojure job out there?
The latest Thoughtworks technology radar says that clojure is the best of the functional languages out there at the moment. I'm hoping this will lead to greater adoption. http://www.thoughtworks.com/radar/ FTA: Of the current crop of functional languages, the one we like the most is Clojure: a simple, elegant implementation of Lisp on the JVM. The other two that we find interesting are Scala (a re-thinking of Java in functional form) and F#, the OCaml derivative from Microsoft that now appears “in the box” in Visual Studio 2010. cheers, Bruce -- You 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: labrepl updated
More than one clojure or contrib jar file one the classpath, perhaps. Can you try starting the labrepl from the command line and see if you get the same error? Stu I'm getting this error in Eclipse: Clojure 1.2.0-master-SNAPSHOT 1:1 user=> * (require 'labrepl) * (labrepl/-main) # java.lang.ExceptionInInitializerError (control.clj:9) 1:2 user=> # 1:3 user=> java.lang.Exception: No such var: labrepl/-main (repl-1:2) Do you maybe have an idea what I'm doing wrong? On Apr 30, 2:56 pm, Stuart Halloway wrote: I have updated the labrepl [1] to use the latest clojure 1.2 and contrib 1.2 snapshots. Also, most of the dependencies are now frozen to specific snapshot timestamps (the project.clj file may be of interest to people living on the development edge). After a "lein clean; lein deps" everything should work, please let me know if you see otherwise. Have a good weekend! Stu [1]http://github.com/relevance/labrepl -- You 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 athttp://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 -- You 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: labrepl updated
Can you send your .project and .classpath files, for analysis ? (Place them in the files section of the google group, please) 2010/5/1 Keno : > I'm getting this error in Eclipse: > > Clojure 1.2.0-master-SNAPSHOT > 1:1 user=> * (require 'labrepl) > * (labrepl/-main) > # > java.lang.ExceptionInInitializerError (control.clj:9) > 1:2 user=> # > 1:3 user=> java.lang.Exception: No such var: labrepl/-main (repl-1:2) > > Do you maybe have an idea what I'm doing wrong? > > On Apr 30, 2:56 pm, Stuart Halloway wrote: >> I have updated the labrepl [1] to use the latest clojure 1.2 and >> contrib 1.2 snapshots. Also, most of the dependencies are now frozen >> to specific snapshot timestamps (the project.clj file may be of >> interest to people living on the development edge). >> >> After a "lein clean; lein deps" everything should work, please let me >> know if you see otherwise. >> >> Have a good weekend! >> >> Stu >> >> [1]http://github.com/relevance/labrepl >> >> -- >> You 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 >> athttp://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 -- You 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: Defining a namespace inside a let
Hello Stuart,
"they don't work as you'd expect".
Ah, I see. Thank you ;-)
Hm. Can you point me to some documentation about these special rules
then?
Many thanks, alux
On 30 Apr., 18:10, Stuart Sierra wrote:
> "ns" and "in-ns" have special evaluation rules. In general, they
> don't work as you'd expect in block expressions such as "do" or "let".
>
> If you want to create namespaces programatically, use "create-ns" and
> "intern".
>
> -SS
>
> On Apr 26, 6:25 pm, David McNeil wrote:
>
>
>
> > I am experimenting with clojure.test and I encountered the following
> > situation which I cannot explain.
>
> > This code:
>
> > (println (do
> > (ns ns01
> > (:use clojure.test))
> > (deftest test1 nil)
> > (run-tests)))
>
> > Produces the expected result (note: it runs one test):
>
> > Testing ns01
>
> > Ran 1 tests containing 0 assertions.
> > 0 failures, 0 errors.
> > {:type :summary, :test 1, :pass 0, :fail 0, :error 0}
>
> > However, if I do the exact same thing inside of a let:
>
> > (println (let []
> > (do
> > (ns ns02
> > (:use clojure.test))
> > (deftest test1 nil)
> > (run-tests
>
> > Then I get the unexpected result that no tests are executed:
>
> > Testing ns02
>
> > Ran 0 tests containing 0 assertions.
> > 0 failures, 0 errors.
> > {:type :summary, :test 0, :pass 0, :fail 0, :error 0}
>
> > Seems there is something going on with namespaces that I do not
> > understand and I hope that somewhere here can explain it.
>
> > Thank you.
> > -David McNeil
>
> > --
> > You 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
> > athttp://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
> athttp://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
Funcalls vs. lists (Was: Clojure Concurrency Screencast Available)
On Sun, 02 May 2010 13:06:56 +1000
Alex Osborne wrote:
> e writes:
> > Can you imagine how disruptive it would be at this point to do it the
> > other way around? If you were starting out today without any Lisp
> > baggage, it seems TOTALLY obvious to me that lists would have been (1
> > 2 3), and the *calling of a function* would have been the different
> > thing ... now that these other data structures represent themselves
> > symbolically (vectors, sets, maps).
> Interesting, although in the case of idiomatic Clojure it's actually
> very rare to want to use a list literal. Most of the places you'd use a
> list literal in other lisps, a vector probably makes more sense in
> Clojure.
That was my conclusion as well - pragmatically, you want the shorter
construct for the more common use case.
> I'm also not sure the code-is-data thing works so well when
> you reverse quotation like that as it means you'd have quotes on every
> nested level instead of just the outside, which would make macros more
> difficult to write (at least without any other changes), but I may be
> misunderstanding your idea.
I thought that as first, but then realized that you'd still want quote
even if you had this change, because quote is more than just a
symbolic representation of the list. It stops the evaluation of the
contents of the list, which the other symbolic representations don't
do. So [1 2 3 (print :hello)] will print the keyword :hello, then
return [1 2 3 nil], but '(1 2 3 (print :hello)) doesn't print
anything, and returns a list with four elements - 1, 2, 3 and the list
with two elements, the symbol print and the keyword :hello. This
should be compared with '[1 2 3 (print :hello)].
To get behavior similar to the vector constructs, you want to use
list, which works like vector, except returning a list instead of a
vector: (list 1 2 3 (print :hello)). It seems that what's missing here
is a syntax for (list. I'm not sure it's needed, as it never appeared
in LISP, but #[ seems to be the logical candidate:
{ - hash-map #{ - hash-set [ - vector#[ - list
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.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: Funcalls vs. lists (Was: Clojure Concurrency Screencast Available)
On May 2, 11:14 pm, Mike Meyer wrote:
> On Sun, 02 May 2010 13:06:56 +1000
> To get behavior similar to the vector constructs, you want to use
> list, which works like vector, except returning a list instead of a
> vector: (list 1 2 3 (print :hello)). It seems that what's missing here
> is a syntax for (list. I'm not sure it's needed, as it never appeared
> in LISP, but #[ seems to be the logical candidate:
>
> { - hash-map #{ - hash-set [ - vector #[ - list
>
Hmmh. I haven't read the discussion very carefully but it seems there
might be a fundamental misunderstanding here somewhere.
The thing is that (foo bar) *is* a list of two symbols, even if not
quoted. It just so happens that when such a list is passed to the
evaluator, it evaluates it as a function call. Similarly, [foo bar] is
*not* a shortcut for (vector foo bar); it *is* a vector of two
symbols, and vectors just have different evaluation semantics. The
same applies to sets and maps.
The best you'd get out of a #[foo bar] is a simple reader macro that
expands to (list foo bar) and that's really just a waste of macro
characters, not to mention confusing. Or you would have to have a list
type that isn't evaluated as a function call. But that path leads to
insanity.
--
You 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: My non-ELPA Emacs swank-clojure setup
Am Sonntag, 11. April 2010 00:59:47 schrieb DanL: > On 11 Apr., 00:34, Ævar Arnfjörð Bjarmason wrote: > > > As far as I know, there were problems with the protocol using symbols > > > in CL's package::symbol syntax (and some other characters not being > > > allowed in Clojure) after changes in CVS Slime about five months ago. > > > > So it would just need to use a sexp parser instead of directly > > interning the foreign symbols? Not that I'm volunteering or anything > > A small custom reader would be part of the solution, I guess. IIRC there has been some work on slime making a thin RPC layer. I haven't looked recently how far that one has come. Unfortunatly I am not in the position to contribute patches, but I think that swank-clojure should consider adopting this protocol, although I don't think there are any promisies regarding stability. Robert -- You 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: Funcalls vs. lists (Was: Clojure Concurrency Screencast Available)
On Sun, 2 May 2010 14:52:17 -0700 (PDT)
Jarkko Oranen wrote:
> On May 2, 11:14 pm, Mike Meyer 620...@mired.org> wrote:
> > On Sun, 02 May 2010 13:06:56 +1000
> > To get behavior similar to the vector constructs, you want to use
> > list, which works like vector, except returning a list instead of a
> > vector: (list 1 2 3 (print :hello)). It seems that what's missing here
> > is a syntax for (list. I'm not sure it's needed, as it never appeared
> > in LISP, but #[ seems to be the logical candidate:
> >
> > { - hash-map #{ - hash-set [ - vector #[ - list
>
> Hmmh. I haven't read the discussion very carefully but it seems there
> might be a fundamental misunderstanding here somewhere.
No, just a failure to look past syntax at the implementation.
> The thing is that (foo bar) *is* a list of two symbols, even if not
> quoted. It just so happens that when such a list is passed to the
> evaluator, it evaluates it as a function call. Similarly, [foo bar] is
> *not* a shortcut for (vector foo bar); it *is* a vector of two
> symbols, and vectors just have different evaluation semantics. The
> same applies to sets and maps.
Presumably because the reader returns those structures, and the
evaluator evaluates the symbols they contain, but doesn't do the
implied function call that it does for lists.
> The best you'd get out of a #[foo bar] is a simple reader macro that
> expands to (list foo bar) and that's really just a waste of macro
> characters, not to mention confusing. Or you would have to have a list
> type that isn't evaluated as a function call. But that path leads to
> insanity.
Well, implementing it that way would be easy, but it wouldn't be
right. #[ should cause the reader to emit a list that the evaluator
doesn't treat as a function invocation, not the code to construct
one. Otherwise, the semantics would be wrong.
But you echoed my main concern about it - 50 years of LISP hasn't
caused anyone to want a shorthand for (list .., otherwise it'd be a
standard CLISP reader macro, indicating that "waste of macro
characters" is probably right.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.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
Calling for advice on a parser's location data
I'm making a parsing library that can keep track of its location in a
stream of tokens, and the tokens can be of any type—character, map,
and so forth. I need advice on this question:
Can you think of an instance where the location would not be a line
number and column number, such as {:line 3, :column 25}?
I'm deciding if I should bother with the trouble of making the
location data structure independent and pluggable with my parser, or
if I should make it always a line-column pair, which would make the
API much simpler.
--
You 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
HOWTO http.agent ( PUT or potential 500 )
Hey, ok so a noobie question here. I'm trying to use the 'http-agent'
function to make HTTP calls. I can do so easily as in fig. 1. But when I try
to make a PUT call as in fig. 2, I get a pretty ugly stacktrace, the bottom
one having the error "Caused by: java.lang.IllegalArgumentException: No
method in multimethod 'send-request-entity' for dispatch value: class
clojure.lang.PersistentStructMap" (fig. 3).
I figure I'm doing something dumb here but can't figure out what...
1) I've tried adding a no-op handler function (fn [agnt] ) to see if the
error goes away - nope.
2) I tried adding the example handler function that writes the response
directly to dis - no dice
:handler (fn [agnt] (with-open [w
(clojure.contrib.io/writer"/tmp/out")](
clojure.contrib.io/copy (clojure.contrib.http.agent/stream agnt) w)))
Is there anything obvious I'm missing here?
Thanks
=
(require 'clojure.contrib.http.agent)
(let [thing (clojure.contrib.http.agent/result
(clojure.contrib.http.agent/http-agent "http://google.com"; :method "GET" )
)]
(. System/out println thing)
)
fig. 1
=
(use 'clojure.xml);; use XML library
(def myXML (parse "")) ;; load XML from file
(require 'clojure.contrib.http.agent) ;; use HTTP client library
(require 'clojure.contrib.io)
;; connect to a eXist server ; push the XML object out
(clojure.contrib.http.agent/result (clojure.contrib.http.agent/http-agent
"http://"
:method "PUT"
:header {"Content-Type" "text/xml"}
:body myXML)
)
fig. 2
=
Caused by: java.lang.Exception: Agent has errors
at clojure.lang.Agent.deref(Agent.java:129)
...
at clojure.lang.Agent$Action.run(Agent.java:106)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.IllegalArgumentException: No method in multimethod
'send-request-entity' for dispatch value: class
clojure.lang.PersistentStructMap
at clojure.lang.MultiFn.getFn(MultiFn.java:115)
at clojure.lang.MultiFn.invoke(MultiFn.java:161)
at
clojure.contrib.http.connection$start_http_connection__511.invoke(connection.clj:58)
at clojure.contrib.http.agent$start_request__526.invoke(agent.clj:92)
at clojure.lang.AFn.applyToHelper(AFn.java:175)
... 6 more
fig. 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: Calling for advice on a parser's location data
On Sun, May 2, 2010 at 6:29 PM, joshua-choi wrote:
> I'm making a parsing library that can keep track of its location in a
> stream of tokens, and the tokens can be of any type—character, map,
> and so forth. I need advice on this question:
>
> Can you think of an instance where the location would not be a line
> number and column number, such as {:line 3, :column 25}?
Binary input wouldn't be required to have a concept of lines or columns.
> I'm deciding if I should bother with the trouble of making the
> location data structure independent and pluggable with my parser, or
> if I should make it always a line-column pair, which would make the
> API much simpler.
The clj-peg library requires pre-wrapping any input to be parsed in an
interface that provides quite a bit of flexibility like this.
I would agree that it makes it more complicated though.
-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
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: Calling for advice on a parser's location data
Unless you're dealing with 1) binary data or 2) structured data (ie. XML)
where a path is more appropriate, then I think line / column is the way to
go.
Now, is this a clojure parser? Or a clojure parser generator library that
consumes a BNF-like file that defines another lang? As far as I can tell,
clojure doesn't have one. I have a recent project where clojure is pointing
to a SableCC BNF generated Lexer and Parser file. That project might give
you some ideas.
HTH
Tim
On Sun, May 2, 2010 at 8:29 PM, joshua-choi wrote:
> I'm making a parsing library that can keep track of its location in a
> stream of tokens, and the tokens can be of any type—character, map,
> and so forth. I need advice on this question:
>
> Can you think of an instance where the location would not be a line
> number and column number, such as {:line 3, :column 25}?
>
> I'm deciding if I should bother with the trouble of making the
> location data structure independent and pluggable with my parser, or
> if I should make it always a line-column pair, which would make the
> API much simpler.
>
> --
> You 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: HOWTO http.agent ( PUT or potential 500 )
On 03/05/2010, at 10:47 AM, Timothy Washington wrote: > Hey, ok so a noobie question here. I'm trying to use the 'http-agent' > function to make HTTP calls. I can do so easily as in fig. 1. But when I try > to make a PUT call as in fig. 2, I get a pretty ugly stacktrace, the bottom > one having the error "Caused by: java.lang.IllegalArgumentException: No > method in multimethod 'send-request-entity' for dispatch value: class > clojure.lang.PersistentStructMap" (fig. 3). > > I figure I'm doing something dumb here but can't figure out what... > 1) I've tried adding a no-op handler function (fn [agnt] ) to see if the > error goes away - nope. > 2) I tried adding the example handler function that writes the response > directly to dis - no dice > :handler (fn [agnt] (with-open [w (clojure.contrib.io/writer > "/tmp/out")](clojure.contrib.io/copy (clojure.contrib.http.agent/stream > agnt) w))) > > Is there anything obvious I'm missing here? The error is that it can't send your XML as the body. Convert the XML to a string and send that. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- You 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: HOWTO http.agent ( PUT or potential 500 )
Yes, that was it. Thanks On Sun, May 2, 2010 at 10:04 PM, Antony Blakey wrote: > > On 03/05/2010, at 10:47 AM, Timothy Washington wrote: > > > Hey, ok so a noobie question here. I'm trying to use the 'http-agent' > function to make HTTP calls. I can do so easily as in fig. 1. But when I try > to make a PUT call as in fig. 2, I get a pretty ugly stacktrace, the bottom > one having the error "Caused by: java.lang.IllegalArgumentException: No > method in multimethod 'send-request-entity' for dispatch value: class > clojure.lang.PersistentStructMap" (fig. 3). > > > > I figure I'm doing something dumb here but can't figure out what... > > 1) I've tried adding a no-op handler function (fn [agnt] ) to see if the > error goes away - nope. > > 2) I tried adding the example handler function that writes the response > directly to dis - no dice > > :handler (fn [agnt] (with-open [w > > (clojure.contrib.io/writer"/tmp/out")]( > clojure.contrib.io/copy (clojure.contrib.http.agent/stream agnt) w))) > > > > Is there anything obvious I'm missing here? > > The error is that it can't send your XML as the body. Convert the XML to a > string and send that. > > Antony Blakey > - > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Every task involves constraint, > Solve the thing without complaint; > There are magic links and chains > Forged to loose our rigid brains. > Structures, structures, though they bind, > Strangely liberate the mind. > -- James Fallen > > > -- > You 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
clojure-contrib diffs?
I've noticed that there are some big clojure-contrib source differences between the 'master' branch and '1.1.0'. For example 1) 'io' is in master, but not 1.1.0 2) json is in master, but json.read and json.write are in 1.1.0 I assume new developments are going into 1.1.0. But is it possible to keep track of the lost libs like io? These are the sources I'm looking at. - http://richhickey.github.com/clojure-contrib/ - http://richhickey.github.com/clojure-contrib/branch-1.1.x/index.html 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 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: My non-ELPA Emacs swank-clojure setup
On Mon, May 3, 2010 at 3:43 AM, Robert Ewald wrote: > Am Sonntag, 11. April 2010 00:59:47 schrieb DanL: >> On 11 Apr., 00:34, Ævar Arnfjörð Bjarmason wrote: >> > > As far as I know, there were problems with the protocol using symbols >> > > in CL's package::symbol syntax (and some other characters not being >> > > allowed in Clojure) after changes in CVS Slime about five months ago. >> > >> > So it would just need to use a sexp parser instead of directly >> > interning the foreign symbols? Not that I'm volunteering or anything >> >> A small custom reader would be part of the solution, I guess. > > IIRC there has been some work on slime making a thin RPC layer. I haven't > looked recently how far that one has come. Unfortunatly I am not in the > position to contribute patches, but I think that swank-clojure should consider > adopting this protocol, although I don't think there are any promisies > regarding stability. Terje Norderhaug implemented it and is already in use in the latest swank-clojure. -- Ramakrishnan -- You 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-contrib diffs?
On 03/05/2010, at 1:06 PM, Timothy Washington wrote: > I've noticed that there are some big clojure-contrib source differences > between the 'master' branch and '1.1.0'. For example 1) 'io' is in master, > but not 1.1.0 2) json is in master, but json.read and json.write are in 1.1.0 > > I assume new developments are going into 1.1.0. But is it possible to keep > track of the lost libs like io? These are the sources I'm looking at. > • http://richhickey.github.com/clojure-contrib/ > • http://richhickey.github.com/clojure-contrib/branch-1.1.x/index.html 1.1.0 is stable. The git master is the upcoming 1.2.0 BTW: You can't depend on *anything* in contrib. It's not part of standard clojure (despite IMO being implicitly promoted that way on clojure.org) and there are no guarantees about backwards compatibility. It's been stated that contrib is a playground for new ideas that might make it into core clojure. Of course, there are many useful libraries that are only available in contrib - contrib acts as a magnet, and then infects all those useful libraries with it's "you shouldn't be using me" status. I'd like to advise you to only rely on single-purpose packages you find through dependency resolution (maven or lein) rather then the one-version-fits-all you're-a-fool-if-you-use-this indispensable big bundle of stuff that is contrib. But IMO that's not really feasible. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. -- Steve Jobs -- You 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: Calling for advice on a parser's location data
On May 3, 2010, at 3:29 , joshua-choi wrote:
> Can you think of an instance where the location would not be a line
> number and column number, such as {:line 3, :column 25}?
I'd also add :file there (while this does not need to be a physical one it can
come in handy)
--
You 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
