Question on bound-fn source

2010-05-26 Thread YD
(defmacro bound-fn
  [& fntail]
  `(bound-fn* (fn ~...@fntail)))

Shouldn't it be: (fn [] ~...@fntail) ?

If you try to use this function by passing more than one function as
arguments to it, you'll get an exception. e.g. (bound-fn f1 f2)

I'm a newbie to clojure and I'm not quite sure if this is a bug.

-- 
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: Question on bound-fn source

2010-05-26 Thread YD
Thank you, now I see the point.

-- 
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


Question on destructure source

2010-06-03 Thread YD
Hi,

When 'destructure' is doing a map destructuring, 'pmap' is the
function to use. 'pmap' will do some kind of process to the given
bindings using these lines of code:
bes (reduce
 (fn [bes entry]
   (reduce #(assoc %1 %2 ((val
entry) %2))
   (dissoc bes (key
entry))
   ((key entry) bes)))
 (dissoc b :as :or)
 {:keys #(keyword (str %)), :strs
str, :syms #(list `quote %)})

I'm confused. Since every time ((key entry) bes) evaluates to nil, the
inner reduce will never really do some useful thing. What's the
purpose of this piece of code?

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: Question on destructure source

2010-06-04 Thread YD
Very clear, much appreciate!

On Jun 4, 2:55 am, Chouser  wrote:
> On Thu, Jun 3, 2010 at 9:38 AM, YD  wrote:
> > Hi,
>
> > When 'destructure' is doing a map destructuring, 'pmap' is the
> > function to use. 'pmap' will do some kind of process to the given
> > bindings using these lines of code:
> >                                bes (reduce
> >                                     (fn [bes entry]
> >                                       (reduce #(assoc %1 %2 ((val
> > entry) %2))
> >                                               (dissoc bes (key
> > entry))
> >                                               ((key entry) bes)))
> >                                     (dissoc b :as :or)
> >                                     {:keys #(keyword (str %)), :strs
> > str, :syms #(list `quote %)})
>
> > I'm confused. Since every time ((key entry) bes) evaluates to nil, the
> > inner reduce will never really do some useful thing. What's the
> > purpose of this piece of code?
>
> Yes, if ((key entry) bes) is nil then the inner reduce simply
> returns the binding map as it stands.  The purpose of this code
> is to support the :keys, :strs, and :syms keys in map
> destructuring:
>
>         (let [{:keys [a b]} {:a 1 :b 2}] [a b])
>         ;=> [1 2]
>
> In this example, (key entry) will be :keys for one of the
> iterations of the inner reduce.  When (key entry) is :keys, ((key
> entry) bes) will be [a b], and the inner reduce will process each
> item of that vector, finally returning {a :a b :b} as the whole
> binding map.
>
> Which means the above example does exactly the same things as:
>
>         (let [{a :a b :b} {:a 1 :b 2}] [a b])
>         ;=> [1 2]
>
> ...which is what you'd do if there was no support for :keys
>
> --Chouserhttp://joyofclojure.com/

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


Re: Serious problem with underive (for hierarchies), an attempt to fix, and request for code review.

2010-06-16 Thread YD
The problems are real. Well 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: Serious problem with underive (for hierarchies), an attempt to fix, and request for code review.

2010-06-16 Thread YD
Another apporach I think would be modifying the data structure of
hierarchy itself. The idea is to add a counter to ancestors and
descendants.
:ancestors: { :c #{ [:a1 1] [:a2 2] } }
So, the counter 2 on :a2 means how many paths can you get :c to
reach :a2. When the counter reaches 0, you can remove it completely.
Otherwise, decrement it.

This approach requires to change all the functions related to
hierarchy, and the data structure will be incompatible to the original
one. But the speed is gonna be fast.

-- 
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: agents sending-off to other agents blocks?

2010-06-16 Thread YD
Yeah, it's intended, just like what Ulrich showed. The same comment
appears on the doc of release-pending-sends.
In your case, the inner send-off doesn't rely on the result of the
outter send-off. So, you can use release-pending-sends.
The following code will have "hey" printed right away.

(send
  (agent nil)
  (fn [_]
(send
  (agent nil)
  (fn [_]
(println "Hey!")))
(release-pending-sends)
(Thread/sleep 4000)))
(shutdown-agents)

The interesting thing is, if you remove the call to (release-pending-
sends) and the call to (shutdown-agents) will cause
java.util.concurrent.RejectedExecutionException being thrown.
This is because, I think, when the outter send-off has finished
sleeping, shutdown-agents (which is really a call to shutdown on the
thread-pool agents used) will take effect, and the thread-pool is shut
down. Then, the inner send-off starts to work, but he will find that
the thread pool has already been turned off. So the exception is
thrown.

I don't know how to NOT call the release-pending-sends function, and
still be able to shutdown-agents. Would anyone tell me how?

On Jun 13, 3:46 am, Moritz Ulrich 
wrote:
> Sorry for the second mail, but here is the passage from clojure.org
> which mentions the behavior you've seen:
>
> "5. If during the function execution any other dispatches are made
> (directly or indirectly), they will be held until after the state of
> the Agent has been changed."
>
> Maybe it's done to prevent problems when the function the
> currently-active agent sent to another agent depends on the value of
> the original agent.
>
> On Sat, Jun 12, 2010 at 9:43 PM, Moritz Ulrich
>
>
>
>  wrote:
> > I'm not sure why it's doing this, but I read about this in the api
> > documentation - It's intended
>
> > On Sat, Jun 12, 2010 at 9:41 PM, Dan Larkin  wrote:
> >> Hey all,
>
> >> I've cooked up this example code to demonstrate a point:
>
> >> (send-off
> >>  (agent nil)
> >>  (fn [_]
> >>   (send-off
> >>    (agent nil)
> >>    (fn [_]
> >>      (println "Hey!")))
> >>   (Thread/sleep 4000))) ; "Hey!" isn't printed for 4 seconds (when the 
> >> outer agent finishes).
>
> >> Which is that actions sent to an agent from another agent won't be started 
> >> until the first agent returns from its current action.
>
> >> Does anyone have insight as to the reasoning here? Is it a bug? If it's 
> >> intended behavior is there something I can do to circumvent it?
>
> >> Dan
>
> >> --
> >> 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
>
> > --
> > Moritz Ulrich
> > Programmer, Student, Almost normal Guy
>
> >http://www.google.com/profiles/ulrich.moritz
>
> --
> Moritz Ulrich
> Programmer, Student, Almost normal Guy
>
> http://www.google.com/profiles/ulrich.moritz

-- 
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