Re: Idiomatically returning one or two values from a function.

[Tassilo Horn]

Meikel Brandmeyer  writes:

> you can return always a vector.
>
> (fn [] [true])
> (fn [] [true {:foo 12}])
>
> And then use destructuring on the return value.
>
> (let [[value annotations] (...)]
>   (when annotations
> ..))

My first idea was to add metadata to the return value, but that doesn't
work for java types like Boolean.  As a workaround, you could let your
functions return

(defn foo []
  ;; calculate real-return-val
  (with-meta (constantly real-return-val)
{:foo 1, :bar 2}))

Wrap that in a `annotated-return' macro and always use that in your
functions.  The cost is, that now `foo' returns a function returning the
result, so you have to call it using ((foo)) or (apply (foo))...

But at least you can then do

(let [f (foo)
  r (f)
  m (meta f)]
  ;; the result is r, the metadata is m
  )

Again, wrap that in some `annotated-call' macro, so that you can do

  (annotated-call foo [result meta]
(do-stuff-with result meta))

Hm, but well, that's only a workaround.  Metadata could be so useful if
it was possible to attach it to anything, not only anything in clojure.
I myself once had the need to put metadata on java objects, but that
doesn't work either...

Bye,
Tassilo

-- 
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: error after install java IO file not found

[Luc Prefontaine]

Two things:

a) You are running an example written for Clojure 1.2.1 but you try to run it 
with 1.3.0.
   This is likely to create problems by itself.

b) You did not specify the clojure contrib library on your class path. Note that
   the clojure contrib predating 1.3 (contrib version 1.2) is not
   compatible with Clojure 1.3.

Download Clojure 1.2.1 and the 1.2 contrib kit from here 
http://clojure.org/downloads

And then add contrib to the Java classpath as follow:

C:\clojure-1.2.1>java -cp c:/clojure-contrib-1.2/clojure-contrib-1.2.jar -jar 
c:/clojure-1.2.1/clojure-1.2.1.jar c:/clojure-1.2.1/examples/snake.clj

I am assuming that contrib will expand in clojure-contrib-1.2 and that the jar 
will be named clojure-contrib-1.2.jar
but check the actual names and substitute them accordingly in the command line 
above.

Luc

On Wed, 28 Sep 2011 22:52:38 -0700 (PDT)
jayvandal  wrote:

> I installed clojure from Programming Clojure page 12.
> I try to run snake.clj.
> This is what I get
> What causes this??
> Thanks
> ==
> 
> C:\clojure-1.3.0>java -jar c:/clojure-1.3.0/clojure-1.3.0.jar 
> c:/clojure-1.2.1/e
> xamples/snake.clj
> Exception in thread "main" java.lang.RuntimeException: 
> java.io.FileNotFoundExcep
> tion: Could not locate clojure/contrib/import_static__init.class or 
> clojure/cont
> rib/import_static.clj on classpath:
> at clojure.lang.Util.runtimeException(Util.java:165)
> at clojure.lang.Compiler.eval(Compiler.java:6476)
> at clojure.lang.Compiler.eval(Compiler.java:6455)
> at clojure.lang.Compiler.load(Compiler.java:6902)
> at clojure.lang.Compiler.loadFile(Compiler.java:6863)
> at clojure.main$load_script.invoke(main.clj:282)
> at clojure.main$script_opt.invoke(main.clj:342)
> at clojure.main$main.doInvoke(main.clj:426)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.lang.Var.invoke(Var.java:401)
> at clojure.lang.AFn.applyToHelper(AFn.java:161)
> at clojure.lang.Var.applyTo(Var.java:518)
> at clojure.main.main(main.java:37)
> Caused by: java.io.FileNotFoundException: Could not locate 
> clojure/contrib/impor
> t_static__init.class or clojure/contrib/import_static.clj on
> classpath: at clojure.lang.RT.load(RT.java:430)
> at clojure.lang.RT.load(RT.java:398)
> at clojure.core$load$fn__4610.invoke(core.clj:5386)
> at clojure.core$load.doInvoke(core.clj:5385)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5200)
> at clojure.core$load_lib.doInvoke(core.clj:5237)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:602)
> at clojure.core$load_libs.doInvoke(core.clj:5271)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:604)
> at clojure.core$use.doInvoke(core.clj:5363)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at
> examples.snake$eval3$loading__4505__auto4.invoke(snake.clj:8) at
> examples.snake$eval3.invoke(snake.clj:8) at
> clojure.lang.Compiler.eval(Compiler.java:6465) ... 11 more
> 
> C:\clojure-1.3.0>
> 



-- 
Luc P.


The rabid Muppet

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

error after install java IO file not found

[jayvandal]

I installed clojure from Programming Clojure page 12.
I try to run snake.clj.
This is what I get
What causes this??
Thanks
==

C:\clojure-1.3.0>java -jar c:/clojure-1.3.0/clojure-1.3.0.jar 
c:/clojure-1.2.1/e
xamples/snake.clj
Exception in thread "main" java.lang.RuntimeException: 
java.io.FileNotFoundExcep
tion: Could not locate clojure/contrib/import_static__init.class or 
clojure/cont
rib/import_static.clj on classpath:
at clojure.lang.Util.runtimeException(Util.java:165)
at clojure.lang.Compiler.eval(Compiler.java:6476)
at clojure.lang.Compiler.eval(Compiler.java:6455)
at clojure.lang.Compiler.load(Compiler.java:6902)
at clojure.lang.Compiler.loadFile(Compiler.java:6863)
at clojure.main$load_script.invoke(main.clj:282)
at clojure.main$script_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:426)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:401)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.Var.applyTo(Var.java:518)
at clojure.main.main(main.java:37)
Caused by: java.io.FileNotFoundException: Could not locate 
clojure/contrib/impor
t_static__init.class or clojure/contrib/import_static.clj on classpath:
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:398)
at clojure.core$load$fn__4610.invoke(core.clj:5386)
at clojure.core$load.doInvoke(core.clj:5385)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5200)
at clojure.core$load_lib.doInvoke(core.clj:5237)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5271)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:604)
at clojure.core$use.doInvoke(core.clj:5363)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at examples.snake$eval3$loading__4505__auto4.invoke(snake.clj:8)
at examples.snake$eval3.invoke(snake.clj:8)
at clojure.lang.Compiler.eval(Compiler.java:6465)
... 11 more

C:\clojure-1.3.0>

-- 
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: help understanding how map works

[Sean Corfield]

On Wed, Sep 28, 2011 at 6:32 PM, Cluj  wrote:
> Thank you! Obvious once someone explains it :)

You could also do: (map vector '("A" "B" "C"))
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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: help understanding how map works

[Cluj]

Thank you! Obvious once someone explains it :)


On Sep 28, 6:13 pm, Mark Engelberg  wrote:
> #([ % ]) is like:
> (defn wrap [ x ] ([ x ]) )
>
> not
> (defn wrap [ x ] [ x ] )

-- 
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: help understanding how map works

[Mark Engelberg]

#([ % ]) is like:
(defn wrap [ x ] ([ x ]) )

not
(defn wrap [ x ] [ x ] )

-- 
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: Type inheritance, porting from Java

[David Nolen]

There is no convenient way to inherit functionality. But there are a couple
other routes, perhaps one of these will appeal to you -

* Just use your rich Java library from Clojure, perhaps providing a high
performance integration the same way that Clojure does via RT.java and
inlining
* Use macros - see gvec.clj or defrecord.clj
* Write the shared code as helper functions that can deal with types via a
common access protocol

It's admittedly a real challenge taking a inheritance-centric design and
making it work in Clojure. But I consider it a fun and eye-opening one.

David

On Wed, Sep 28, 2011 at 6:40 AM, toxi  wrote:

> Dear Clojurians,
>
> I picked up Clojure a few months ago and find it hugely fascinating.
> I've been working mainly with Java for the past few years and now
> trying to overcome the un-learning curve in regards to polymorphism
> and solving it with records & protocols instead.
>
> My aim is to port my library collection (http://toxiclibs.org) to
> Clojure. The core libs contain several type hierarchies of geometric
> entities (vectors, particles, shapes etc.) So I'm currently trying to
> find the best solution to the following (but would just like to get my
> head around this kind of problem in general):
>
> In Java I've got a Vec2D class which has a large amount of methods
> (80+) for vector algebra. I've also got a VerletParticle2D which
> subclasses Vec2D, and adds a bunch of new properties (and methods). In
> Java I only needed to implement the generic vector behaviours (adding,
> normalizing, scaling etc.) once in the Vec2D class and they become
> automatically available in VerletParticle2D. In Clojure I've tried to
> achieve this with protocols, but I can't see a way how to provide the
> same thing without having to re-implement the entire IVec2D protocol
> for both record types. The following works of course, but IMHO
> violates the DRY principle:
>
> (defprotocol IVec2D
>  (vadd [this v] "produces 2d vector sum of given vectors"))
>
> (defrecord Vec2D [^double x ^double y]
>  IVec2D
>  (vadd [this v] (Vec2D. (+ x (:x v)) (+ y (:y v)
>
> (defrecord VerletParticle2D
>  [^double x ^double y ^double mass behaviors constraints]
>  IVec2D
>  (vadd [this v]
>(VerletParticle2D. (+ x (:x v)) (+ y (:y v)) mass behaviors
> constraints)))
>
> (def v (Vec2D. 23 42))
> (def p (VerletParticle2D. 11 22 3 [] []))
>
> (vadd v p) ; => #:user.Vec2D{:x 34.0, :y 64.0}
> (vadd p v) ; => #:user.VerletParticle2D{:x 34.0, :y 64.0, :mass
> 3.0, :behaviors [], :constraints []}
>
> The other option I thought of is using assoc instead of explicitly
> creating new instances and then injecting these implementations via
> the extend function:
>
> (def IVec2D-impl {
>  :vadd (fn [this v]
>(assoc this :x (+ (:x this) (:x v)) :y (+ (:y this) (:y v
> })
>
> (defrecord Vec2D [^double x ^double y])
> (defrecord VerletParticle2D [^double x ^double y ^double mass
> behaviors constraints])
>
> (extend Vec2D IVec2D IVec2D-impl)
> (extend VerletParticle2D IVec2D IVec2D-impl)
>
> This is more concise, but also quite a lot slower due to assoc. Are
> there any other options I can try to realise this? Also, in the latter
> case, why does (parents Vec2D) doesn't list IVec2D, but in the former
> it does? How can I express a VerletParticle2D is a Vec2D? Using derive
> doesn't work with records...
>
> Super grateful for any answers/pointers/solutions!
>
> Thanks, 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

help understanding how map works

[Cluj]

I am learning Clojure and have installed Clojure 1.2.0 in an Ubuntu 11
box.

While playing with the map function I ran into some behavior I don't
understand.

I tried to use map to change a list of strings into a list of vectors
of strings, something like:

("A" "B" "C") => ( [ "A"] ["B"] ["C"])

Inlining the function does not work:

user=> (map #([ % ]) '("A" "B" "C"))
java.lang.IllegalArgumentException: Wrong number of args (0) passed
to: PersistentVector
user=>

But defining an external function does:

user=> (defn wrap [ x ] [ x ] )
#'user/wrap
user=> (map #(wrap %) '("A" "B" "C"))
(["A"] ["B"] ["C"])
user=>

can someone explain to me why this is the case?

Thanks for your help in advance!


-- 
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: suggestion for clojure development

[Michael Gardner]

On Sep 28, 2011, at 7:20 PM, Arthur Edelstein wrote:

> So what's the plan for the future? Are there plans to make clojure
> stable at some point so that backward compatibility can be expected?
> Otherwise I am going to have difficulty continuing to advocate clojure
> to my colleagues. In other words, when will the library ecosystem be
> considered important enough not to break?

I don't think there will (nor should) ever be a declaration by the core team 
that "from this point onward, we will never break backwards compatibility." 
There's always a trade-off between maintaining backwards compatibility and 
making improvements to the language. Naturally, as the language matures the 
tradeoff will shift towards compatibility, but in my opinion it would be 
foolish to set anything in stone. I don't think the lack of any such promise 
has hurt Python, for example; and while the transition to 3.0 certainly seems 
to have been slow and painful, I don't doubt the language will survive.

> I think a statement of the policies of the Clojure/Core team (perhaps
> spelled out on the website) concerning stability and backward
> compatibility would really help those of us who want to be able to
> rely on Clojure.

I think the absence of such a statement makes it clear that although breaking 
backwards compatibility is obviously bad, the core team is making no 
hard-and-fast promises. This seems consistent with what other dynamic languages 
are doing, and is a Good Thing for the language in my view.

-- 
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: suggestion for clojure development

[cran1988]

Improve as much as possible , performances and memory management  !!






-- 
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: seeking advice for reducing boilerplate

[Eric Lavigne]

> While trying out clj-webdriver (for testing web pages), I got the impulse to
> reduce some of my boilerplate. I'd like your advice on best practices.

I would start with the main test macro, web-test. I would replace your
local variable b with a dynamically bound var *browser* that web-test
is responsible for setting. The options is a map that allows you to
specify browser and implicit-wait timeout like {:browser :firefox
:timeout 6} but has reasonable defaults so that you can usually
use {} instead.

(defvar ^:dynamic *browser* nil)

(defmacro web-test [name options & actions]
...)

(web-test test-login {}
(-> *browser* (find-it {:text "Login"})
click)
(-> *browser* (find-it {:class "text", :name "login"})
(input-text "username"))
(-> *browser* (find-it {:class "text", :name "password"})
(input-text "password"))
(-> *browser* (find-it :input {:value "Log in"})
click)
(is (-> *browser* (find-it {:href "/logout"})
present?)))

Next, I'd factor our the "(-> *browser* (find-it" pattern with another macro.

(defmacro web-action [search-parameters & actions]
...)

This converts

(-> *browser* (find-it {:text "Login"})
click)

into

(web-action {:text "Login"} click)

If there is a lot of clicking and entering text in fields, I might
also create click-it and write-it macros so that you can say:

(click-it {:text "Login"})

(write-it {:class "text", :name "login"} "username")

After all these changes, the original example becomes:

(web-test test-login {}
(click-it {:text "Login"})
(write-it {:class "text", :name "login"} "username")
(write-it {:class "text", :name "password"} "password")
(click-it {:value "Log in"})
(is (-> *browser* (find-it {:href "/logout"})
present?)))

Hmm, maybe needs an is-present macro as well?

(is-present {:href "/logout"})

If you have a lot of tests related to the same form, you can also make
shortcuts for commonly references elements:

(def login-text {:class "text", :name "login"})

After all these changes, tests like these should be very easy to write.

-- 
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: suggestion for clojure development

[Arthur Edelstein]

> I think that clojure/core team is doing its best to ensure backward
> compatibility and break it only when there are prevalent reasons to do
> it.

So what's the plan for the future? Are there plans to make clojure
stable at some point so that backward compatibility can be expected?
Otherwise I am going to have difficulty continuing to advocate clojure
to my colleagues. In other words, when will the library ecosystem be
considered important enough not to break?

I think a statement of the policies of the Clojure/Core team (perhaps
spelled out on the website) concerning stability and backward
compatibility would really help those of us who want to be able to
rely on Clojure.

Arthur

-- 
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: how do I use data.priority-map

[Sean Corfield]

No builds have yet been released to Maven.

You can, however, use the snapshot from Sonatype. Add the following to
project.clj:

  :repositories {"sonatype-oss-public"
"https://oss.sonatype.org/content/groups/public/"}

That causes Leiningen to search the Sonatype repository.

Then add this dependency:

  [org.clojure/data.priority-map "0.0.1-SNAPSHOT"]

That should get you going.

Sean

On Wed, Sep 28, 2011 at 3:21 PM, Sunil S Nandihalli
 wrote:
> after I posted the question .. I found this discussion . So, I guess it is
> not ready for prime-time yet .. (may be I am wrong)

-- 
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: how do I use data.priority-map

[Mark Engelberg]

I see it here:
https://oss.sonatype.org/content/groups/public/org/clojure/
so based on the version number here:
https://oss.sonatype.org/content/groups/public/org/clojure/data.priority-map/
I assume it can be added to one's project with a version number of
0.0.1-SNAPSHOT

I'm still trying to figure the 1.3 stuff out myself, so let me know if that
works.

Thanks,

Mark

-- 
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: Shameless self promotion - JavaOne

[Dennis]

I am not sure to what extent there will be recording.  However, I can
send you my slides after the presentation.

-- Dennis

On Wed, Sep 28, 2011 at 12:47 AM, Boris Mühmer
 wrote:
> Will there be any slides or maybe even a recording of this session?
>
> I would be very interested in this talk, but I can't go there...
>
>
> Regards,
> Boris
>
>
> 2011/9/27 Dennis :
>> Hey guys,
>>
>> I will be giving a talk at JavaOne (it is Clojure related).  Here is
>> the information.
>>
>> Title:          Monitoring a Large-Scale Infrastructure with Clojure
>> Time             Tuesday, 07:30 PM, Parc 55 - Embarcadero
>> Length          45 Minutes
>> Abstract:               Monitoring a large infrastructure brings unique 
>> challenges
>> that require blending development and operations concepts. This
>> session discusses how Dell Inc. used Clojure to develop a
>> data-flow-based monitoring system that stores, evaluates, and acts on
>> hundreds of thousands of metrics.
>>
>> It covers
>> • Real-world applications of Clojure's parallel programming constructs
>> to take advantage of multiple cores available in today's systems
>> • Using Clojure's homoiconic nature to create DSLs
>> • Taking advantage of Clojure running on the JVM to use the Java ecosystem
>> • How DevOps takes advantage of the JVM dynamic languages to develop
>> new monitoring tools
>> Track           Emerging Languages, Tools, and Techniques
>> Optional Track          The Java Frontier
>>
>> -- Dennis
>>
>> --
>> 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

-- 
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: seeking advice for reducing boilerplate

[Kevin Downey]

the browser bit should really use with-open

(with-open [browser (create-browser :firefox)]


On Wed, Sep 28, 2011 at 4:32 PM, Andrew  wrote:
> While trying out clj-webdriver (for testing web pages), I got the impulse to
> reduce some of my boilerplate. I'd like your advice on best practices.
> Here's the original code.
> (deftest test-login
>   (let [b (start :firefox "https://github.com";)]
>     (try
>       (implicit-wait b 6)
>       (-> b (find-it {:text "Login"}) click)
>       (-> b (find-it {:class "text", :name "login"}) (input-text
> "username"))
>       (-> b (find-it {:class "text", :name "password"}) (input-text
> "password"))
>       (-> b (find-it :input {:value "Log in"}) click)
>       (is (-> b (find-it {:href "/logout"}) present?))
>       (finally (-> b quit)
> In most of my tests, there's going to be (highlighted in red text above) the
> declaration of the browser, a tweak to how long to wait before declaring
> something not found, and a try-finally for closing the browser regardless of
> the test's outcome. I'd like a test definition to just list the browser type
> (e.g. :firefox) and the URL and the test steps... leaving out the let, the
> implicit-wait, and the try-finally. Can there be a macro that defines
> browser b for the test steps that I feed into it?
>
> For the test steps themselves, the way an html element is found (find-it
> {:text "Login"}) could be factored out and made re-usable...
> (defmacro login-link [browser & actions]
>   `(-> ~browser (find-it {:text "Login"}) ~@actions))
> (defmacro username [browser & actions]
>   `(-> ~browser (find-it {:class "text", :name "login"}) ~@actions))
> (defmacro password [browser & actions]
>   `(-> ~browser (find-it {:class "text", :name "password"}) ~@actions))
> (defmacro login-btn [browser & actions]
>   `(-> ~browser (find-it :input {:value "Log in"}) ~@actions))
> This allows my tests to look like this instead:
> (deftest test-login
>   (let [b (start :firefox "https://github.com";)]
>     (try
>       (implicit-wait b 6)
>       (login-link b click)
>       (username b (input-text "username"))
>       (password b (input-text "password"))
>       (login-btn b click)
>       (is (-> b (find-it {:href "/logout"}) present?))
>       (finally (-> b quit)
> Is this a good way to do it? Can my macros be changed to eliminate the
> mention of the browser b as the first argument? (I'm guessing this is bad
> practice) And is there something I can do to reduce the boilerplate in my
> macro definitions so that I can say this instead...
> (defelem login-link {:text "Login"})
> (defelem username {:class "text", :name "login"})
> (defelem password {:class "text", :name "password"})
> (defelem login-btn :input {:value "Log in"})
>
>
> --
> 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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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

Re: [ANN] Clojure 1.3 Released

[Sean Corfield]

On Tue, Sep 27, 2011 at 9:21 PM, Sidharth Kshatriya
 wrote:
> Can you tell me why Clojure scored over Scala for you.

For my Scala / Clojure anecdote, see:

http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0/

We like CFML for View templating and Controllers but we expect to
migrate most of our Model to Clojure over time...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
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: how do I use data.priority-map

[Sunil S Nandihalli]

after I posted the question .. I found this
discussion
.
So, I guess it is not ready for prime-time yet .. (may be I am wrong)

Thanks,
Sunil.

On Thu, Sep 29, 2011 at 3:34 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hello everybody,
>  can somebody help me figure out what I should add to my project.clj to
> use https://github.com/clojure/data.priority-map
>
> I am using clojure 1.3.
>
> Thanks,
> Sunil.
>

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

how do I use data.priority-map

[Sunil S Nandihalli]

Hello everybody,
 can somebody help me figure out what I should add to my project.clj to use
https://github.com/clojure/data.priority-map

I am using clojure 1.3.

Thanks,
Sunil.

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

Type inheritance, porting from Java

[toxi]

Dear Clojurians,

I picked up Clojure a few months ago and find it hugely fascinating.
I've been working mainly with Java for the past few years and now
trying to overcome the un-learning curve in regards to polymorphism
and solving it with records & protocols instead.

My aim is to port my library collection (http://toxiclibs.org) to
Clojure. The core libs contain several type hierarchies of geometric
entities (vectors, particles, shapes etc.) So I'm currently trying to
find the best solution to the following (but would just like to get my
head around this kind of problem in general):

In Java I've got a Vec2D class which has a large amount of methods
(80+) for vector algebra. I've also got a VerletParticle2D which
subclasses Vec2D, and adds a bunch of new properties (and methods). In
Java I only needed to implement the generic vector behaviours (adding,
normalizing, scaling etc.) once in the Vec2D class and they become
automatically available in VerletParticle2D. In Clojure I've tried to
achieve this with protocols, but I can't see a way how to provide the
same thing without having to re-implement the entire IVec2D protocol
for both record types. The following works of course, but IMHO
violates the DRY principle:

(defprotocol IVec2D
  (vadd [this v] "produces 2d vector sum of given vectors"))

(defrecord Vec2D [^double x ^double y]
  IVec2D
  (vadd [this v] (Vec2D. (+ x (:x v)) (+ y (:y v)

(defrecord VerletParticle2D
  [^double x ^double y ^double mass behaviors constraints]
  IVec2D
  (vadd [this v]
(VerletParticle2D. (+ x (:x v)) (+ y (:y v)) mass behaviors
constraints)))

(def v (Vec2D. 23 42))
(def p (VerletParticle2D. 11 22 3 [] []))

(vadd v p) ; => #:user.Vec2D{:x 34.0, :y 64.0}
(vadd p v) ; => #:user.VerletParticle2D{:x 34.0, :y 64.0, :mass
3.0, :behaviors [], :constraints []}

The other option I thought of is using assoc instead of explicitly
creating new instances and then injecting these implementations via
the extend function:

(def IVec2D-impl {
  :vadd (fn [this v]
(assoc this :x (+ (:x this) (:x v)) :y (+ (:y this) (:y v
})

(defrecord Vec2D [^double x ^double y])
(defrecord VerletParticle2D [^double x ^double y ^double mass
behaviors constraints])

(extend Vec2D IVec2D IVec2D-impl)
(extend VerletParticle2D IVec2D IVec2D-impl)

This is more concise, but also quite a lot slower due to assoc. Are
there any other options I can try to realise this? Also, in the latter
case, why does (parents Vec2D) doesn't list IVec2D, but in the former
it does? How can I express a VerletParticle2D is a Vec2D? Using derive
doesn't work with records...

Super grateful for any answers/pointers/solutions!

Thanks, 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: Shameless self promotion - JavaOne

[Boris Mühmer]

Will there be any slides or maybe even a recording of this session?

I would be very interested in this talk, but I can't go there...


Regards,
Boris


2011/9/27 Dennis :
> Hey guys,
>
> I will be giving a talk at JavaOne (it is Clojure related).  Here is
> the information.
>
> Title:          Monitoring a Large-Scale Infrastructure with Clojure
> Time             Tuesday, 07:30 PM, Parc 55 - Embarcadero
> Length          45 Minutes
> Abstract:               Monitoring a large infrastructure brings unique 
> challenges
> that require blending development and operations concepts. This
> session discusses how Dell Inc. used Clojure to develop a
> data-flow-based monitoring system that stores, evaluates, and acts on
> hundreds of thousands of metrics.
>
> It covers
> • Real-world applications of Clojure's parallel programming constructs
> to take advantage of multiple cores available in today's systems
> • Using Clojure's homoiconic nature to create DSLs
> • Taking advantage of Clojure running on the JVM to use the Java ecosystem
> • How DevOps takes advantage of the JVM dynamic languages to develop
> new monitoring tools
> Track           Emerging Languages, Tools, and Techniques
> Optional Track          The Java Frontier
>
> -- Dennis
>
> --
> 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: [ANN] Clojure 1.3 Released

[Sidharth Kshatriya]

Hi Sean,

Intrigued by your statement that:

On Wed, Sep 28, 2011 at 3:17 AM, Sean Corfield wrote:

> [...] We've converted all of our profile publishing and searching code to
> Clojure
> now (from Scala and CFML respectively) and we're liking the initial
> results we're seeing (improved stability and performance).
>
>
Can you tell me why Clojure scored over Scala for you. Or was the code a
mish-mash of Scala + CFML and that Clojure is just better than the
combination?

Thanks,

Sidharth

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

Who will be at QCon SF?

[Demetrius Nunes]

Hi guys,

I'd love to meet with fellow "clojurians" at QCon SF. How many of you will
be there?

cheers!
Demetrius

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

seeking advice for reducing boilerplate

[Andrew]

While trying out clj-webdriver (for testing web pages), I got the impulse to 
reduce some of my boilerplate. I'd like your advice on best practices. 
Here's the original code.

(deftest test-login
  (let [b (start :firefox "https://github.com";)]
(try
  (implicit-wait b 6)
  (-> b (find-it {:text "Login"}) click)
  (-> b (find-it {:class "text", :name "login"}) (input-text 
"username"))
  (-> b (find-it {:class "text", :name "password"}) (input-text 
"password"))
  (-> b (find-it :input {:value "Log in"}) click)
  (is (-> b (find-it {:href "/logout"}) present?))
  (finally (-> b quit)

In most of my tests, there's going to be (highlighted in red text above) the 
declaration of the browser, a tweak to how long to wait before declaring 
something not found, and a try-finally for closing the browser regardless of 
the test's outcome. I'd like a test definition to just list the browser type 
(e.g. :firefox) and the URL and the test steps... leaving out the let, the 
implicit-wait, and the try-finally. Can there be a macro that defines 
browser b for the test steps that I feed into it?

For the test steps themselves, the way an html element is found (find-it 
{:text "Login"}) could be factored out and made re-usable...

(defmacro login-link [browser & actions]
  `(-> ~browser (find-it {:text "Login"}) ~@actions))
