Re: Aquamacs Preferences.el
If it is only on directory and you are using a recent version of Java / * will pick up all jars in the directory. /mac On Nov 10, 5:08 am, Sean Devlin wrote: > Hello all, > I'm trying to add a directory to my classpath in Aquamacs. How do I > do this recusively? Here's what I've got right now > > (setq swank-clojure-extra-classpaths (list > ...lots-of-jars... > "~/Applications/clojure-apps/swing-test/")) > > Can somebody give me a hand? > > Thanks! -- You 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: Boggle solver
C and Common Lisp versions here --> http://code.google.com/p/boggle-solvers/ Both use the same algorithm and data structures as far as possible. The C version can solve a 1000x1000 board in about 40 seconds. The CL version solves a 1000x1000 board in about 65 seconds on a dual core laptop. Haven't yet implemented a Clojure version. That would be interesting for comparison ... On Nov 7, 12:11 am, james wrote: > Hey! > > As a learning exercise I wrote a simple boggle solver in clojure. > I'm sure there is lots of room for improvement to make it more > idiomatic and perform better so I would be grateful if anyone would > care to cast their eye over it. > > http://wiki.github.com/phraemer/Boggle-Solver > > thanks, > > James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Boggle solver
Please, do as you will with my code! It's free for all to play with. TBH, I'm delighted that someone else can find use for it. I'd love to see what improvements you could make. I've also now posted up on the wiki page some plots of the performance using Incanter http://wiki.github.com/phraemer/Boggle-Solver I tested this against a friends very neat (but not optimised) c++ implimentation and it's only slightly faster as far as I can tell. I suspect that some clever people on here could easily get better performance out of my version and yet keep it idiomatic. (Come on you guys and gals ;)) What I do love is that it would be trivial to parallelise this in Clojure with no risk of locking, but still the most interesting thing right now is tackling the single threaded performance. On Nov 10, 10:53 am, william douglas wrote: > Very nice, I had actually been implementing a boggle solver for my > optimal boggle grid generator (5x5 with no limits on number of letters > on dice). I hadn't discovered the wonders of assoc-in though which > makes things look much nicer when creating nested maps. I really like > the layout of your code in general too though I'm a beginner with > clojure myself. > > Mind if I fork your solution into mine for the grid creation as your > solver has very nice performance? > > -William -- You 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
filter using foldr point-free?
Hi, We can define filter using foldr as under: filter1 p = foldr (\x xs -> (if (p x) then (x:xs) else xs)) [] Can we define filter using foldr but in pointfree style? How? Thanks -DM -- You 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: Avoiding reflection/hinting with byte-array.
On Sat, Nov 7, 2009 at 3:13 PM, Chouser wrote: > > On Sat, Nov 7, 2009 at 2:57 PM, David Brown wrote: >> >> On Sat, Nov 07, 2009 at 11:48:32AM -0500, Chouser wrote: >> >>>This should work: >>> >>> (defn update1 [#^MessageDigest md, #^bytes item] >>> (.update md item)) >> >> This does seem to work, thanks. >> >> Any reason that 'doubles' is also defined as an array cast function, >> but 'bytes' is not? > > I don't know of any deep reason. > > Not only bytes, but also array-cast functions don't exist for > chars, shorts or booleans. > > Also there are factory functions for several primitive array > types, but char-array, short-array, byte-array, and > boolean-array don't exist. > There is no deep reason. Patch welcome for unifying the array support for primitives. 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: Consistency of the API
On Mon, Nov 9, 2009 at 3:31 PM, Mark Engelberg wrote: > > 2009/11/9 Tiago Antão : >> What is the rationale for even? and contains? having different >> behaviors for the exact same error (ie, one throws the other works >> fine and just returns false on a type error)? From a design >> perspective this seems to increase the cognitive load to programmers >> without any (apparent) reason. >> > > I imagine the rationale is efficiency. Every core function could > conceivably do a number of runtime checks to make sure that each input > is the right kind of type, and then Clojure might feel more sluggish. > So instead, the core functions just worry about what to do for the > appropriate inputs. If you pass a bogus input, the consequence > depends entirely on how that particular function was coded. It might > return a spurious result, or it might error. There are numerous > examples of this in the Clojure API. > Efficiency is certainly part of it. However, it is not spurious. Errors will become exceptions, not random nonsense. Some things one might consider errors are not considered as such, and that is quite a different thing. One presumption here is that this is a simple matter of types. It is not (simple). There are some functions whose domain is constrained by a known/fixed (family of) type(s), but many that are not. even? is (Numbers), contains? is not (open set of associative-like things, false otherwise). This type-openness of many Clojure core functions is one key to its power. I'm sure making contains?/get tolerant of non-associative things gave us benefits elsewhere (i.e. made associative destructuring tolerant of, and thus useful upon, heterogeneous sequences, only some of whose elements were associative). If that were not the case, then any code needed to handle that would need a predicate for an open set in order to filter first. Such predicates are extremely icky to construct and maintain, and, brittle to rely upon. The work I am doing on protocols may help out quite a bit here, as they will provide a unifying point for open abstractions, encompassing explicit type relationships (inheritance form interfaces), superimposed capabilities (e.g. the way Strings become seq-able), and open functional extension (a la multimethods), in a way such that asking (implements? protocol x) will become an open type predicate. > It wouldn't surprise me if there are a number of programmers who would > be turned off by the ease with which one can shoot yourself in the > foot without getting any kind of error message, but in practice I > haven't gotten bit by this yet. > Everyone would like more help from a system when they have made a mistake. But everyone needs to have a realistic view about what can be detected, and at what cost, (especially to produce a revelatory message), as well as a general understanding of open functions. I imagine at some point we may have a diagnostic mode, with many (expensive) runtime checks, and correspondingly more detailed error/mistake reports. But you are right, the emphasis right now is on making correct programs work well. 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: Running out of memory when using loop/recur and destructuring
On Wed, Nov 4, 2009 at 8:47 AM, Christophe Grand wrote: > > On Tue, Nov 3, 2009 at 7:27 PM, Paul Mooser wrote: >> >> Ah -- I hadn't understood that when using destructuring, that >> subsequent bindings could refer to the destructured elements. I should >> have, since clojure "only" has let*, and this behavior seems >> consistent with that, for binding. >> >> Eeww. It seems like quite a thorny issue to solve, even if simple to >> describe. > > Well, in truth, there's a way to fix the loop macro but it is too > ugly: the idea is to wrap the outer let in a closure and replace the > loop by a function, thus we could benefit from the locals clearing on > tail call. > > The real solution would be pervasive locals clearing but I seem to > remember Rich saying he'd like to delay such work until clojure in > clojure. > Right - pervasive locals clearing will definitely do the trick here. Interestingly, when I was at Microsoft and asked them about handling this issue for the CLR they stated plainly it wasn't an issue at all - their system can fully detect that any such references are in fact unreachable and are subject to GC. So, in a sense, all locals clearing on my part is a workaround for a JVM weakness in this area. >> What's the procedure for creating a ticket for this? Is it at least >> acknowledged that this IS a bug? > > It's better to wait for Rich's opinion on this problem before creating a > ticket. > No ticket, please. This issue is well understood and has been discussed at length. Thanks, Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Boggle solver
Nice. As soon as I get a chance I'll modify it to be able to solve arbitrary sized boards. Should be a perfect example to explore and demonstrate clojure's concurrency capabilities. On Nov 10, 5:42 pm, jng27 wrote: > C and Common Lisp versions here --> http://code.google.com/p/boggle-solvers/ > Both use the same algorithm and data structures as far as possible. > The C version can solve a 1000x1000 board in about 40 seconds. The CL > version solves a 1000x1000 board in about 65 seconds on a dual core > laptop. > > Haven't yet implemented a Clojure version. That would be interesting > for comparison ... > > On Nov 7, 12:11 am, james wrote: > > > > > Hey! > > > As a learning exercise I wrote a simple boggle solver in clojure. > > I'm sure there is lots of room for improvement to make it more > > idiomatic and perform better so I would be grateful if anyone would > > care to cast their eye over it. > > >http://wiki.github.com/phraemer/Boggle-Solver > > > thanks, > > > James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Gensym collisions can be engineered.
On Mon, Nov 9, 2009 at 10:04 PM, Kevin Tucker wrote: > I in CL they can be read but aren't interned in any package so every > time you read it you get a different symbol. Yes, I know; I said that myself in the first post. But your first post inspired in me the idea of simply making symbols that would collide with gensyms unreadable period. :) -- You 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: Using agents and blocking I/O.
On Nov 10, 7:07 am, David Brown wrote: > Ok. So, it's the existence of this future-like entity that blocks > upon deref until filled is indeed somewhat missing. It's not > particularly difficult to implement. > > This thing could easily create a lazy sequence, in fact, the code > would look a lot like the code for seque, with just a separation of > the writer from the reader. I'll have to think about it to make sure > that it can be used safely. You might want to look at the (recently added) fill-queue (in clojure.contrib.seq-utils), which provides a lazy seq that is filled by another thread and blocks if readers consume faster than the queue is filled; maybe your problem fits into this mechanism. -- You 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: Vector manipulation problem, possible function for a solution.
On Tue, Nov 10, 2009 at 1:00 AM, Richard Newman wrote: > > I have a vector a [ [2 3] [4 5] [6 7] ] > > > > And I want to be able to get [2 3 4 5 6 7] > > user=> (reduce into [ [2 3] [4 5] [6 7] ]) > [2 3 4 5 6 7] > This and another solution have already been posted, but there's also: (vec (apply concat [ [2 3] [4 5] [6 7] ])) (vec (mapcat identity [ [2 3] [4 5] [6 7] ])) (into [] (apply concat [ [2 3] [4 5] [6 7] ])) (into [] (mapcat identity [ [2 3] [4 5] [6 7] ])) (into [] (remove vector? (tree-seq vector? seq [ [2 3] [4 5] [6 7] ]))) of which the last will also do e.g. [[2 [4 5]] [[8 9] [11 1]] [17]]. Of course, then we're getting pretty close to the implementation of flatten, which is (filter (complement sequential?) (rest (tree-seq sequential? seq x))) (apparently whoever wrote it never heard of remove). :) -- You 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: Running out of memory when using loop/recur and destructuring
On Tue, Nov 10, 2009 at 7:21 AM, Rich Hickey wrote: > Right - pervasive locals clearing will definitely do the trick here. > Interestingly, when I was at Microsoft and asked them about handling > this issue for the CLR they stated plainly it wasn't an issue at all - > their system can fully detect that any such references are in fact > unreachable and are subject to GC. So, in a sense, all locals clearing > on my part is a workaround for a JVM weakness in this area. Did you see my earlier post? One possible workaround in this specific instance could be to use SoftReference to make a "clearable" local in the let outside the loop. In case of any worries about the reference being cleared in the few nanos before it can be copied into the loop variables, you could also use a mutable store, e.g. let [G__13697 (atom s) [x & xs] @G__13697 x (atom x) xs (atom xs) y (atom @xs) grab (fn [a] (let [x @a] (reset! a nil) x))] (loop* [G__13697 (grab G__13697) y (grab y)] (let [[x & xs] G__13697 y y] ...))) How it works: 1. When the outer let is needed due to destructuring, the nondestructuring binds are wrapped in (atom). The destructuring binds are not, but each destructuring-produced binding is then rebound to itself wrapped in (atom). Any reference to one of the preceding locals is wrapped in (deref). 2. When the loop needs to initialize its loop variables, it wraps access to the let's variables in grab, which returns the contents of the atom while also resetting it. It's not very CPU efficient, since it uses atoms which seem to be slow, but it will prevent head-retention of lazy seqs IF (let [x the-seq x something-else]) lets go of the head of the-seq when the second binding of x in the same let is performed. By the time the loop body begins executing, the only things the outer let's bindings are holding onto will be tiny little empty atoms, consuming just a few heap bytes each. -- You 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: Running out of memory when using loop/recur and destructuring
On Wed, Nov 4, 2009 at 6:46 AM, John Harrop wrote: > On Tue, Nov 3, 2009 at 1:53 AM, Alex Osborne wrote: >> >> The new loop uses the outer-let to get around this: >> (let [G__13697 s >> [x & xs] G__13697 >> y xs] >> (loop* [G__13697 G__13697 >> y y] >> (let [[x & xs] G__13697 >> y y] >> ...))) > > Now, if that were > (let [G__13697 (java.lang.ref.SoftReference. s) > [x & xs] (.get G__13697) > y xs] > (loop* [G__13697 (.get G__13697) > y y] > (let [[x & xs] G__13697 > y y] > ...))) > instead ... Or you can rely on the existing local clearing on tail calls: (#(let [G__13697 s [x & xs] G__13697 y xs] ((fn [G__13697 y] (let [[x & xs] G__13697 y y] ...) G__13697 y It _should_ work (untested). Christophe -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Using agents and blocking I/O.
On Tue, Nov 10, 2009 at 07:41:41AM -0800, pmf wrote: >> This thing could easily create a lazy sequence, in fact, the code >> would look a lot like the code for seque, with just a separation of >> the writer from the reader. I'll have to think about it to make sure >> that it can be used safely. > >You might want to look at the (recently added) fill-queue (in >clojure.contrib.seq-utils), which provides a lazy seq that is filled >by another thread and blocks if readers consume faster than the queue >is filled; maybe your problem fits into this mechanism. Well, almost. Except that it would create a future that I really don't have any use for. Last night, I posted very similar code to do the same kind of thing with an agent (I have since fixed the exception handling in the agent so it terminates the queue so the reader will get an exception rather than just hang). With fill-queue, send-queued, and seque all looking nearly identical, I wonder if we're missing how this should be abstracted. I did learn, though from reading it that seque stops short if the computation runs ahead enough to fill up the queue. I'm not quite sure what this would be useful for. (import '(java.util.concurrent BlockingQueue LinkedBlockingQueue)) (defn send-queued "Dispatch blocking action to agent. The state of the agent will be set to the value of: (apply action-fn state-of-agent enqueue args) The agent should call enqueue for each item to return to the caller of send-queued. send-queued returns a lazy sequence of the items the agent passes to enqueue (in order). The agent may enqueue 'n' items before blocking on its call to enqueue." [a n f & args] (let [#^BlockingQueue q (LinkedBlockingQueue. (int n)) NIL (Object.) ;nil sentinel since LBQ doesn't support nils enqueue (fn [x] (.put q (if (nil? x) NIL x))) action (fn [state1] (try (let [state2 (apply f state1 enqueue args)] (.put q q) ; q itself is eos sentinel state2) (catch Exception e (.put q q) (throw e drain (fn drain [] (lazy-seq (let [x (.take q)] (if (identical? x q) ;q itself is eos sentinel (do @a nil) ;touch agent just to propagate errors (cons (if (identical? x NIL) nil x) (drain))] (send-off a action) (drain))) -- You 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: Using agents and blocking I/O.
On Tue, Nov 10, 2009 at 10:41 AM, pmf wrote:
> On Nov 10, 7:07 am, David Brown wrote:
> > Ok. So, it's the existence of this future-like entity that blocks
> > upon deref until filled is indeed somewhat missing. It's not
> > particularly difficult to implement.
> >
> > This thing could easily create a lazy sequence, in fact, the code
> > would look a lot like the code for seque, with just a separation of
> > the writer from the reader. I'll have to think about it to make sure
> > that it can be used safely.
>
> You might want to look at the (recently added) fill-queue (in
> clojure.contrib.seq-utils), which provides a lazy seq that is filled
> by another thread and blocks if readers consume faster than the queue
> is filled; maybe your problem fits into this mechanism.
This suggests something else, in turn -- a tunable, somewhat lazy seq
produced using parallelism:
(defmacro p-lazy-seq [lookahead continue? & body]
`(let [lzy# (fn lzy [] (lazy-seq (if ~continue? (cons (future ~...@body)
(~'lzy)
s# (lzy#)]
(map (fn [x# _#] (deref x#)) s# (drop ~lookahead s#
The result for
(p-lazy-seq n continue?
body)
should be the same as for
(letfn [(f []
(lazy-seq
(if continue?
(cons (do body) (f)]
(f))
i.e. continue? is evaluated and if true body is evaluated to yield the next
element of the lazy sequence; then continue? is evaluated again, etc. etc.
Except that the generation of elements is done on worker threads, possibly
more than one at a time if on multicore hardware, transparently to the
consumer of the seq.
Consumption of the seq blocks if it reaches an element not yet produced. The
tandem map of s# and (drop ~lookahead s#) is used to force the creation of a
future wrapping the element n ahead of the current element, while the
current element's future is dereferenced (which is where the blocking may
occur) and its result returned. Note that the future n elements ahead is NOT
dereferenced; it's just generated (by realizing that element of a lazy
sequence of future objects) which causes it to be enqueued for calculation
on a thread pool without blocking until it has a result.
Thus, lookahead futures will be computing or done at any given time. A
lookahead of zero would result in no better than sequential performance as
the consumer of the seq would block until one more element was produced,
process it, block until one more element was produced, etc.; however, a
lookahead of 1 allows the consumer of the seq to be processing one element
while the next is being produced by another thread, and higher lookaheads
can exploit more than two cores for even more parallelism.
As for a practical application:
(def *rngs* (atom {}))
(defn thread-local-rand [n]
(if-let [rng (@*rngs* (Thread/currentThread))]
(rng n)
(let [rng-1 (java.util.Random.)
rng #(.nextInt rng-1 %)]
(swap! *rngs* assoc (Thread/currentThread) rng)
(rng n
user=> (take 10 (p-lazy-seq 3 true (thread-local-rand 10)))
(1 2 6 1 5 1 7 8 4 3)
This should generate the random numbers on multiple threads, using multiple
RNGs. In the limit, on multicore hardware and with a slow enough RNG
implementation (e.g. SecureRandom), a consumer of that sequence might be
able to obtain and use random numbers faster than with direct calls to the
RNG implementation.
(The mechanism I used to make a function that maintains its own encapsulated
thread-local state, persistent across calls, might be worth a closer look,
too, for situations where binding just can't get the job done.)
--
You 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: Using agents and blocking I/O.
On Tue, Nov 10, 2009 at 11:41 AM, John Harrop wrote: > user=> (take 10 (p-lazy-seq 3 true (thread-local-rand 10))) > (1 2 6 1 5 1 7 8 4 3) > > This should generate the random numbers on multiple threads, using multiple > RNGs. In the limit, on multicore hardware and with a slow enough RNG > implementation (e.g. SecureRandom), a consumer of that sequence might be > able to obtain and use random numbers faster than with direct calls to the > RNG implementation. > Oh, and did I mention the random numbers should also be more *secure*? There would be multiple SecureRandom (or whatever) instances and which one is chosen to produce a given random number will be essentially, well, random, making it, if possible, even harder to guess the next random number the consumer will use than if it just used one SecureRandom instance directly. -- You 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: Autodoc for clojure core, first rev
On Nov 9, 1:28 pm, Howard Lewis Ship wrote: > It looks very nice ... still I'd love to see something like what > clj-doc does (http://github.com/mmcgrana/clj-doc) ... it adds a text > field that you can type into and it matches the available names > against what you type, hiding the rest. Great idea. As I said in another message, I've been resisting having any JS driven stuff while I get the HTML/CSS ironed out, but that's a natural thing to add. > I'll see if I can find some time to help ... where's the code? (i.e., > what git repo do I clone?) The code is at http://github.com/tomfaulhaber/contrib-autodoc. The clojure core documentation is built by the code on the "general" branch. (The master branch is still clojure-contrib specific. Once I get "general" so that it can build both clojure and clojure-contrib, I will merge them back together. I will warn you, however, that there is a crazy amount of mechanism here (mostly undocumented) that I'm still working out. So I don't consider this to be supported code yet. On Nov 9, 1:42 pm, Konrad Hinsen wrote: > But please add clojure.test and clojure.parallel as well! Oops, missed those. Thanks for spotting them. On Nov 9, 2:21 pm, Michael Jaaka wrote: > Why when I click on left in the index menu, the description of a > function shows on top? > It should be right next to clicked position, so I won't scroll whole > page on top in order to read doc. I'm not sure I understand this. Do you mean, why doesn't the link on the API index page go straight to the function? That's a bug. Fixed soon. Tom -- You 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: Using agents and blocking I/O.
Anybody else getting bombarded by multiple copies of this message? --- On Tue, 11/10/09, John Harrop wrote: > From: John Harrop > Subject: Re: Using agents and blocking I/O. > To: clojure@googlegroups.com > Date: Tuesday, November 10, 2009, 8:45 AM > On Tue, Nov 10, > 2009 at 11:41 AM, John Harrop > wrote: > > user=> (take 10 > (p-lazy-seq 3 true (thread-local-rand > 10)))(1 2 6 1 5 1 7 8 4 > 3) > This should generate the random numbers on > multiple threads, using multiple RNGs. In the limit, on > multicore hardware and with a slow enough RNG implementation > (e.g. SecureRandom), a consumer of that sequence might be > able to obtain and use random numbers faster than with > direct calls to the RNG implementation. > > Oh, and did I mention the random numbers should > also be more *secure*? There would be multiple SecureRandom > (or whatever) instances and which one is chosen to produce > a given random number will be essentially, well, random, > making it, if possible, even harder to guess the next random > number the consumer will use than if it just used one > SecureRandom instance directly. > > > > > -- > > You 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: Communication in a distributed system
On Mon, Nov 9, 2009 at 1:09 PM, Michael Jaaka wrote: > > Hi! > > Is there any support from Clojure for communication between procesess > by sockets? > I'm interested in communication via RMI. > How about agents? I don't know much about agents exept fact that they > are seen in terms of threads in the same process? Should the socket > communication/RMI be interfaced via agents? > > Bye! > > FYI... The sample application built in the peepcode clojure screencast ( http://peepcode.com/products/functional-programming-with-clojure) demonstrates one way of dealing with socket connections. The source code for the app is at http://github.com/technomancy/mire. jb -- Jeff Brown SpringSource http://www.springsource.com/ Autism Strikes 1 in 166 Find The Cause ~ Find The Cure http://www.autismspeaks.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
Better documentation and error messages are needed for the ns macro
So I have (ns foo.bar.baz) and I want to grab clojure.contrib.core/seqable? What do I do? (ns foo.bar.baz (use clojure.contrib.core :only seqable?)) # (ns foo.bar.baz (use [clojure.contrib.core :only seqable?])) # (ns foo.bar.baz (:use [clojure.contrib.core :only seqable?])) # etc. Anyone else noticing a pattern here? a) a need to play a variation of the old command-line-prompt guess-the-synonym game to get it to work, because the documentation for "ns" doesn't give actual examples nor does that for "use" and b) completely uninformative error messages that don't even identify the ns form as the problem, though it is. Really, to refer to the exact syntax for a use clause in an ns form I shouldn't have to do more than a) go to clojure.org/api, b) go to the entry on "ns", and c) skim. But it takes careful reading and pointer-following (from "ns" to "use" and then "require", then backtrack, then "refer") instead of a quick and easy skim, largely owing to the lack of actual examples of usage in the docs. Which are unnecessary in most places, but the "ns" macro is an exception since it has its own mini-DSL inside it. (The for/doseq/doall triad is the other major culprit in that regard.) In case anyone was wondering, apparently it wants (ns foo.bar.baz (:use [clojure.contrib.core :only (seqable?)])) (and thus violates the usual clojure rule of using vectors rather than lists for groupings that are not invocations -- that is, function calls, macro calls, or special form calls). -- You 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: Better documentation and error messages are needed for the ns macro
> (ns foo.bar.baz > (:use [clojure.contrib.core :only (seqable?)])) > > (and thus violates the usual clojure rule of using vectors rather > than lists for groupings that are not invocations -- that is, > function calls, macro calls, or special form calls). It works fine with a vector. user=> (ns foo.bar.baz (:use [clojure.contrib.core :only [seqable?]])) nil foo.bar.baz=> seqable? # -- You 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: Better documentation and error messages are needed for the ns macro
On Tue, Nov 10, 2009 at 9:11 PM, Richard Newman wrote: > > (ns foo.bar.baz > > (:use [clojure.contrib.core :only (seqable?)])) > > > > (and thus violates the usual clojure rule of using vectors rather > > than lists for groupings that are not invocations -- that is, > > function calls, macro calls, or special form calls). > > It works fine with a vector. Yeah, but it doesn't require one, versus: foo.bar.baz=> (let (a 10) (println a)) # -- You 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: Better documentation and error messages are needed for the ns macro
On Tue, Nov 10, 2009 at 09:08:31PM -0500, John Harrop wrote: >In case anyone was wondering, apparently it wants > >(ns foo.bar.baz > (:use [clojure.contrib.core :only (seqable?)])) > >(and thus violates the usual clojure rule of using vectors rather than lists >for groupings that are not invocations -- that is, function calls, macro >calls, or special form calls). You can use vectors for everything other than the outside parens, if you'd like. They just need to be sequences. I'm guessing people usually use parens on the :use, because it at least looks like an invocation (and is similar to the (use ...) call). I've seen the :only followed by a vector. 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
