Re: beginner help with views in ClojureScript One?
Thanks for posting this. I actually had the same problem and couldn't work out what was going wrong. Cheers, Simon On Friday, 16 March 2012 15:42:03 UTC, George Oliver wrote: hi, I'm starting to modify the One sample application and can't get the hang of rendering a new view. I've tried looking at some forked projects but am coming up short. This is solved -- looks like I saved but didn't compile and load the snippets macro. Moderators, if you catch this before you approve the first message, feel free to kill the thread. -- 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: Mapping first element only: how to preserve vectors
On Mon, Mar 19, 2012 at 2:40 PM, Bojan bojandoli...@hotmail.com wrote: Hi! I'm a beginner at clojure and enjoying the learning process. While writing my first nontrivial program, I noticed that I'm transforming only first elements in the list, so I factored this transformation out by writing next function: (defn map-first [f coll] (map #(cons (f (first %)) (rest %)) coll)) If coll is always a collection of vectors, then you can simply use 'assoc' since vectors support near-constant-time random access. Also, the name map-first is a bit misleading in my opinion, since it does not map f over the first element in coll, but over the first element of each collection in coll. Here's an example using assoc: (defn map-first [f v] (assoc v 0 (f (nth v 0 (defn map-firsts [f coll] (map #(map-first f %) coll)) (map-firsts #(* 2 %) [[2] [3 3] [3 [2 4]] [4 10]]) ;= ([4] [6 3] [6 [2 4]] [8 10]) The complexity of map-firsts is O(log_32(n) * m). The log_32(n) part comes from assoc, which creates a new updated vector with n elements. (log_32 is practically close to constant. log_32 of four billion is about 6 or 7) The m part comes from mapping over the outer collection (of size m). The complexity can be approximated to just O(m) if you approximate log_32 as constant time. The 'assoc' here is very cheap. // raek -- 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: Parallel SSH and system monitoring in Clojure
Chris McBride cmm7...@gmail.com writes: I releases two simple clojure libraries to help running commands via SSH on multiple servers. Hopefully someone will find it useful. You might also be interested in Pallet [1], which executes via SSH. [1] http://palletops.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
Precondition asserts in macros
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
Shantanu
--
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: Precondition asserts in macros
Your second `foo` call fails in 1.2 as well. If there was ever a time when it
would have succeeded, it would have been a bug. Since `foo` is a macro, it
receives its arguments unevaluated, so `(str baz 34)` will always be received
as a list of three values.
The syntax-quote precondition simply expands into a list containing the symbol
'clojure.core/string? and the value of bar; this is a logically-true value, and
so does not trigger any error.
You want something like:
(defmacro foo
[bar body]
`(let [bar# ~bar]
(when-not (string? bar#) (IllegalArgumentException. msg))
...))
- Chas
On Mar 20, 2012, at 8:34 AM, Shantanu Kumar wrote:
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
Shantanu
--
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: Precondition asserts in macros
Hello,
I am not sure that anything has changed between Clojure 1.2.1 and
Clojure 1.3.0 with respect to pre- and post-conditions. However, I
think I have any idea as to what may be going on.
On Tue Mar 20 05:34 2012, Shantanu Kumar wrote:
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
As I understand it, as foo is a macro, bar isn't being evaluated in the
precondition. As a result it just gets whatever bar is. In the first
example, bar is bar34, but in the second example, it's the list (str
baz 34). So, if you changed the precondition to (list? bar), the
first would fail, and the second would succeed.
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
In this case, your precondition is evaluating to something like:
(clojure.core/seq
(clojure.core/concat
(clojure.core/list (quote clojure.core/string?))
(clojure.core/list bar)))
And this does not evaluate to false. As such, the precondition is being
checked, it's just not checking what you want it to check.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
I think what you may want is something like:
{:pre [(string? (eval bar))]}
However, I must question whether or not you really want to be doing
this. The precondition is being evaluated a compile/macro-expansion
time, not run time. As such, you should probably only use pre- and
post-conditions on defmacro if they are checking the arguments to the
macro itself.
Just some thoughts.
Sincerely,
Daniel
signature.asc
Description: Digital signature
Re: Precondition asserts in macros
Another option: create a helper function to do the work and have the macro
call that:
(defn foo* [bar body-thunk]
{:pre [(string? bar)]}
(body-thunk)) ;or whatever
(defmacro foo [bar body]
`(foo* ~bar (fn [] ~@body))
Justin
On Tuesday, March 20, 2012 9:07:45 AM UTC-4, Chas Emerick wrote:
Your second `foo` call fails in 1.2 as well. If there was ever a time
when it would have succeeded, it would have been a bug. Since `foo` is a
macro, it receives its arguments unevaluated, so `(str baz 34)` will
always be received as a list of three values.
The syntax-quote precondition simply expands into a list containing the
symbol 'clojure.core/string? and the value of bar; this is a logically-true
value, and so does not trigger any error.
You want something like:
(defmacro foo
[bar body]
`(let [bar# ~bar]
(when-not (string? bar#) (IllegalArgumentException. msg))
...))
- Chas
On Mar 20, 2012, at 8:34 AM, Shantanu Kumar wrote:
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
Shantanu
--
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: Precondition asserts in macros
try with {:pre [(string? (eval bar))]}
--
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: Returning Success
On Mar 19, 3:56 am, Narvius narv...@gmail.com wrote:
I am writing a game in Clojure, and I often need some functions to return
whether they succeeded in doing what they are supposed to do
[]
I see several ways to achieve what I want, that is to return both the new
world state and success status.
not, then at least I hope my idea is helpful to someone. :)
You might have a fifth option -- don't return the world state, but
report what happened (pushing that event onto a queue maybe?). Then
have a separate function make state changes. See
http://prog21.dadgum.com/26.html:
When I first mused over writing a game in a purely functional style,
this had me stymied. One simple function ends up possibly changing the
entire state of the world? Should that function take the whole world
as input and return a brand new world as output? Why even use
functional programming, then?
A clean alternative is not to return new versions of anything, but to
simply return statements about what happened. Using the above example,
the movement routine would return a list of any of these side effects:
{new_position, Coordinates}
{ate_ghost, GhostName}
{ate_dot, Coordinates}
ate_fruit
killed_by_ghost
All of a sudden things are a lot simpler. You can pass in the relevant
parts of the state of the world, and get back a simple list detailing
what happened. Actually handling what happened is a separate step, one
that can be done later on in the frame. The advantage here is that
changes to core world data don't have to be painstakingly threaded in
and out of all functions in the game.
--
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: ClojureScript error messages
Not yet. I'll have to take care of that. On Mon, Mar 19, 2012 at 5:48 PM, David Nolen dnolen.li...@gmail.com wrote: On Mon, Mar 19, 2012 at 1:36 PM, Aaron aaroncrael...@gmail.com wrote: I pushed the patch to my fork on github in this commit: https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 Should I submit a pull request? Clojure doesn't take pull requests. Have you sent in your CA? If so open a ticket and attach a patch in JIRA. Thanks! 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 -- 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: Parallel SSH and system monitoring in Clojure
Thinking cloudly, one may query ec2 tags to assemble the cluster with clojure-control. Both are useful though. Paulo Suzart On 15 March 2012 21:19, Sun Ning classicn...@gmail.com wrote: You might interested in clojure-control[1], which has similar functionality to your library. [1] https://github.com/killme2008/**clojure-controlhttps://github.com/killme2008/clojure-control On 03/16/2012 06:12 AM, Chris McBride wrote: Hi, I releases two simple clojure libraries to help running commands via SSH on multiple servers. Hopefully someone will find it useful. http://info.rjmetrics.com/**blog/bid/54114/Parallel-SSH-** and-system-monitoring-in-**Clojurehttp://info.rjmetrics.com/blog/bid/54114/Parallel-SSH-and-system-monitoring-in-Clojure https://github.com/RJMetrics/**Parallel-SSHhttps://github.com/RJMetrics/Parallel-SSH https://github.com/RJMetrics/**Server-Statshttps://github.com/RJMetrics/Server-Stats Best, Chris McBride -- Sun Ning Software developer Nanjing, China (N32°3'42'' E118°46'40'') http://about.me/sunng/bio -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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 for banking and invenstment system?
I dont understand why some companies use clojure for finance. How can I work there ? What do I have to learn ? -- 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: Precondition asserts in macros
Using an explicit eval is generally not a good idea, as `bar` will be evaluated
at least twice: once in validating the precondition, and again in the
macroexpansion. This can lead to all sorts of interesting problems if `bar`
happens to be a side-effecting expression.
- Chas
On Mar 20, 2012, at 9:18 AM, Daniel Solano Gomez wrote:
Hello,
I am not sure that anything has changed between Clojure 1.2.1 and
Clojure 1.3.0 with respect to pre- and post-conditions. However, I
think I have any idea as to what may be going on.
On Tue Mar 20 05:34 2012, Shantanu Kumar wrote:
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
As I understand it, as foo is a macro, bar isn't being evaluated in the
precondition. As a result it just gets whatever bar is. In the first
example, bar is bar34, but in the second example, it's the list (str
baz 34). So, if you changed the precondition to (list? bar), the
first would fail, and the second would succeed.
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
In this case, your precondition is evaluating to something like:
(clojure.core/seq
(clojure.core/concat
(clojure.core/list (quote clojure.core/string?))
(clojure.core/list bar)))
And this does not evaluate to false. As such, the precondition is being
checked, it's just not checking what you want it to check.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
I think what you may want is something like:
{:pre [(string? (eval bar))]}
However, I must question whether or not you really want to be doing
this. The precondition is being evaluated a compile/macro-expansion
time, not run time. As such, you should probably only use pre- and
post-conditions on defmacro if they are checking the arguments to the
macro itself.
Just some thoughts.
Sincerely,
Daniel
--
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 for banking and invenstment system?
Perhaps you could contact someone at a company that uses Clojure for finance and ask them. On Tuesday, March 20, 2012 9:03:30 AM UTC-5, Roller wrote: I dont understand why some companies use clojure for finance. How can I work there ? What do I have to learn ? -- 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 for banking and invenstment system?
have a look here: http://blog.malcolmsparks.com/ On Tuesday, March 20, 2012 2:03:30 PM UTC, Roller wrote: I dont understand why some companies use clojure for finance. How can I work there ? What do I have to learn ? -- 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
Google Summer of Code 2012 Mentors please put yourself into Melange
If you've marked yourself as a mentor for any of Google Summer of Code 2012 proposals please apply to be a mentor: http://www.google-melange.com/gsoc/homepage/google/gsoc2012 Thanks! 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: Precondition asserts in macros
Thanks everybody for the pointers! I realized I was wrong about the
behavior being different in 1.2; rather it is the same since 1.1.0.
Shantanu
On Mar 20, 2:29 pm, Chas Emerick c...@cemerick.com wrote:
Using an explicit eval is generally not a good idea, as `bar` will be
evaluated at least twice: once in validating the precondition, and again in
the macroexpansion. This can lead to all sorts of interesting problems if
`bar` happens to be a side-effecting expression.
- Chas
On Mar 20, 2012, at 9:18 AM, Daniel Solano Gomez wrote:
Hello,
I am not sure that anything has changed between Clojure 1.2.1 and
Clojure 1.3.0 with respect to pre- and post-conditions. However, I
think I have any idea as to what may be going on.
On Tue Mar 20 05:34 2012, Shantanu Kumar wrote:
Hi,
The way preconditions are invoked in Clojure 1.3.0 seems to have
changed since Clojure 1.2:
(defmacro foo
[bar body]
{:pre [(string? bar)]}
...)
(foo bar34 ...) ; doesn't complain, which is OK
(foo (str baz 34) ...) ; Error! (I wanted this to pass)
As I understand it, as foo is a macro, bar isn't being evaluated in the
precondition. As a result it just gets whatever bar is. In the first
example, bar is bar34, but in the second example, it's the list (str
baz 34). So, if you changed the precondition to (list? bar), the
first would fail, and the second would succeed.
When I write the precondition like this:
{:pre [`(string? ~bar)]}
It doesn't seem to check the precondition at all in 1.3.0.
In this case, your precondition is evaluating to something like:
(clojure.core/seq
(clojure.core/concat
(clojure.core/list (quote clojure.core/string?))
(clojure.core/list bar)))
And this does not evaluate to false. As such, the precondition is being
checked, it's just not checking what you want it to check.
Can somebody suggest me what am I missing? I want both the examples
above to be verified and passed as OK.
I think what you may want is something like:
{:pre [(string? (eval bar))]}
However, I must question whether or not you really want to be doing
this. The precondition is being evaluated a compile/macro-expansion
time, not run time. As such, you should probably only use pre- and
post-conditions on defmacro if they are checking the arguments to the
macro itself.
Just some thoughts.
Sincerely,
Daniel
--
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
into applied to transient vectors undocumented?
Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an *into!* version of *into *when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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: into applied to transient vectors undocumented?
into uses transient and persistent! for speed. The fact that into can take a transient as input is an accidental consequence of that, I think. Before into was changed to use transients internally, it could only take persistent data structures as input, and return a persistent data structure. Andy On Mar 20, 2012, at 10:32 AM, László Török wrote: Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an into! version of into when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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: into applied to transient vectors undocumented?
Ok, so the pattern is: func! (bang) takes a transient and returns a transient regular collection functions MAY take a transient but ALWAYS return a persistent collection, right? :) thx Las 2012/3/20 Andy Fingerhut andy.finger...@gmail.com into uses transient and persistent! for speed. The fact that into can take a transient as input is an accidental consequence of that, I think. Before into was changed to use transients internally, it could only take persistent data structures as input, and return a persistent data structure. Andy On Mar 20, 2012, at 10:32 AM, László Török wrote: Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an *into!* version of *into *when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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 -- László Török -- 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: into applied to transient vectors undocumented?
func! (bang) is a naming convention from the programming language Scheme that Clojure often uses. In general it means that the function mutates data, i.e. it is not a pure function. Clojure does not have a ! after all of its core functions that do this, but it does after some. In particular, the functions that operate on transients like conj! assoc! persistent! etc. mutate their arguments. Many (maybe most) regular collection functions do not take transients. As I said, I think it is an accident, not by design, that 'into' can take a transient as an argument. Originally it only took persistent collections as arguments (perhaps also seqs, but those are immutable, too). Andy On Mar 20, 2012, at 11:17 AM, László Török wrote: Ok, so the pattern is: func! (bang) takes a transient and returns a transient regular collection functions MAY take a transient but ALWAYS return a persistent collection, right? :) thx Las 2012/3/20 Andy Fingerhut andy.finger...@gmail.com into uses transient and persistent! for speed. The fact that into can take a transient as input is an accidental consequence of that, I think. Before into was changed to use transients internally, it could only take persistent data structures as input, and return a persistent data structure. Andy On Mar 20, 2012, at 10:32 AM, László Török wrote: Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an into! version of into when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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 -- László Török -- 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: understanding data structures, and other low-level stuff
On 03/15/2012 09:15 PM, Nic Long wrote: So I guess I'm asking whether anyone can recommend some good primers on data structures, both as they relate to Clojure, but also how they work in the fundamentals - e.g. what exactly is the classic model of an 'array' and how does it work, etc. I have read the various performance commitments for the data-types in Clojure on the .org site but even things like Big O notation are still pretty new to me. I'm sure this stuff is pretty basic for many, but I don't know it and would like to! I'm not afraid of some heavy reading; I'd rather get a really deep and solid grasp of the fundamentals, then a quick surface-level solution. If I'm to develop as a programmer I feel like I need to get looking under the hood as it were, even though I can get by in PHP (for the most part anyway) without this kind of understanding. I can't recommend Sedgewick and Wayne's Algorithms [1] enough. It's not heavy reading at all; I'm amazed at how readable the book is considering the subject matter. In addition to the great writing the algorithms are presented as Java source code, and their operation is visualized, so you have three ways of looking at each algorithm, which really helps to understand them. The book is also excellently structured, only introducing a handful of new concepts at a time, so reading it cover to cover you will very rarely feel out of your depth. [1] http://amzn.com/032157351X -- Timo -- 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: into applied to transient vectors undocumented?
(def into! #(reduce conj! %1 %2))? On Mar 20, 10:32 am, László Török ltoro...@gmail.com wrote: Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an *into!* version of *into *when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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: Literate programming in emacs - any experience?
I'm using org-mode, org-babel swank for a living document I'm writing. I'm generating a PDF which includes documentation, working clojure code that generates incanter graphs. Also the generated incanter graphs are included in the generated (latex) PDF. On Monday, January 23, 2012 3:14:09 AM UTC-10, Colin Yates wrote: Hi all, There are some excellent resources on this mailing list regarding literate resources, but they are more based around the theory rather than actual use. Has anybody got any real world usage reports regarding using literate programming in emacs? In particular, does paredit and slime work inside the clojure fragments when using org.babel for example? Finally - how are people finding practising TDD with literate programming? I imagine that Clojure's excellent REPL (+ evaluating clojure forms from within a buffer) mean there are far less type, extract tangled code, run tests needed. Hmmm, not sure that is clear. What I mean is, do people find that the ability to evaluate a clojure form from within org.babel (assuming that is possible!) is sufficient for TDD or do you find you need to type, extract the tangled code and then run lein (for example) to run the tests? Basically - how do y'all get on with TDDing in emacs following the approach of literate programming - any advice welcome! Thanks all. Col -- 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: understanding data structures, and other low-level stuff
I have to tip my hat to Daniel Spiewak's talk at Clojure/conj 2011: http://blip.tv/clojure/daniel-spiewak-extreme-cleverness-functional-data-structures-in-scala-5970151 I learned a lot from it. Cheers, '(Devin Walters) On Tuesday, March 20, 2012 at 12:56 PM, Timo Mihaljov wrote: On 03/15/2012 09:15 PM, Nic Long wrote: So I guess I'm asking whether anyone can recommend some good primers on data structures, both as they relate to Clojure, but also how they work in the fundamentals - e.g. what exactly is the classic model of an 'array' and how does it work, etc. I have read the various performance commitments for the data-types in Clojure on the .org site but even things like Big O notation are still pretty new to me. I'm sure this stuff is pretty basic for many, but I don't know it and would like to! I'm not afraid of some heavy reading; I'd rather get a really deep and solid grasp of the fundamentals, then a quick surface-level solution. If I'm to develop as a programmer I feel like I need to get looking under the hood as it were, even though I can get by in PHP (for the most part anyway) without this kind of understanding. I can't recommend Sedgewick and Wayne's Algorithms [1] enough. It's not heavy reading at all; I'm amazed at how readable the book is considering the subject matter. In addition to the great writing the algorithms are presented as Java source code, and their operation is visualized, so you have three ways of looking at each algorithm, which really helps to understand them. The book is also excellently structured, only introducing a handful of new concepts at a time, so reading it cover to cover you will very rarely feel out of your depth. [1] http://amzn.com/032157351X -- Timo -- 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 (mailto: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 (mailto: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
revisiting community funding?
There was a brief period of community funding for Rich's work back in 2010. When that ended, we now know the result was Datomica huge win. But there are other people who work on Clojure and Clojurescript; great things could happen from the focus that comes from being able to work on them full time. I know I'd be willing to give a couple hundred to fund such an effort, and given how much people spend to go to conferences, I'd be surprised if many others didn't feel the same way. And then there are now many companies that depend on Clojure. I'm curious how Clojure/core would feel about this. Is there still a concern about creating unreasonable expectations? Are there people outside Clojure/core who would be willing to work on something? -- 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
Passing data out of closure into the outer context
Greetings, I've stumbled across the following problem, which I believe is common and should have some sort of generic solution. Imagine I have ... ;; code inside defn ;; I extract some information out of my atom in closure: (swap! my-atom (fn [val] (let [extracted-info1 (extract-something-from val) extracted-info2 (extract-something-else-from val)] ;; update the atom (- val (assoc ...) (assoc) ;; out of swap! ;; still code inside defn ;; now, here I need to use those extracted-info1, extracted-info2 that I got out of atom inside swap! operation ;; What would be the common way to pass that information here? Using vals doesn't sound right. Have a beer! 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: Returning Success
Alright. 1) Why I need success state: this is a turn-based game, and I want to advance the world clock if and only if the player makes a valid move. 2) identical? makes sense. I generated some unnecessarily large data structure and checked, it really is ridiculously fast. Thanks! 3) Returning nil also makes sense... actually. It makes way too much sense. This is what happens when you overthink problems. :D Thanks for all the replies! -- 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: understanding data structures, and other low-level stuff
Hey, just want to say thanks for all the advice! And Andy especially for the kind offer - I may well PM some specific questions once I start reading. The Cormen et al. book looks great - tough but exactly what I need - so I'm going to pick up a copy. And I'll also read the PhD thesis on Functional Data Structures suggested by Nuno. On Mar 19, 8:02 pm, Nuno Marques nuno.filipe.marq...@gmail.com wrote: This book: Purely Functional Data Structureshttp://www.cs.cmu.edu/~rwh/theses/okasaki.pdf is a good read. Though, It only contains a small reference (half a page) about persistent data structures. On Mar 19, 2012, at 7:28 PM, Andy Fingerhut wrote: I've got my copy of Cormen, Leiserson, and Rivest's book with me now, which is the 3rd edition, and looking in the index under persistent it does have one exercise in chapter 13 on that topic, and a mention later in the book that is a paragraph or two long with a reference to a research paper. So while that book isn't a good reference for persistent data structures in particular, it is a good reference for the more widely known (and some not-so-widely known) mutable data structures. If you learn at least a few of those, then you are very well prepared to understand Clojure's persistent data structures, too, and there are blog posts on the topic that can get you a lot of the way there (once you understand the basics), e.g.: http://blog.higher-order.net/2009/09/08/understanding-clojures-persis... The book does assume a knowledge of how basic arrays work, but those are quite simple and hopefully my message below is nearly as much as there is to know about them. To get an understanding of data structures like hash tables and some different kinds of trees, you can probably get there just reading a few of the introductory sections at the beginning, and then jump to those specific sections. Save all the stuff on algorithms for when and if you are interested. Andy On Mar 18, 2012, at 8:57 PM, Andy Fingerhut wrote: Feel free to ask follow-up questions on the basics privately, since many Clojure programmers are probably already familiar with them, whereas follow-up questions on persistent data structures are very on-topic, since I would guess many people who have studied computer science and/or programming for a while may not be familiar with them. The classic model of an array is based upon the implementation of physical RAM in a computer: a physical RAM, at a high level and leaving out details of variations, is a device where you either give it a command READ and an address, and it returns an 8-bit byte stored at that location, or you give it a WRITE command, an address, and an 8-bit value, and it stores the 8-bit value at the location given by the address. A classic array is a one-dimensional structure indexed by an integer i, usually from 0 up to some maximum value N, and every item in the array stores an item of the same size and type, e.g. all 32-bit integers, or all pointers to some object elsewhere in the memory. If every item fits in exactly B bytes, and the first item of the array begins at address A in the memory, then item i will be at address A+B*i in the memory. In terms of performance, computers are designed to be able to access any address in their memory in the same amount of time, no matter what address it is stored at, so with a couple of instructions to calculate A+B*i, the computer can read or write any element of an array within a constant amount of time (constant meaning it doesn't get larger or smaller depending upon the size of the array -- it is always the same no matter the array's size). With other non-array data structures like trees, accessing an element takes longer as the data structure grows to contain more items. I don't recall if it covers persistent data structures like the ones most commonly used in Clojure, but Cormen, Leiserson, and Rivest's Introduction to Algorithms is used in many colleges as a text in courses on algorithms and data structures. There are probably other books that would be better as a primer, and it does assume you are comfortable with at least algebra and a bit more math, but if you got through a chapter of it and understood even half of it, you'd have learned something worth knowing about the subject. http://www.amazon.com/Introduction-Algorithms-Includes-CD-Rom-Thomas/... There is a newer edition than the one I linked to, but an older used copy for $25.00 might be closer to what you want if you aren't sure yet. Andy On Mar 15, 2012, at 12:15 PM, Nic Long wrote: Hi all, I am starting to learn Clojure after buying the book 7 Languages in 7 Weeks (really interesting read) and working through the examples there. But my background is PHP (and no Computer Science degree) so my understanding of data structures and
Re: Clojure code optimizer
Thank you for the clarifications and the resources, I understand now what tree shaking is. In fact, I had a project last year at our college to implement (in Scheme) a constant folding optimizer for Scheme programs, I now see the resemblance with what you described. The program would optimize functions like: (define some-function (lambda (x) (if ( x (+ 2 4)) (- 7 (car ‘(1 2 3))) (cons x 4))) Turning it into (define some-function (lambda (x) (if ( x 6) 6 (cons x 4 Also, when finding conditional statements in which the test condition is known (can be evaluated) to replace it with the code which runs on the appropriate branch. For example, replacing: (if (or #f #t) then-code else-code) With then-code Same thing for cond. Another part of the project was to classify recursive functions into stack recursive, tree recursive or iterations. I was thinking that a similar program for Clojure could detect stack recursive functions and replace them with their iterative counterparts, though this can be somewhat difficult as various loop-holes can arise that would fool the program. I suppose an approach can be found which makes the best out of both worlds: a tree shaker and constant folding implementation + an automated program which detects recursions and replaces them with more efficient versions and a rule-based system to cover some cases which the first approach misses. Andru Gheorghiu On Mar 20, 1:31 am, Sanel Zukan san...@gmail.com wrote: Hi Andru and thank you for expressing interest in this proposal. Could you please give more details (or examples) on the types of optimizations the optimizer should be able to do? Also, what is a tree shaker implementation? As David wrote, this is dead code elimination and in LISP world is also known as tree shaking. Contrary to pattern matching (for which you expressed desire), dead code elimination is usually more advanced approach, sometimes requiring passing through the code multiple times, inspecting compiler facilities or simply doing a bunch of tricks to remove obvious and not so obvious unused code. Take this example: (defonce *always-true* true) (if *always-true* (println Always executed) (println Never executed)) Matching this case could be hard for pattern matching tools; they often do not understand the content outside given pattern. True optimizer would pick up *always-true* and notice it will never be changed for this block. However, if I do some weird magic inside some function and globally change the value of *always-true* at some point, optimizer should recognize this case or would remove valid code. Also, often case for optimizers is to precompute simple expressions in compilation phase yielding static values, like: (let [a 0 b (+ a 1)] (if something b)) here it could rewrite whole block as: (if something 1) or even can recognize Clojure patterns like: (apply + (range 1 10)) where the pattern matching approach could rewrite expression to (+ 1 2 3 4 5 6 ... 9) and optimizer would simply produce 45. Using this case you can see how pattern matching can be a part of optimizer. I'm hoping I manage to fully describe you an idea behind this proposal. Of course, taking some expert system approach and doing Kibit-style matching can be a good starting point too :) Also, if you are interested to take tree shaking way, a good starting point can be SBCL alpha shaker athttp://jsnell.iki.fi/tmp/shake.lisp. Unfortunately without documentation, but the code is quite easy to follow. Sanel On Saturday, March 17, 2012 10:59:44 PM UTC+1, Andru Gheorghiu wrote: Hello, I am a third year student majoring in computer science and I am interested in the Clojure code optimizer project proposed for GSoC 2012. Could you please give more details (or examples) on the types of optimizations the optimizer should be able to do? Also, what is a tree shaker implementation? I was thinking that an optimizer could be implemented as a rule engine similar to Jess or CLIPS in which rules contains patterns which need to be replaced and the code to replace them with. For example one could write patterns for generic linear recursive functions that should be replaced with linear iterative functions. Similarly patterns can be written for functions which replicate the behavior of an already existing function (such as reverse, map, apply etc) and a rule to replace those functions with the predefined ones. Thank you, Andru Gheorghiu -- 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
SuperDevMode and SourceMaps for ClojureScript debugging
Ray Cromwell https://plus.google.com/u/1/110412141990454266397/posts, a Google employee, has recently announced new feature in Chrome Dev Tools: SuperDevMode and SourceMapshttps://plus.google.com/u/1/110412141990454266397/posts/Nvr6Se6eAPh. It helps to map source code written in programming language that targets JavaScript run-time (e.g. CoffeeScript) to resulting JavaScript code. Is it feasible to utilize it to debug ClojureScript in a browser? Please share your thoughts. -- 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
ClojureScriptOne design
I have added a new model cljs file in my dev One app , but when I use it in the controller, that one doesnt see it. Any idea, suggestion? 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: SuperDevMode and SourceMaps for ClojureScript debugging
On Tue, Mar 20, 2012 at 2:45 PM, Alexander Zolotko azolo...@gmail.comwrote: Ray Cromwell https://plus.google.com/u/1/110412141990454266397/posts, a Google employee, has recently announced new feature in Chrome Dev Tools: SuperDevMode and SourceMapshttps://plus.google.com/u/1/110412141990454266397/posts/Nvr6Se6eAPh. It helps to map source code written in programming language that targets JavaScript run-time (e.g. CoffeeScript) to resulting JavaScript code. Is it feasible to utilize it to debug ClojureScript in a browser? Please share your thoughts. Yep, looks promising and we definitely want to support it. Would love to see someone tackle this project. 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: Passing data out of closure into the outer context
On Tue, Mar 20, 2012 at 11:16 AM, Tom Krestle tom.kres...@gmail.com wrote: Greetings, I've stumbled across the following problem, which I believe is common and should have some sort of generic solution. Imagine I have ... ;; code inside defn ;; I extract some information out of my atom in closure: (swap! my-atom (fn [val] (let [extracted-info1 (extract-something-from val) extracted-info2 (extract-something-else-from val)] ;; update the atom (- val (assoc ...) (assoc) ;; out of swap! ;; still code inside defn ;; now, here I need to use those extracted-info1, extracted-info2 that I got out of atom inside swap! operation ;; What would be the common way to pass that information here? Using vals doesn't sound right. Have a beer! Tom The ugly way, as you noted, is to change the atom from some-map to [some-map extracted-info-from-last-swap]. A less ugly way might be (let [ei (atom nil)] (swap! my-atom ... (reset! ei extracted-info1) ...) (do-things-with ei)) If the swap! is retried, the ei atom will be reset! more than once, but it will after the swap! contain the extracted-info1 from the successful swap! of my-atom. The most functional way would be to see if you couldn't do the work with ei *inside* the closure. However, if it's expensive or side-effecty that doesn't play nice with swap! retrying. In that instance, you might want to think of replacing my-atom with my-ref and doing something like (dosync (alter my-ref ... (send-off ei-agent ei-do-things-func extracted-info1) ...)) Agent sends are held until a transaction commits, so the ei-do-things-func will be called only once for each transaction on my-ref. -- 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: revisiting community funding?
On 20 mar, 21:09, nchurch nchubr...@gmail.com wrote: But there are other people who work on Clojure and Clojurescript; great things could happen from the focus that comes from being able to work on them full time. I know I'd be willing to give a couple hundred to fund such an effort, and given how much people spend to go to conferences, I'd be surprised if many others didn't feel the same way. […Is there still a concern about creating unreasonable expectations? Are there people outside Clojure/core who would be willing to work on something? FWIW, I'd also be willing to contribute on funding. I'd be glad to contribute anonymously if that would avoid any concern of unreasonable expectations (nobody, including Clojure/core member would need to know that *I* contributed). Best Regards, B. -- 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: into applied to transient vectors undocumented?
Sorry, I said something incorrect. into cannot take transients as the first arg. It calls transient internally on the first arg for speed. This does not modify the value you passed in at all -- it creates a new transient data structure from what you pass in. If you try calling transient on a data structure that is already a transient, you get an error. Thus this gives an error: user= (def x [1 2 3]) #'user/x user= (def tx (transient x)) #'user/tx user= (into tx [5 6 7]) ClassCastException clojure.lang.PersistentVector$TransientVector cannot be cast to clojure.lang.IPersistentCollection clojure.core/conj (core.clj:83) user= (into x [5 6 7]) [1 2 3 5 6 7] Andy On Mar 20, 2012, at 11:30 AM, Andy Fingerhut wrote: func! (bang) is a naming convention from the programming language Scheme that Clojure often uses. In general it means that the function mutates data, i.e. it is not a pure function. Clojure does not have a ! after all of its core functions that do this, but it does after some. In particular, the functions that operate on transients like conj! assoc! persistent! etc. mutate their arguments. Many (maybe most) regular collection functions do not take transients. As I said, I think it is an accident, not by design, that 'into' can take a transient as an argument. Originally it only took persistent collections as arguments (perhaps also seqs, but those are immutable, too). Andy On Mar 20, 2012, at 11:17 AM, László Török wrote: Ok, so the pattern is: func! (bang) takes a transient and returns a transient regular collection functions MAY take a transient but ALWAYS return a persistent collection, right? :) thx Las 2012/3/20 Andy Fingerhut andy.finger...@gmail.com into uses transient and persistent! for speed. The fact that into can take a transient as input is an accidental consequence of that, I think. Before into was changed to use transients internally, it could only take persistent data structures as input, and return a persistent data structure. Andy On Mar 20, 2012, at 10:32 AM, László Török wrote: Hi, While implementing qsort with clojure for fun, I thought about using transient vectors to speed up sorting vs the naive functional implementation. I need an into! version of into when joining two sorted subarrays and I was wondering why there isn't one. It seems that (source into) does in fact support a transient collection as the first argument, however it calls persistent! on the result. What was the rationale behind the decision? (Note: I'm not questioning it, just interested.) Is there a particular reason why this feature remains undocumented? -- László Török -- 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 -- László Török -- 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: Returning Success
On Mon, 2012-03-19 at 03:56 -0700, Narvius wrote:
2) Return [new-state success?] instead of just new-state - requires too
much acrobatics from the user of the function (which is still me, but
whatever).
Don't be so sure...you can arrange for values on the side to be
readable and writable at various code depths.
https://bazaar.launchpad.net/~scompall/+junk/clojure-stuff/view/head:/src/com/nocandysw/cloj_dummy/punch.clj
(play-a-round [])
[nil {:opponent {:health 100, :shouts []}, :stamina 75}]
(play-a-round [[50 true]])
[:won! {:opponent {:health 0, :shouts [Uggh...]}, :stamina 25}]
(play-a-round [[10 false] [10 false] [50 true]])
[:won! {:opponent {:health -20, :shouts [Ow! Ow! Uggh...]}, :stamina 5}]
(play-a-round [[80 false]])
[:out-of-stamina! {:opponent {:health 100, :shouts []}, :stamina 75}]
(As an exercise, make it possible to lose this game.)
Moreover, there are many other useful HOFs I didn't use in this example,
for the sake of introduction. For example, use m-lift to inject a
normal function into the monadic data flow.
4) Allow an optional last argument to world-modifying functions which is an
atom that gets set to the success value. This is what I ultimately settled
for, and I think it is somewhat elegant. That way I minimize the side
effects to a level I can fully control.
It is slightly less elegant than `out' parameters in C#. How F# treats
those parameters is instructional: it converts any method using them
into a method that simply returns the extra results in a tuple with the
primary return value.
--
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better
--
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
