Re: into applied to transient vectors undocumented?

[László Török]

Hi,
I'm not sure why I said it can be. My original post was going to be about
why there isn't a into! (Thanks Alan for the hint!)

I think the

(if (instance? clojure.lang.IEditableCollection to)

line made me draw false conclusions. It was a bit late, apologies for the
noise and thx!

2012/3/20 Andy Fingerhut 

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



-- 
László Török

-- 
You received this message because you are subscribed to the Goo

Re: Returning Success

[Stephen Compall]

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

Re: into applied to transient vectors undocumented?

[Andy Fingerhut]

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 
>> 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: revisiting community funding?

[bernardH]

On 20 mar, 21:09, nchurch  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: Passing data out of closure into the outer context

[Cedric Greevey]

On Tue, Mar 20, 2012 at 11:16 AM, Tom Krestle  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: SuperDevMode and SourceMaps for ClojureScript debugging

[David Nolen]

On Tue, Mar 20, 2012 at 2:45 PM, Alexander Zolotko wrote:

> Ray Cromwell , a
> Google employee, has recently announced new feature in Chrome Dev Tools: 
> SuperDevMode
> and 
> SourceMaps.
>  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

SuperDevMode and SourceMaps for ClojureScript debugging

[Alexander Zolotko]

Ray Cromwell , a 
Google employee, has recently announced new feature in Chrome Dev Tools: 
SuperDevMode 
and 
SourceMaps.
 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

[Pierre-Henry Perret]

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

Passing data out of closure into the outer context

[Tom Krestle]

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

[Narvius]

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

[Nic Long]

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

Re: Clojure code optimizer

[Andru Gheorghiu]

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

revisiting community funding?

[nchurch]

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

Re: understanding data structures, and other low-level stuff

[Devin Walters]

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

Re: Literate programming in emacs - any experience?

[Tim Dysinger]

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: into applied to transient vectors undocumented?

[Alan Malloy]

(def into! #(reduce conj! %1 %2))?

On Mar 20, 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

Re: understanding data structures, and other low-level stuff

[Timo Mihaljov]

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?

[Andy Fingerhut]

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 
> 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: into applied to transient vectors undocumented?

[László Török]

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 

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

[Andy Fingerhut]

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

into applied to transient vectors undocumented?

[László Török]

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: Precondition asserts in macros

[Shantanu Kumar]

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

Google Summer of Code 2012 Mentors please put yourself into Melange

[David Nolen]

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: Clojure for banking and invenstment system?

[Thomas]

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

Re: Clojure for banking and invenstment system?

[Bill Smith]

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: Precondition asserts in macros

[Chas Emerick]

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

Clojure for banking and invenstment system?

[Roller]

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: Parallel SSH and system monitoring in Clojure

[Paulo Suzart]

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

> You might interested in clojure-control[1], which has similar
> functionality to your library.
>
> [1] 
> https://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-**Clojure
>>
>> https://github.com/RJMetrics/**Parallel-SSH
>>
>> https://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.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

[George Oliver]

On Mar 19, 3:56 am, Narvius  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

[Aaron Craelius]

Not yet.  I'll have to take care of that.

On Mon, Mar 19, 2012 at 5:48 PM, David Nolen  wrote:

> On Mon, Mar 19, 2012 at 1:36 PM, Aaron  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: Precondition asserts in macros

[Bronsa]

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: Precondition asserts in macros

[Justin Kramer]

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

[Daniel Solano Gomez]

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

[Chas Emerick]

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

Precondition asserts in macros

[Shantanu Kumar]

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: Parallel SSH and system monitoring in Clojure

[Hugo Duncan]

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

Re: Mapping first element only: how to preserve vectors

[Rasmus Svensson]

On Mon, Mar 19, 2012 at 2:40 PM, Bojan  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: beginner help with views in ClojureScript One?

[Simon Holgate]

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