(defmacro username [browser & actions]
  `(-> ~browser (find-it {:class "text", :name "login"}) ~@actions))
(defmacro password [browser & actions]
  `(-> ~browser (find-it {:class "text", :name "password"}) ~@actions))
(defmacro login-btn [browser & actions]
  `(-> ~browser (find-it :input {:value "Log in"}) ~@actions))

This allows my tests to look like this instead:

(deftest test-login
  (let [b (start :firefox "https://github.com";)]
(try
  (implicit-wait b 6)
  (login-link b click)
  (username b (input-text "username"))
  (password b (input-text "password"))
  (login-btn b click)
  (is (-> b (find-it {:href "/logout"}) present?))
  (finally (-> b quit)

Is this a good way to do it? Can my macros be changed to eliminate the 
mention of the browser b as the first argument? (I'm guessing this is bad 
practice) And is there something I can do to reduce the boilerplate in my 
macro definitions so that I can say this instead...

(defelem login-link {:text "Login"})
(defelem username {:class "text", :name "login"})
(defelem password {:class "text", :name "password"})
(defelem login-btn *:input* {:value "Log in"})



-- 
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: Are futures garbage-collected?

[Michael Jaaka]

I'm using futures for queuing jobs to stress test a server, multiple
processess,each reciving and futuring job. Works as expected for many
days with no problems in cpu and mem usage... Clojure rox.


On 28 Wrz, 22:48, Mark  wrote:
> The future object itself is garbage collected but the thread is not, so you
> should be ok.  

-- 
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: break-on-gaps - just curious if there is a more idiomatic way to do this

[Alan Malloy]

I wrote a generalized version of this called partition-between, which
you can see at 
https://github.com/flatland/useful/blob/develop/src/useful/seq.clj#L181
if you're interested. Using that as a primitive, your break-on-gaps
function is simple:

user> (partition-between (fn [[a b]] (not= a (dec b))) [1 2 3 5 6 7 8
10 20 21])
([1 2 3] [5 6 7 8] [10] [20 21])

On Sep 28, 11:39 am, qhfgva  wrote:
> I've been working on problems from "Programming Challenges" (Skiena)
> to learn clojure.  As part of a problem I developed the following
> routine.  I sort of scare myself how natural thinking in reduce is
> getting, but I was wondering if there is a more clever/idiomatic way
> to solve this problem.
>
> (defn break-on-gaps [minutes]
>   (reduce (fn [acc x]
>             (if (empty? acc)
>               [[x]]
>               (if (= (inc (last (last acc))) x)
>                 (conj (vec (butlast acc))
>                       (conj (last acc) x))
>                 (conj acc [x]
>           []
>           minutes))
>
> user=> (break-on-gaps [1 2 3 5 6 7 8 10 20 21])
> [[1 2 3] [5 6 7 8] [10] [20 21]]

-- 
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: Are futures garbage-collected?

[Mark]

The future object itself is garbage collected but the thread is not, so you 
should be ok.  

-- 
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: Are futures garbage-collected?

[Matt Hoyt]

It won't get GC until it finishes running unless the thread throws an unhandled 
Exception or the application is terminated.
 
Matt Hoyt



From: Jan Rychter 
To: clojure@googlegroups.com
Sent: Wednesday, September 28, 2011 3:38 PM
Subject: Are futures garbage-collected?


If I create a future but do not hold on to it anywhere and never dereference 
it, is the thread guaranteed to run until successful completion?

In other words, if I create futures entirely for side effects, should I worry 
about them getting terminated and GCd?

I looked for an answer but could not find anything relevant. Any hints 
appreciated.

thanks,
--J.


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

Are futures garbage-collected?

[Jan Rychter]

If I create a future but do not hold on to it anywhere and never dereference 
it, is the thread guaranteed to run until successful completion?

In other words, if I create futures entirely for side effects, should I 
worry about them getting terminated and GCd?

I looked for an answer but could not find anything relevant. Any hints 
appreciated.

thanks,
--J.

-- 
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: break-on-gaps - just curious if there is a more idiomatic way to do this

[Nathan Sorenson]

If you were feeling so inclined, you could structure this as a lazy sequence 
(like 'partition' does)

(defn lazy-break
  [coll]
  (letfn [(break-paired [pairs]
(lazy-seq
 (when-let [s (seq pairs)]
   (let [p (doall (take-while (fn [[a b]] (= (inc a) b)) pairs))
 cutpoint (count p)]
 (cons (concat p [(nth pairs cutpoint)])
   (break-paired (drop (inc cutpoint) pairs)))]
(map #(map first %) (break-paired (map vector coll (rest coll))

user> (take 2 (lazy-break (concat (range 4) (range 3) (range
((0 1 2 3) (0 1 2))

-- 
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: Shameless self promotion - JavaOne

[Sean Corfield]

The Bay Area Clojure User Group is scheduled to meet on Thursday
October 6th. Any out of town Clojurians who would be around for that
meetup and might be persuaded to come and talk about what they're
doing with Clojure?

http://www.meetup.com/The-Bay-Area-Clojure-User-Group/

Sean

On Tue, Sep 27, 2011 at 8:50 AM, Dennis  wrote:
> I will be giving a talk at JavaOne (it is Clojure related).  Here is
> the information.
>
> Title:          Monitoring a Large-Scale Infrastructure with Clojure
> Time             Tuesday, 07:30 PM, Parc 55 - Embarcadero
> Length          45 Minutes
> Abstract:               Monitoring a large infrastructure brings unique 
> challenges
> that require blending development and operations concepts. This
> session discusses how Dell Inc. used Clojure to develop a
> data-flow-based monitoring system that stores, evaluates, and acts on
> hundreds of thousands of metrics.
>
> It covers
> • Real-world applications of Clojure's parallel programming constructs
> to take advantage of multiple cores available in today's systems
> • Using Clojure's homoiconic nature to create DSLs
> • Taking advantage of Clojure running on the JVM to use the Java ecosystem
> • How DevOps takes advantage of the JVM dynamic languages to develop
> new monitoring tools
> Track           Emerging Languages, Tools, and Techniques
> Optional Track          The Java Frontier

-- 
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: Idiomatically returning one or two values from a function.

[Meikel Brandmeyer]

Hi,

you can return always a vector.

(fn [] [true])
(fn [] [true {:foo 12}])

And then use destructuring on the return value.

(let [[value annotations] (...)]
  (when annotations
..))

Sincerely
Meikel

-- 
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: Idiomatically returning one or two values from a function.

[Daniel Solano Gomez]

On Wed Sep 28 18:52 2011, Daniel Pittman wrote:
> G'day.
> 
> I have problem that I have been thrashing back and forth over the best
> design of for a week now, and I can't work out the nicest way to
> handle it.  Specifically, I have a collection of functions that return
> a primary result, and might also return a secondary "annotation" about
> that result.
> 
> The current implementation is:
> 
> (fn [] true) ; primary only
> (fn [] (annotated-return true {:foo 12})) ; with annotation
> 
> `annotated-return` actually wraps a record, and then the handling code
> can determine if the result is specifically that type, or if it is
> anything else, to select between the two cases.
> 
> In a bunch of other languages I would use a `pair` or `tuple`, but
> Clojure doesn't have a native type that maps closely to that.  Worse,
> though, it doesn't have a native type that isn't a valid return from
> one of these methods.  (Set, Vector, List, and Map are all used. :)
> 
> The alternatively I can think of are limited: I don't like the idea of
> guessing based on a two element vector return or so, since I want this
> to be pretty much impossible to accidentally break.

Why not always return a vector?  That is more or less what a tuple is.

(fn [] [true])   ; primary only
(fn [] [true {:foo 12}]) ; with annotation

That way, your data is always (first x) and your metadata is always
(second x).

If you want to use something more typed-like, you could return a map:

(fn [] {:result true})
(fn [] {:result true :metadata {:foo 12}})

For this approach, you could write helper functions to make the code
less painful to read and write.  If performance is a concern, you can
try a record.

> I considered using meta-data, but that can't attach to a primitive
> value, and those are definitely valid results.
> 
> So, is there a better way to do this?  At this point I am tempted to
> step aside from functional code, and use stateful mutation of some
> sort to maintain the annotations:
> 
> (fn [] (annotate-by-side-effort {:foo 12}) true)
> 
> Daniel
> -- 
> ♲ Made with 100 percent post-consumer electrons
> 
> -- 
> 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


signature.asc
Description: Digital signature

Re: iterate with side-effect function?

[siyu798]

Thanks everyone.

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

Idiomatically returning one or two values from a function.

[Daniel Pittman]

G'day.

I have problem that I have been thrashing back and forth over the best
design of for a week now, and I can't work out the nicest way to
handle it.  Specifically, I have a collection of functions that return
a primary result, and might also return a secondary "annotation" about
that result.

The current implementation is:

(fn [] true) ; primary only
(fn [] (annotated-return true {:foo 12})) ; with annotation

`annotated-return` actually wraps a record, and then the handling code
can determine if the result is specifically that type, or if it is
anything else, to select between the two cases.

In a bunch of other languages I would use a `pair` or `tuple`, but
Clojure doesn't have a native type that maps closely to that.  Worse,
though, it doesn't have a native type that isn't a valid return from
one of these methods.  (Set, Vector, List, and Map are all used. :)

The alternatively I can think of are limited: I don't like the idea of
guessing based on a two element vector return or so, since I want this
to be pretty much impossible to accidentally break.

I considered using meta-data, but that can't attach to a primitive
value, and those are definitely valid results.

So, is there a better way to do this?  At this point I am tempted to
step aside from functional code, and use stateful mutation of some
sort to maintain the annotations:

(fn [] (annotate-by-side-effort {:foo 12}) true)

Daniel
-- 
♲ Made with 100 percent post-consumer electrons

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

[David Nolen]

Change you project layout to something like this:

src/hello/core.cljs

And put the code currently in hello.cljs in core.cljs

Make the other relevant changes to account for this restructuring.

Whenever I encounter issues like the one you're experiencing I try to
compare against the working samples in the repo.

David

On Wed, Sep 28, 2011 at 2:47 PM, Brent Millare wrote:

> Hi David,
>
> I'm not sure what you mean by this.
>
> If I replace hello.greet() with greet(), I get "greet is not defined"
> instead.
>
> On Sep 28, 2:03 pm, David Nolen  wrote:
> > Did you try this wIthout a single element namespace?
> >
> > On Wednesday, September 28, 2011, Brent Millare  >
> > wrote:
> >
> >
> >
> >
> >
> >
> >
> > > No, I get a similar error, but instead of "hello" not being defined,
> > > it says "b" is not defined.
> >
> > > On Sep 28, 12:55 pm, David Nolen  wrote:
> > >> Does it work when you use the advanced compilation settings?
> >
> > >> On Wed, Sep 28, 2011 at 12:35 PM, Brent Millare <
> brent.mill...@gmail.com
> > >wrote:
> >
> > >> > @David Nolen,
> >
> > >> > All the files are there in the script tab.
> >
> > >> > autogen'd file out/F6baq.js:
> > >> > goog.provide('hello');
> > >> > goog.require('cljs.core');
> > >> > hello.greet = (function greet(){
> > >> > return "hello world";
> > >> > });
> > >> > goog.exportSymbol('hello.greet', hello.greet);
> >
> > >> > hello.js:
> > >> > goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
> > >> > 'goog.string.StringBuffer', 'goog.object', 'goog.array']);
> > >> > goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);
> >
> > >> > @David Powell,
> >
> > >> > I added  and I got no effect.
> >
> > >> > --
> > >> > 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
>
> --
> 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: Clojurescript output effect

[Brent Millare]

Hi David,

I'm not sure what you mean by this.

If I replace hello.greet() with greet(), I get "greet is not defined"
instead.

On Sep 28, 2:03 pm, David Nolen  wrote:
> Did you try this wIthout a single element namespace?
>
> On Wednesday, September 28, 2011, Brent Millare 
> wrote:
>
>
>
>
>
>
>
> > No, I get a similar error, but instead of "hello" not being defined,
> > it says "b" is not defined.
>
> > On Sep 28, 12:55 pm, David Nolen  wrote:
> >> Does it work when you use the advanced compilation settings?
>
> >> On Wed, Sep 28, 2011 at 12:35 PM, Brent Millare  >wrote:
>
> >> > @David Nolen,
>
> >> > All the files are there in the script tab.
>
> >> > autogen'd file out/F6baq.js:
> >> > goog.provide('hello');
> >> > goog.require('cljs.core');
> >> > hello.greet = (function greet(){
> >> > return "hello world";
> >> > });
> >> > goog.exportSymbol('hello.greet', hello.greet);
>
> >> > hello.js:
> >> > goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
> >> > 'goog.string.StringBuffer', 'goog.object', 'goog.array']);
> >> > goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);
>
> >> > @David Powell,
>
> >> > I added  and I got no effect.
>
> >> > --
> >> > 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

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

break-on-gaps - just curious if there is a more idiomatic way to do this

[qhfgva]

I've been working on problems from "Programming Challenges" (Skiena)
to learn clojure.  As part of a problem I developed the following
routine.  I sort of scare myself how natural thinking in reduce is
getting, but I was wondering if there is a more clever/idiomatic way
to solve this problem.

(defn break-on-gaps [minutes]
  (reduce (fn [acc x]
(if (empty? acc)
  [[x]]
  (if (= (inc (last (last acc))) x)
(conj (vec (butlast acc))
  (conj (last acc) x))
(conj acc [x]
  []
  minutes))

user=> (break-on-gaps [1 2 3 5 6 7 8 10 20 21])
[[1 2 3] [5 6 7 8] [10] [20 21]]

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

[David Nolen]

Did you try this wIthout a single element namespace?

On Wednesday, September 28, 2011, Brent Millare 
wrote:
> No, I get a similar error, but instead of "hello" not being defined,
> it says "b" is not defined.
>
> On Sep 28, 12:55 pm, David Nolen  wrote:
>> Does it work when you use the advanced compilation settings?
>>
>> On Wed, Sep 28, 2011 at 12:35 PM, Brent Millare wrote:
>>
>>
>>
>>
>>
>>
>>
>> > @David Nolen,
>>
>> > All the files are there in the script tab.
>>
>> > autogen'd file out/F6baq.js:
>> > goog.provide('hello');
>> > goog.require('cljs.core');
>> > hello.greet = (function greet(){
>> > return "hello world";
>> > });
>> > goog.exportSymbol('hello.greet', hello.greet);
>>
>> > hello.js:
>> > goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
>> > 'goog.string.StringBuffer', 'goog.object', 'goog.array']);
>> > goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);
>>
>> > @David Powell,
>>
>> > I added  and I got no effect.
>>
>> > --
>> > 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

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

[Brent Millare]

No, I get a similar error, but instead of "hello" not being defined,
it says "b" is not defined.

On Sep 28, 12:55 pm, David Nolen  wrote:
> Does it work when you use the advanced compilation settings?
>
> On Wed, Sep 28, 2011 at 12:35 PM, Brent Millare 
> wrote:
>
>
>
>
>
>
>
> > @David Nolen,
>
> > All the files are there in the script tab.
>
> > autogen'd file out/F6baq.js:
> > goog.provide('hello');
> > goog.require('cljs.core');
> > hello.greet = (function greet(){
> > return "hello world";
> > });
> > goog.exportSymbol('hello.greet', hello.greet);
>
> > hello.js:
> > goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
> > 'goog.string.StringBuffer', 'goog.object', 'goog.array']);
> > goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);
>
> > @David Powell,
>
> > I added  and I got no effect.
>
> > --
> > 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: Clojurescript output effect

[David Nolen]

Does it work when you use the advanced compilation settings?

On Wed, Sep 28, 2011 at 12:35 PM, Brent Millare wrote:

> @David Nolen,
>
> All the files are there in the script tab.
>
> autogen'd file out/F6baq.js:
> goog.provide('hello');
> goog.require('cljs.core');
> hello.greet = (function greet(){
> return "hello world";
> });
> goog.exportSymbol('hello.greet', hello.greet);
>
> hello.js:
> goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
> 'goog.string.StringBuffer', 'goog.object', 'goog.array']);
> goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);
>
> @David Powell,
>
> I added  and I got no effect.
>
> --
> 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: Clojurescript output effect

[Brent Millare]

@David Nolen,

All the files are there in the script tab.

autogen'd file out/F6baq.js:
goog.provide('hello');
goog.require('cljs.core');
hello.greet = (function greet(){
return "hello world";
});
goog.exportSymbol('hello.greet', hello.greet);

hello.js:
goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string',
'goog.string.StringBuffer', 'goog.object', 'goog.array']);
goog.addDependency("../F6baq.js", ['hello'], ['cljs.core']);

@David Powell,

I added  and I got no effect.

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

[Brent Millare]

Ah, figured it out. First, its important to use the debugging tools in
chrome when working on javascript (Shift+Ctrl+I). This gave me the
error I needed to figure what was going wrong. The problem was I
needed the goog.addDependency line. Now it knows where to find it and
doesn't cause an error.

Best,
Brent

On Sep 27, 8:51 pm, Brent Millare  wrote:
> Also as for compile options, there are none. I initially tried
> advanced, but again got a blank page. So I tried no args, and it made
> the "out" folder. I looked in there and saw the generated js file. I
> looked through that, and edited each line to look like my working js
> code. In the end, translating the require is what seemed to prevent
> the behavior.
>
> -Brent
>
> On Sep 27, 7:26 pm, Brent Millare  wrote:
>
>
>
>
>
>
>
> > You can try out the code I posted, but basically I wanted to create a
> > hello world canvas. Without the require, I get the canvas. With the
> > require, I get a blank white page.
>
> > There isn't any error message, which is what made this particularly
> > difficult to narrow.
>
> > -Brent
>
> > On Sep 27, 7:01 pm, David Nolen  wrote:
>
> > > What was the error and what were your compile options?
>
> > > On Tuesday, September 27, 2011, Brent Millare 
> > > wrote:
>
> > > > I'm trying to figure out why when I require('cljs.core') in a
> > > > javascript file, the hello world example doesn't work.
>
> > > > hello.js
> > > > goog.require('cljs.core');               ;;<--- If I delete this line,
> > > > then everything works.
> > > > goog.require('goog.dom');
>
> > > > function sayHi() {
> > > >    var myc__2284 = goog.dom.createDom("canvas",
> > > > {"width":"300","height":"225","style":"border:1px dotted"});
> > > >    var context__2285 = myc__2284.getContext("2d");
> > > >    context__2285.font = "bold 12px sans-serif";
> > > >    context__2285.fillText("hello wurld",50,50);
> > > >    return goog.dom.appendChild(document.body,myc__2284);
> > > > };
>
> > > > index.html
> > > > 
> > > > 
> > > >  
> > > >    
> > > >    
> > > >  
> > > >  
> > > >  
> > > > 
>
> > > > I was trying to cut away at what clojurescript outputs since I was
> > > > trying to rule out what line was breaking the code. And oddly enough,
> > > > it was the require line. What's going on here?
>
> > > > --
> > > > 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: iterate with side-effect function?

[Meikel Brandmeyer (kotarak)]

Hi,

there is ye olde loop/recur, which handles side effects (and this case in 
particular) quite nicely. The only advantage of iterate is that the sequence 
of intermediate values is available to an outside observer. However, as 
stated before: mixing lazy sequences with side effects is asking for 
trouble.

Sincerely
Meikel

-- 
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: iterate with side-effect function?

[siyu798]

Odyssomay,
  While does not work in this case as ctx will be "updated" on each 
iteration and fed to the next iteration.

Thanks,
siyu

-- 
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: True diff on any Clojure struct

[Baishampayan Ghose]

On Wed, Sep 28, 2011 at 7:29 PM, Michael Jaaka
 wrote:
> Do you know any lib for making diff from nested structures?
> (diff [ 1 2 3 { 2 3 4 [ 1 2 { 1 2 3 4} ] } #{ 4 5 } ]  [ 1 3 { 2 3 4 [ 1 4 {
> 2 2 3 5} ] } #{ 4 5 } ] )
> -> [ 2 { [ 2 { 1 2 3 4 } ] } ]
> as you can see it behaves like clojure.set/difference
> and better if you would point the keys in map to keep remaining
> (diff [ 1 2 3 { 2 3 4 [ 1 2 { 1 2 3 4 :tag "me"  } ] } #{ 4 5 } ]  [ 1 3 { 2
> 3 4 [ 1 4 { 2 2 3 5  :tag "me" } ] } #{ 4 5 } ]  :keep [ :tag ] )
> -> [ 2 { [ 2 { 1 2 3 4  :tag "me" } ] } ]
> This tool would allow to compare XML documents in form got from reading them
> by clojure.xml lib.

Clojure now has clojure.data/diff to accomplish this task -
https://github.com/clojure/clojure/blob/master/src/clj/clojure/data.clj

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.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

True diff on any Clojure struct

[Michael Jaaka]

Do you know any lib for making diff from nested structures?

(diff [ 1 2 3 { 2 3 4 [ 1 2 { 1 2 3 4} ] } #{ 4 5 } ]  [ 1 3 { 2 3 4 [ 1 4 { 
2 2 3 5} ] } #{ 4 5 } ] )

-> [ 2 { [ 2 { 1 2 3 4 } ] } ]

as you can see it behaves like clojure.set/difference 

and better if you would point the keys in map to keep remaining

(diff [ 1 2 3 { 2 3 4 [ 1 2 { 1 2 3 4 :tag "me"  } ] } #{ 4 5 } ]  [ 1 3 { 2 
3 4 [ 1 4 { 2 2 3 5  :tag "me" } ] } #{ 4 5 } ]  :keep [ :tag ] )

-> [ 2 { [ 2 { 1 2 3 4  :tag "me" } ] } ]

This tool would allow to compare XML documents in form got from reading them 
by clojure.xml lib.

-- 
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: statistics library?

[Daniel]

Depending on the project (and I don't know if it's still supported in
1.3), you ought to be able to leverage Mathematica Player with
Clojuratica for more powerful operations.

On Sep 27, 6:43 pm, Lee Spector  wrote:
> On Sep 27, 2011, at 5:44 PM, David Powell wrote:
>
> > I see that there was a recent fix made to Incanter:
>
> > Fixed typo in :lower-tail? keyword.
> > This was causing the complement of the p-value to be returned.
>
> >https://github.com/liebke/incanter/pull/39
>
> > Have you tried the latest version in git?  Does this fix the problem?
>
> Hmm. I had asked about the version on the Incanter list too. I now see that I 
> was using a *newer* version than the newest one 
> athttps://github.com/liebke/incanter.
>
> I grabbed what appeared to be the newest on clojars, which is [incanter 
> "1.2.3"], while the newest download on that github project page appears to be 
> 1.2.2 from April 20, 2010.
>
> It does sound like the comment that you quoted might indeed be about the bug 
> that I ran into, so maybe it's fixed in some version of Incanter somewhere... 
> But for my current purposes I have more faith in 
> [org.apache.commons/commons-math "2.0"].
>
> Thanks,
>
>  -Lee

-- 
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: suggestion for clojure development

[Islon Scherer]

I agree with Nicolas, clojure should, at this point, focus on improving the 
language instead of maintain compatibility, and as most features of other 
languages can be implemented as macros I think clojure is ahead of the 
competition.

-- 
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: suggestion for clojure development

[Nicolas]

On Sep 28, 1:30 pm, Gary Poster  wrote:
> On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote:
>
> Perhaps Java has been different, but the languages I use and follow have not, 
> with the exception of JavaScript.  I perceive it to be a mildly unfortunate 
> fact of life at this point.
>
> Gary

Java is backward compatible. You know that by default you can run old
legacy code on lastest JVM without problem.

This is one of the reason JAVA is so successfull in enterprise world,
you can take code from year 2000, run it on latest VM, and the only
change is that this code will run dramatically faster.

Clojure itself really benefit from java popularity and stability.
Imagine if clojure couldn't run JVM7 without a significant effort to
update clojure compiler !

This is also a reason why JAVA has difficulties to have latest and
greatest features and to inovate... Java fail to really improve.

I think that clojure/core team is doing its best to ensure backward
compatibility and break it only when there are prevalent reasons to do
it.

-- 
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: A question about arity and function performance

[David Nolen]

Specific arities means dispatch on arity can happen at the full speed of the
host w/o incurring the overhead of variable arity support. This issue
applies to ClojureScript as well where functions are not backed by classes.

David

On Wed, Sep 28, 2011 at 8:55 AM, Christian Romney  wrote:

> I was reading the implementation of juxt and noticed it is defined
> with 4 arities:
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2296
>
> Am I right to infer this is for performance reasons?
> Where can I read more about the performance implications of arity and
> this sort of optimization?
>
> TIA.
>
> --
> 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

A question about arity and function performance

[Christian Romney]

I was reading the implementation of juxt and noticed it is defined
with 4 arities:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2296

Am I right to infer this is for performance reasons?
Where can I read more about the performance implications of arity and
this sort of optimization?

TIA.

-- 
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: suggestion for clojure development

[Baishampayan Ghose]

On Wed, Sep 28, 2011 at 5:00 PM, Gary Poster  wrote:
> Perhaps Java has been different, but the languages I use and follow have not, 
> with the exception of JavaScript.  I perceive it to be a mildly unfortunate 
> fact of life at this point.

JavaScript's case might seem different because people are always
programming to the Lowest Common Denominator of JS features across all
Browsers. ES5 was released in 2009, but I doubt if programmers even
today can use/rely on the new features (eg. strict mode, JSON, etc.).

The bottomline with JS is that almost none is using JavaScript
directly, it's almost always through some library which abstracts out
the incompatibilities.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.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: suggestion for clojure development

[Gary Poster]

On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote:

> On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
>  wrote:
>> You may think
>> I'm doing it wrong, but I don't think I'm alone at all.
> 
> I don't think you're doing anything wrong - and I'm sure many people
> only do minimal research on tools they use. I just think your
> expectations of Clojure the language are unrealistic, in terms of
> maintaining total compatibility with the myriad third party (and
> sometimes unmaintained) libraries.
> 
> For comparison, Scala went thru a lot of binary compatibility issues
> in the transition from 2.7 to 2.8, to the point that even milestone
> builds were not always compatible with each other. This meant the
> entire tool chain had to be rebuilt on almost every milestone build.
> Apparently there were a few similar bumps on the transition to 2.9 (I
> don't know for sure: I lived thru the 2.7 to 2.8 debacle and chose not
> to go to 2.9).
> 
> I hear similar stories for other fast-evolving languages. I think it's
> just a fact of life with "new" technologies - and we pay that price
> for being early adopters.

FWIW, similarly, despite an intent of backwards compatibility, Python has had 
migration costs and small backward compatibility niggles for every single major 
release (2.2 -> 2.3, 2.3 -> 2.4, and so on) ever since I've been involved with 
it, which is...I dunno, more than 10 years now?  My current project doesn't use 
2.7 yet because the cost/benefit hasn't been there yet.  And, of course, the 
switch to Python 3 intentionally broke backwards compatibility.

Every major project I've been involved with had to set aside some 
not-insignificant amount of time to migrate our own code base, determine what 
to do with dependencies, and even help migrating some of the dependencies.  

We have said exactly the same sorts of things that Arthur is saying. :-)  And 
then replied to ourselves with the same sorts of things that Sean is saying.

Perhaps Java has been different, but the languages I use and follow have not, 
with the exception of JavaScript.  I perceive it to be a mildly unfortunate 
fact of life at this point.

Gary

-- 
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: Does macros evaluates its arguments before?

[ru]

On 28 сен, 13:13, Michał Marczyk  wrote:
> You know, in many Lisps let is a macro too. In Clojure it expands to
> the special form let* (an implementation detail); a Scheme
> implementation might implement it as ((lambda (binding-symbol ...)
> expr . exprs) binding-val ...).
>
> Now, would you expect the following to return (inc x) -- a list of two
> symbols -- or 2?
>
> (let [x 1]
>   (inc x))
>
> There's no promise arguments passed to macros will *never* be
> evaluated, that would make no sense at all. They're just not being
> evaluated at compile time.

Only Baishampayan explained me at last that evaluation done under MY
control :)

>
> Sincerely,
> Michał

-- 
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: Does macros evaluates its arguments before?

[Baishampayan Ghose]

2011/9/28 ru :
> Thank you very much!
> Your explanation is best. At last I understand my gap in understanding
> of the situation.

Extremely happy to to have helped you, Ru. Please don't hesitate to
email us if you have more questions.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.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: Does macros evaluates its arguments before?

[ru]

Baishampayan!

Thank you very much!
Your explanation is best. At last I understand my gap in understanding
of the situation.

Sincerely,
  Ru

On 28 сен, 13:06, Baishampayan Ghose  wrote:
> On Wed, Sep 28, 2011 at 2:27 PM, ru  wrote:
> > The documentation says that the macro function is called with the
> > arguments unevaluated. So I write code for that function on that
> > assumption. And when I run this code the arguments being evaluated. It
> > does not matter why or how and when! They mustn't evaluated never in
> > that case in accordance with the documentation! That is the question!
> > Because the unevaluated arguments is an important feature that allows
> > you to expand the language using macros.
>
> Let's put it this way - you misunderstood the documentation. What the
> documentation says is correct and defmacro behaves as advertised. The
> arguments are _never_ evaluated when they are _passed_ to the macro,
> but that doesn't mean they can never be evaluated inside the macro no
> matter what you do.
>
> In case of macros, the developer is (that is, you are) in charge of
> _when_ do evaluate the arguments; and you did that when you typed in
> ~e inside the `let` binding. It was your choice and none can do
> anything about it.
>
> Regards,
> BG
>
> --
> Baishampayan Ghose
> b.ghose at gmail.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: Does macros evaluates its arguments before?

[Michał Marczyk]

You know, in many Lisps let is a macro too. In Clojure it expands to
the special form let* (an implementation detail); a Scheme
implementation might implement it as ((lambda (binding-symbol ...)
expr . exprs) binding-val ...).

Now, would you expect the following to return (inc x) -- a list of two
symbols -- or 2?

(let [x 1]
  (inc x))

There's no promise arguments passed to macros will *never* be
evaluated, that would make no sense at all. They're just not being
evaluated at compile time.

Sincerely,
Michał

-- 
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: Does macros evaluates its arguments before?

[Baishampayan Ghose]

On Wed, Sep 28, 2011 at 2:39 PM, ru  wrote:
> If the macro arguments are evaluated, the macro does not need to
> expand the language. All you can do with functions:
>
> (eval-some-code '(.. some code here ..))
>
> Even VisualBasic can do this: eval_some_code ".. some code here .."

Try writing an `or` and `if` statement in Visual Basic / your
favourite language and share it with us :-)

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.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: Does macros evaluates its arguments before?

[ru]

If the macro arguments are evaluated, the macro does not need to
expand the language. All you can do with functions:

(eval-some-code '(.. some code here ..))

Even VisualBasic can do this: eval_some_code ".. some code here .."

On 28 сен, 12:57, ru  wrote:
> Dear Michal,
>
> You and others explain me how Clojure (or Common Lisp) handles my
> code. Very detailed and thoroughly. I want to draw attention to
> another point:
> The documentation says that the macro function is called with the
> arguments unevaluated. So I write code for that function on that
> assumption. And when I run this code the arguments being evaluated. It
> does not matter why or how and when! They mustn't evaluated never in
> that case in accordance with the documentation! That is the question!
> Because the unevaluated arguments is an important feature that allows
> you to expand the language using macros.
>
> On 28 сен, 00:35, Michał Marczyk  wrote:
>
>
>
>
>
>
>
> > Hi Ru,
>
> > let's input your macro definition at the REPL:
>
> > user> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> > #'user/infix
>
> > So far so good. Now let's try use it in a function:
>
> > user> (defn foo [] (infix (5 + 4)))
> > #'user/foo
>
> > Well now -- it compiled! So, there's no exception being thrown when
> > the macro is expanded at compile time; otherwise foo would not have
> > compiled.
>
> > How about calling foo?
>
> > user> (foo)
> > ; Evaluation aborted.
> > user> *e
> > # > cannot be cast to clojure.lang.IFn>
>
> > There's your exception: at runtime. By this time there is no trace of
> > your macro in the running code (you could undefine it -- by saying
> > (ns-unmap 'user 'infix) -- and this would have no effect on foo).
>
> > Once again: (5 + 4) *is not evaluated when the macro is expanded*. It
> > is only evaluated at runtime -- and only then does it explode, as
> > expected. The key point is that a macro is just a function called upon
> > by the compiler to transform your program prior to it being compiled
> > into JVM bytecode (in the case of Clojure, or perhaps native code in
> > the case of some Common Lisp implementations and execution by the
> > interpreter in interpreted Lisps); if it generates erroneous code
> > (like this version of infix!), that erroneous code will be compiled by
> > the compiler and eventually explode when you run it -- an unpleasant
> > occurrence completely distinct from a macro-expansion-time exception.
>
> > Sincerely,
> > Michał

-- 
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: Does macros evaluates its arguments before?

[Baishampayan Ghose]

On Wed, Sep 28, 2011 at 2:27 PM, ru  wrote:
> The documentation says that the macro function is called with the
> arguments unevaluated. So I write code for that function on that
> assumption. And when I run this code the arguments being evaluated. It
> does not matter why or how and when! They mustn't evaluated never in
> that case in accordance with the documentation! That is the question!
> Because the unevaluated arguments is an important feature that allows
> you to expand the language using macros.

Let's put it this way - you misunderstood the documentation. What the
documentation says is correct and defmacro behaves as advertised. The
arguments are _never_ evaluated when they are _passed_ to the macro,
but that doesn't mean they can never be evaluated inside the macro no
matter what you do.

In case of macros, the developer is (that is, you are) in charge of
_when_ do evaluate the arguments; and you did that when you typed in
~e inside the `let` binding. It was your choice and none can do
anything about it.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.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: iterate with side-effect function?

[Jonathan Fischer Friberg]

How about while?

(while not-finished
  (do stuff ...))

On Wed, Sep 28, 2011 at 4:23 AM, Nathan Sorenson  wrote:

> Quite often I convince myself I need state or some effectful trigger, but
> further thought reveals a simpler stateless approach.
>
> That being said--if you absolutely need to be doing something based on
> effects, something that absolutely can't be tracked via values in a purely
> functional way--like polling a queue once per second (functional-reactive
> programming notwithstanding), I personally prefer straight loop/recur to the
> list processing functions. In my mind, usings seq/filter/map suggests you
> are doing something lazy, referentially transparent, and composable. If you
> are not doing that, a loop recur signals to me you are manipulating the
> execution flow in a precise way.
>
> But again, I always try to find a way to avoid dealing with the messy
> stateful world until the last possible moment. Lots of application logic can
> be completely pure with one small "write to file"-type operation at the end.
>
>  --
> 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: Does macros evaluates its arguments before?

[ru]

Dear Michal,

You and others explain me how Clojure (or Common Lisp) handles my
code. Very detailed and thoroughly. I want to draw attention to
another point:
The documentation says that the macro function is called with the
arguments unevaluated. So I write code for that function on that
assumption. And when I run this code the arguments being evaluated. It
does not matter why or how and when! They mustn't evaluated never in
that case in accordance with the documentation! That is the question!
Because the unevaluated arguments is an important feature that allows
you to expand the language using macros.

On 28 сен, 00:35, Michał Marczyk  wrote:
> Hi Ru,
>
> let's input your macro definition at the REPL:
>
> user> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> #'user/infix
>
> So far so good. Now let's try use it in a function:
>
> user> (defn foo [] (infix (5 + 4)))
> #'user/foo
>
> Well now -- it compiled! So, there's no exception being thrown when
> the macro is expanded at compile time; otherwise foo would not have
> compiled.
>
> How about calling foo?
>
> user> (foo)
> ; Evaluation aborted.
> user> *e
> # cannot be cast to clojure.lang.IFn>
>
> There's your exception: at runtime. By this time there is no trace of
> your macro in the running code (you could undefine it -- by saying
> (ns-unmap 'user 'infix) -- and this would have no effect on foo).
>
> Once again: (5 + 4) *is not evaluated when the macro is expanded*. It
> is only evaluated at runtime -- and only then does it explode, as
> expected. The key point is that a macro is just a function called upon
> by the compiler to transform your program prior to it being compiled
> into JVM bytecode (in the case of Clojure, or perhaps native code in
> the case of some Common Lisp implementations and execution by the
> interpreter in interpreted Lisps); if it generates erroneous code
> (like this version of infix!), that erroneous code will be compiled by
> the compiler and eventually explode when you run it -- an unpleasant
> occurrence completely distinct from a macro-expansion-time exception.
>
> Sincerely,
> Michał

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