Re: [ANN] ClojureScript release 0.0-1535 with G.Closure 0.0-2029

[Evan Mezeske]

> That said what's the compelling reason these days for lein-cljsbuild to 
> depend on a specific version of ClojureScript? Are you relying on certain 
> aspects of the analyzer or compiler's API and find that they change quite 
> frequently?


I guess the (debatably compelling) reason for that these days is just that 
I like the idea of providing a sensible default.  AFAIK, you can always 
override the version by adding it you a project's :dependencies if you want 
to (I'd test this but am in the middle of moving atm, without access to my 
stuff).

Besides just having a sensible default, I also like to "endorse" a 
particular version of the compiler for a particular version of 
lein-cljsbuild.  Before any release, I do a few rounds of testing with the 
example projects and some of my personal stuff, and confirm that things 
seem to work.

Now, if I'm wrong, and you can't just stick a different version of 
clojurescript in :dependencies and have it work, then I'd consider that a 
bug.

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

Re: Change the CCW compile output catalog

[Laurent PETIT]

2012/12/1 Laurent PETIT :
> Hello,
>
> 2012/12/1 Vladimir Tsichevski :
>> Hi,
>>
>> CCW always outputs compiled classes into the "classes" catalog. AFAIK, this
>> name is compiled into CCW and hence cannot be changed. My two questions are:
>>
>> 1. Why the catalog path is not configurable? Was this made intentionally?
>
> It is a limitation, for sure, which comes from the past. Will
> eventually go. There's not reason for it to not be configurable, but
> no having dedicated time to do so.
>
>> 2. Why this catalog differs from the Java output catalog? Was it made
>> intentionally, or it is Ok to put all project output classes to same
>> catalog?
>
> Yes, it is intentional that CCW's output is not in the same folder
> hierarchy as other Java output.
> Indeed, it's not possible (or sufficiently complex to have been
> considered so) to inform Eclipse (which manages java source/classes
> via the JDT - Java Development Tools-) that there are contents in the
> same output as where it compiles classes, and that it would be polite
> not to erase the folder content as if it were under its full control.
>
> Now, beyond your interesting in understand why things are how they
> are, I'd be interesting in knowing if that's currently getting in your
> way, and if so, try to see  if I can help you find a workaround until
> this is eventually customizable.

Wow, re-reading myself right now. Either I was drunk, or the
spellchecker cheated on me a lot :-)

>
>
> HTH,
>
> --
> Laurent

-- 
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: Change the CCW compile output catalog

[Vladimir Tsichevski]

On Sunday, December 2, 2012 2:11:48 AM UTC+4, Vladimir Tsichevski wrote:
>
>
> Hi Laurent,
>
> many thanks for the quick and helpful response!
>
> Now that I've managed to make CCW compile my clojure code to classes I'm 
> wondering how to tell Eclipse to package these classes to an RCP plugin 
> along with classes produced from Java.
>
Just found the answer. Please, ignore my question. 

>
> Regards,
> Vladimir
>
> On Sunday, December 2, 2012 1:04:06 AM UTC+4, lpetit wrote:
>>
>> Hello, 
>>
>> 2012/12/1 Vladimir Tsichevski : 
>> > Hi, 
>> > 
>> > CCW always outputs compiled classes into the "classes" catalog. AFAIK, 
>> this 
>> > name is compiled into CCW and hence cannot be changed. My two questions 
>> are: 
>> > 
>> > 1. Why the catalog path is not configurable? Was this made 
>> intentionally? 
>>
>> It is a limitation, for sure, which comes from the past. Will 
>> eventually go. There's not reason for it to not be configurable, but 
>> no having dedicated time to do so. 
>>
>> > 2. Why this catalog differs from the Java output catalog? Was it made 
>> > intentionally, or it is Ok to put all project output classes to same 
>> > catalog? 
>>
>> Yes, it is intentional that CCW's output is not in the same folder 
>> hierarchy as other Java output. 
>> Indeed, it's not possible (or sufficiently complex to have been 
>> considered so) to inform Eclipse (which manages java source/classes 
>> via the JDT - Java Development Tools-) that there are contents in the 
>> same output as where it compiles classes, and that it would be polite 
>> not to erase the folder content as if it were under its full control. 
>>
>> Now, beyond your interesting in understand why things are how they 
>> are, I'd be interesting in knowing if that's currently getting in your 
>> way, and if so, try to see  if I can help you find a workaround until 
>> this is eventually customizable. 
>>
>>
>> HTH, 
>>
>> -- 
>> Laurent 
>>
>

-- 
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: Change the CCW compile output catalog

[Vladimir Tsichevski]

Hi Laurent,

many thanks for the quick and helpful response!

Now that I've managed to make CCW compile my clojure code to classes I'm 
wondering how to tell Eclipse to package these classes to an RCP plugin 
along with classes produced from Java.

Regards,
Vladimir

On Sunday, December 2, 2012 1:04:06 AM UTC+4, lpetit wrote:
>
> Hello, 
>
> 2012/12/1 Vladimir Tsichevski >: 
> > Hi, 
> > 
> > CCW always outputs compiled classes into the "classes" catalog. AFAIK, 
> this 
> > name is compiled into CCW and hence cannot be changed. My two questions 
> are: 
> > 
> > 1. Why the catalog path is not configurable? Was this made 
> intentionally? 
>
> It is a limitation, for sure, which comes from the past. Will 
> eventually go. There's not reason for it to not be configurable, but 
> no having dedicated time to do so. 
>
> > 2. Why this catalog differs from the Java output catalog? Was it made 
> > intentionally, or it is Ok to put all project output classes to same 
> > catalog? 
>
> Yes, it is intentional that CCW's output is not in the same folder 
> hierarchy as other Java output. 
> Indeed, it's not possible (or sufficiently complex to have been 
> considered so) to inform Eclipse (which manages java source/classes 
> via the JDT - Java Development Tools-) that there are contents in the 
> same output as where it compiles classes, and that it would be polite 
> not to erase the folder content as if it were under its full control. 
>
> Now, beyond your interesting in understand why things are how they 
> are, I'd be interesting in knowing if that's currently getting in your 
> way, and if so, try to see  if I can help you find a workaround until 
> this is eventually customizable. 
>
>
> HTH, 
>
> -- 
> Laurent 
>

-- 
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: First test with JavaFx and blocked yet :(

[Kevin Downey]

if you read the docs on the java command -cp and -jar are mutually
exclusive options


On Sat, Dec 1, 2012 at 1:19 AM, Christian Sperandio <
christian.speran...@gmail.com> wrote:

> Thanks :)
> I got my error. Because I declared my code as a class, my mind turned into
> a object logic and I forget I was always in Clojure and in functional mind.
>
> I'd like understand an another point too. When I generate a jar with lein
> uberjar, the code works. But if I do only a lein jar, the running failed
> with a NoClassDef exception. Even if when I run the jar I use the java
> command's option -cp to give the jfxrt.java's place.
> Do I forget something?
>
>
> Chris
>
> Le 1 déc. 2012 à 01:14, Kevin Downey  a écrit :
>
> here is an example https://gist.github.com/4179694
>
>
> On Fri, Nov 30, 2012 at 4:13 PM, Kevin Downey  wrote:
>
>> javafx.application.Application/launch is looking at the class that the
>> method that calls it belongs to, in this case it belongs to the IFn class
>> generated for the -main function, there is an arity for launch that takes
>> the class you want to use instead of the weird detection thing
>>
>>
>>
>>
>>
>> On Fri, Nov 30, 2012 at 3:38 PM, Christian Sperandio <
>> christian.speran...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm testing JavaFX with Clojure 1.4 and I've got some issues.
>>> I wrote this code:
>>> (ns test-javafx2-clj.core
>>>   (:import javafx.application.Application
>>>javafx.stage.Stage
>>>(javafx.scene Parent Scene))
>>>
>>>   (:gen-class
>>>:extends javafx.application.Application))
>>>
>>> (defn -main
>>>   "I don't do a whole lot ... yet."
>>>   [& args]
>>>   (println "Before the launch call")
>>>   (javafx.application.Application/launch args))
>>>
>>> (defn -start
>>>   [this stage]
>>>   (println "Arf!"))
>>>   ;(.setTitle stage "Hello World!"))
>>>
>>> My project.clj is the following:
>>> (ns test-javafx2-clj.core
>>>   (:import javafx.application.Application
>>>javafx.stage.Stage
>>>(javafx.scene Parent Scene))
>>>
>>>   (:gen-class
>>>:extends javafx.application.Application))
>>>
>>> (defn -main
>>>   "I don't do a whole lot ... yet."
>>>   [& args]
>>>   (println "Before the launch call")
>>>   (javafx.application.Application/launch args))
>>>
>>> (defn -start
>>>   [this stage]
>>>   (println "Arf!"))
>>>   ;(.setTitle stage "Hello World!"))
>>>
>>>
>>> I build my jar with the command lein uberjar, and when I launch the
>>> generated jar I get this error:
>>> Exception in thread "main" java.lang.RuntimeException: Error: class
>>> test_javafx2_clj.core$_main is not a subclass of
>>> javafx.application.Application
>>>  at javafx.application.Application.launch(Application.java:211)
>>> at test_javafx2_clj.core$_main.doInvoke(core.clj:14)
>>>  at clojure.lang.RestFn.invoke(RestFn.java:397)
>>> at clojure.lang.AFn.applyToHelper(AFn.java:159)
>>> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>>>  at test_javafx2_clj.core.main(Unknown Source)
>>>
>>> It's very strange because I well wrote the
>>> :extends  javafx.application.Application. So, I don't understand why I've
>>> got this error.
>>>
>>> Thanks for your help.
>>>
>>> Chris
>>>
>>> --
>>> 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?
>>
>
>
>
> --
> 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
>
>  --
> 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.c

Re: Change the CCW compile output catalog

[Laurent PETIT]

Hello,

2012/12/1 Vladimir Tsichevski :
> Hi,
>
> CCW always outputs compiled classes into the "classes" catalog. AFAIK, this
> name is compiled into CCW and hence cannot be changed. My two questions are:
>
> 1. Why the catalog path is not configurable? Was this made intentionally?

It is a limitation, for sure, which comes from the past. Will
eventually go. There's not reason for it to not be configurable, but
no having dedicated time to do so.

> 2. Why this catalog differs from the Java output catalog? Was it made
> intentionally, or it is Ok to put all project output classes to same
> catalog?

Yes, it is intentional that CCW's output is not in the same folder
hierarchy as other Java output.
Indeed, it's not possible (or sufficiently complex to have been
considered so) to inform Eclipse (which manages java source/classes
via the JDT - Java Development Tools-) that there are contents in the
same output as where it compiles classes, and that it would be polite
not to erase the folder content as if it were under its full control.

Now, beyond your interesting in understand why things are how they
are, I'd be interesting in knowing if that's currently getting in your
way, and if so, try to see  if I can help you find a workaround until
this is eventually customizable.


HTH,

-- 
Laurent

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

Change the CCW compile output catalog

[Vladimir Tsichevski]

Hi,

CCW always outputs compiled classes into the "classes" catalog. AFAIK, this 
name is compiled into CCW and hence cannot be changed. My two questions are:

1. Why the catalog path is not configurable? Was this made intentionally?
2. Why this catalog differs from the Java output catalog? Was it made 
intentionally, or it is Ok to put all project output classes to same 
catalog?

Regards,
Vladimir

-- 
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: JavaFX2, problem with overriden constructor

[Christian Sperandio]

I feel shame.
I didn't think try this solution.

Thanks.


2012/12/1 Sean Corfield 

> On Sat, Dec 1, 2012 at 11:58 AM, Christian Sperandio <
> christian.speran...@gmail.com> wrote:
>
>> When I try to use the following constructor 
>> *Scene
>> *(Parent  root,
>> double width, double height, 
>> Paint
>>  fill)
>> ...
>> I call the constructor like this:  scene (Scene. root 500 250 Color/BLACK)
>> I don't have any error if I do:
>> (let [ scene (Scene. root 500 250)]
>>   (.setFill scene Color/BLACK))
>>
>
> Try: (Scene. root 500.0 250.0 Color/BLACK)
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.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
>

-- 
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: JavaFX2, problem with overriden constructor

[Sean Corfield]

On Sat, Dec 1, 2012 at 11:58 AM, Christian Sperandio <
christian.speran...@gmail.com> wrote:

> When I try to use the following constructor 
> *Scene
> *(Parent  root,
> double width, double height, 
> Paint
>  fill)
> ...
> I call the constructor like this:  scene (Scene. root 500 250 Color/BLACK)
> I don't have any error if I do:
> (let [ scene (Scene. root 500 250)]
>   (.setFill scene Color/BLACK))
>

Try: (Scene. root 500.0 250.0 Color/BLACK)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.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: Proposed change to let-> syntax

[Alex Baranosky]

Nevermind that.  The answer is that as-> would "reduce arg order and
destructuring expectations".  Makes sense.  So for whatever small amount it
is worth I officially have been convinced of all the new names.

On Sat, Dec 1, 2012 at 12:08 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> The more I watch this conversation, the more I like some-> and cond->.
>  What was the motivation for changing let-> to as-> ? let-> made a lot of
> sense as a name to me.
>
>
> On Sat, Dec 1, 2012 at 6:48 AM, Rich Hickey  wrote:
>
>> I'll argue that if 'e' in conde is enough to imply 'each' then '->' in
>> cond-> is enough to imply it keeps threading.
>>
>> I think many people have ideas about -> operators born of some of these
>> libraries that supply a wealth of 'things you can use in ->'.  Most of
>> their operators have '->' in their names, but don't fundamentally thread -
>> e.g. they are terminators or one shots like if-> (or ->if).
>>
>> A op-> operator, IMO, should take an open set of expressions and thread
>> the return values through them in some way. Otherwise it shouldn't be an
>> op->.
>>
>> When one reads -> as 'thread' vs 'for use in threading', things might
>> become clearer.
>>
>>
>> On Dec 1, 2012, at 9:31 AM, Steve Miner wrote:
>>
>> > gate-> would work.  Like guard-> it doesn't have any connotations in
>> the Clojure world, but it's learnable.  I'll add one more: qual-> ... short
>> for "qualified threading macro".  Each clause is qualified by a test
>> condition.
>> >
>> > Of course, there's always conde-> to borrow from miniKanren and
>> core.logic.  The "e" stands for "every" because multiple clauses can
>> succeed as opposed to the short-circuiting cond.
>> >
>> >
>> > On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:
>> >
>> >>
>> >> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
>> >>
>> >>> I propose guard-> to avoid the cond-> confusion.
>> >>>
>> >>
>> >> Yeah, that came up. Guards in other langs are short circuiting, just
>> like cond.
>> >>
>> >> Another in that camp was gate->
>> >
>> > --
>> > 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: Proposed change to let-> syntax

[Alex Baranosky]

The more I watch this conversation, the more I like some-> and cond->.
 What was the motivation for changing let-> to as-> ? let-> made a lot of
sense as a name to me.

On Sat, Dec 1, 2012 at 6:48 AM, Rich Hickey  wrote:

> I'll argue that if 'e' in conde is enough to imply 'each' then '->' in
> cond-> is enough to imply it keeps threading.
>
> I think many people have ideas about -> operators born of some of these
> libraries that supply a wealth of 'things you can use in ->'.  Most of
> their operators have '->' in their names, but don't fundamentally thread -
> e.g. they are terminators or one shots like if-> (or ->if).
>
> A op-> operator, IMO, should take an open set of expressions and thread
> the return values through them in some way. Otherwise it shouldn't be an
> op->.
>
> When one reads -> as 'thread' vs 'for use in threading', things might
> become clearer.
>
>
> On Dec 1, 2012, at 9:31 AM, Steve Miner wrote:
>
> > gate-> would work.  Like guard-> it doesn't have any connotations in the
> Clojure world, but it's learnable.  I'll add one more: qual-> ... short for
> "qualified threading macro".  Each clause is qualified by a test condition.
> >
> > Of course, there's always conde-> to borrow from miniKanren and
> core.logic.  The "e" stands for "every" because multiple clauses can
> succeed as opposed to the short-circuiting cond.
> >
> >
> > On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:
> >
> >>
> >> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
> >>
> >>> I propose guard-> to avoid the cond-> confusion.
> >>>
> >>
> >> Yeah, that came up. Guards in other langs are short circuiting, just
> like cond.
> >>
> >> Another in that camp was gate->
> >
> > --
> > 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

JavaFX2, problem with overriden constructor

[Christian Sperandio]

Hi,

I continue learning JafaFX with Clojure and I've got an issue with the 
Scene constructor.
When I try to use the following constructor 
*Scene*(Parent
 root, 
double width, double height, 
Paint
 fill)
I get an error when launching:
Exception in Application start method
Exception in thread "main" java.lang.RuntimeException: Exception in 
Application start method
at 
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:403)
at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:47)
at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:115)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalArgumentException: No matching ctor found for 
class javafx.scene.Scene
at clojure.lang.Reflector.invokeConstructor(Reflector.java:183)
at testjavafx2clj.core$newScene.invoke(core.clj:21)
at testjavafx2clj.core$_start.invoke(core.clj:36)
at testjavafx2clj.core.start(Unknown Source)
at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:319)
at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:206)
at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:76)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at com.sun.glass.ui.gtk.GtkApplication$3$1.run(GtkApplication.java:82)


I call the constructor like this:  scene (Scene. root 500 250 Color/BLACK)
I don't have any error if I do:
(let [ scene (Scene. root 500 250)]
  (.setFill scene Color/BLACK))

I think the problem comes from the Scene's constructor has 2 constructors 
with the same arity. I try to solve that using hints (like  scene (Scene. 
root 500 250 #^javafx.scene.paint.Color Color/BLACK) but it doesn't work 
too.
Does it exist a solution? Or, must I use the 2 args constructor with 
setFill method call?

Thanks.


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

Re: Proposed change to let-> syntax

[Sean Corfield]

On Sat, Dec 1, 2012 at 6:33 AM, Rich Hickey  wrote:

> > Given that some-> threads while non-nil but the fn some stops with the
> first logical true value, this seems counter-intuitive to me. when-> seems
> better here, or while-> perhaps? What other names were considered?
> when and while also use logical truth. We don't have anything where the
> basis is non-nil. Thus my extended description of how some* could come to
> occupy that role.
>

Ah, OK, so the change in semantics is specifically to allow threading of
true/false (as well as other non-nil values)... your intent is much clearer
to me now, thanx. I'm fine with some-> after hearing that.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.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: Proposed change to let-> syntax

[Marek Šrank]

+1

On Saturday, December 1, 2012 6:38:54 PM UTC+1, Andy Fingerhut wrote:
>
> I don't have suggestions for the best names for these new things, but one 
> good example in the doc string would go a long way to making it clearer 
> what they *do* and how they are intended to be used.  The doc strings are 
> written once, but read thousands of times, and are your most reliable line 
> of communication to Clojure developers.  Everyone can find them quickly. 
>
> Andy 
>
> On Dec 1, 2012, at 6:48 AM, Rich Hickey wrote: 
>
> > I'll argue that if 'e' in conde is enough to imply 'each' then '->' in 
> cond-> is enough to imply it keeps threading. 
> > 
> > I think many people have ideas about -> operators born of some of these 
> libraries that supply a wealth of 'things you can use in ->'.  Most of 
> their operators have '->' in their names, but don't fundamentally thread - 
> e.g. they are terminators or one shots like if-> (or ->if). 
> > 
> > A op-> operator, IMO, should take an open set of expressions and thread 
> the return values through them in some way. Otherwise it shouldn't be an 
> op->. 
> > 
> > When one reads -> as 'thread' vs 'for use in threading', things might 
> become clearer. 
> > 
> > 
> > On Dec 1, 2012, at 9:31 AM, Steve Miner wrote: 
> > 
> >> gate-> would work.  Like guard-> it doesn't have any connotations in 
> the Clojure world, but it's learnable.  I'll add one more: qual-> ... short 
> for "qualified threading macro".  Each clause is qualified by a test 
> condition. 
> >> 
> >> Of course, there's always conde-> to borrow from miniKanren and 
> core.logic.  The "e" stands for "every" because multiple clauses can 
> succeed as opposed to the short-circuiting cond. 
> >> 
> >> 
> >> On Nov 30, 2012, at 2:49 PM, Rich Hickey > 
> wrote: 
> >> 
> >>> 
> >>> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote: 
> >>> 
>  I propose guard-> to avoid the cond-> confusion. 
>  
> >>> 
> >>> Yeah, that came up. Guards in other langs are short circuiting, just 
> like cond. 
> >>> 
> >>> Another in that camp was gate-> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@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+u...@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 clo...@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+u...@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: Proposed change to let-> syntax

[Andy Fingerhut]

I don't have suggestions for the best names for these new things, but one good 
example in the doc string would go a long way to making it clearer what they 
*do* and how they are intended to be used.  The doc strings are written once, 
but read thousands of times, and are your most reliable line of communication 
to Clojure developers.  Everyone can find them quickly.

Andy

On Dec 1, 2012, at 6:48 AM, Rich Hickey wrote:

> I'll argue that if 'e' in conde is enough to imply 'each' then '->' in cond-> 
> is enough to imply it keeps threading.
> 
> I think many people have ideas about -> operators born of some of these 
> libraries that supply a wealth of 'things you can use in ->'.  Most of their 
> operators have '->' in their names, but don't fundamentally thread - e.g. 
> they are terminators or one shots like if-> (or ->if).
> 
> A op-> operator, IMO, should take an open set of expressions and thread the 
> return values through them in some way. Otherwise it shouldn't be an op->.
> 
> When one reads -> as 'thread' vs 'for use in threading', things might become 
> clearer.
> 
> 
> On Dec 1, 2012, at 9:31 AM, Steve Miner wrote:
> 
>> gate-> would work.  Like guard-> it doesn't have any connotations in the 
>> Clojure world, but it's learnable.  I'll add one more: qual-> ... short for 
>> "qualified threading macro".  Each clause is qualified by a test condition.
>> 
>> Of course, there's always conde-> to borrow from miniKanren and core.logic.  
>> The "e" stands for "every" because multiple clauses can succeed as opposed 
>> to the short-circuiting cond.
>> 
>> 
>> On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:
>> 
>>> 
>>> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
>>> 
 I propose guard-> to avoid the cond-> confusion.
 
>>> 
>>> Yeah, that came up. Guards in other langs are short circuiting, just like 
>>> cond.
>>> 
>>> Another in that camp was gate->
>> 
>> -- 
>> 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: Clojure CLR and System.Double Behavior

[Frank Failla]

Thank you!

On Nov 30, 2012, at 11:35 PM, dmiller  wrote:

> Patched in master branch.
> 
> Clojure 1.5.0-master-SNAPSHOT
> user=>
> user=> (defn bar [^Double d] d)
> #'user/bar
> user=> (defn baz [^System.Double d] d)
> #'user/baz
> user=> (bar 1.2)
> 1.2
> user=> (baz 1.2)
> 1.2
> user=> (defprotocol FP (foo [_]))
> FP
> user=> (extend-protocol FP System.Double (foo [d] d))
> nil
> user=> (foo 1.2)
> 1.2
> 
> You can now type hint with double, Double and System.Double.
> 
> One should keep in mind that this is the CLR, not C# (or the JVM).  Thus, 
> int, Int32, System.Int32 and float, Single, System.Single.
> 
> Note  that a type hint such as ^System.Int32 x  is actually using the symbol 
> System.Int32 as the value for :tag -- that is how the LispReader works. 
> However, if you were to put :tag metadata on programmatically and actually 
> use the type System.Int32 -- well, that should work also. 
> 
> 
> -David
> 
>> 
>> On Thursday, November 29, 2012 11:02:19 AM UTC-6, ffailla wrote:
>>> 
>>> I have discovered some odd behavior when type-hinting fns with 
>>> ^System.Double:
>>> 
>>> user=> (defn bar [^System.Double d] d)
>>> #'user/bar
>>> user=> (bar 1.2)
>>> 2.35293190771409E-316
>>> user=> (bar 1)
>>> 2.35069794048985E-316
>>> 
>>> The same behavior occurs when extending double via extend-protocol or 
>>> extend-type:
>>> 
>>> user=> (defprotocol FooProto (foo [_]))
>>> user=> (extend-protocol FooProto System.Double (foo [d] d))
>>> nil
>>> user=> (foo 1.2)
>>> 2.25126584588049E-316
>>> 
>>> Any ideas?  Thanks.
>>> 
>>> -Frank Failla
> -- 
> 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: Proposed change to let-> syntax

[Rich Hickey]

I'll argue that if 'e' in conde is enough to imply 'each' then '->' in cond-> 
is enough to imply it keeps threading.

I think many people have ideas about -> operators born of some of these 
libraries that supply a wealth of 'things you can use in ->'.  Most of their 
operators have '->' in their names, but don't fundamentally thread - e.g. they 
are terminators or one shots like if-> (or ->if).

A op-> operator, IMO, should take an open set of expressions and thread the 
return values through them in some way. Otherwise it shouldn't be an op->.

When one reads -> as 'thread' vs 'for use in threading', things might become 
clearer.

 
On Dec 1, 2012, at 9:31 AM, Steve Miner wrote:

> gate-> would work.  Like guard-> it doesn't have any connotations in the 
> Clojure world, but it's learnable.  I'll add one more: qual-> ... short for 
> "qualified threading macro".  Each clause is qualified by a test condition.
> 
> Of course, there's always conde-> to borrow from miniKanren and core.logic.  
> The "e" stands for "every" because multiple clauses can succeed as opposed to 
> the short-circuiting cond.
> 
> 
> On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:
> 
>> 
>> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
>> 
>>> I propose guard-> to avoid the cond-> confusion.
>>> 
>> 
>> Yeah, that came up. Guards in other langs are short circuiting, just like 
>> cond.
>> 
>> Another in that camp was gate->
> 
> -- 
> 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: Proposed change to let-> syntax

[Rich Hickey]

On Nov 30, 2012, at 4:53 PM, Sean Corfield wrote:

> On Fri, Nov 30, 2012 at 7:37 AM, Rich Hickey  wrote:
> A) let-> becomes as->
> 
> Fine with that.
>  
> B) test-> becomes cond->
> 
> Fine with that (because I can't think of anything better).
>  
> C) when-> becomes some->
> 
> and in doing so, tests for non-nil rather than truth.
> 
> Given that some-> threads while non-nil but the fn some stops with the first 
> logical true value, this seems counter-intuitive to me. when-> seems better 
> here, or while-> perhaps? What other names were considered?

when and while also use logical truth. We don't have anything where the basis 
is non-nil. Thus my extended description of how some* could come to occupy that 
role.

Avoiding some-> due to the less-often used function means the only other viable 
alternatives are:

a completely new name
thread only logical truth (i.e. can't thread false)

one alternative was: 

is->


-- 
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: Proposed change to let-> syntax

[Steve Miner]

gate-> would work.  Like guard-> it doesn't have any connotations in the 
Clojure world, but it's learnable.  I'll add one more: qual-> ... short for 
"qualified threading macro".  Each clause is qualified by a test condition.

Of course, there's always conde-> to borrow from miniKanren and core.logic.  
The "e" stands for "every" because multiple clauses can succeed as opposed to 
the short-circuiting cond.


On Nov 30, 2012, at 2:49 PM, Rich Hickey  wrote:

> 
> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote:
> 
>> I propose guard-> to avoid the cond-> confusion.
>> 
> 
> Yeah, that came up. Guards in other langs are short circuiting, just like 
> cond.
> 
> Another in that camp was gate->

-- 
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: refer-clojure seems to have no effect.

[Thomas Goossens]

Solved it for me as well.

Great :D

On Thursday, November 22, 2012 4:03:38 PM UTC+1, Chas Emerick wrote:
>
> The user namespace is implicitly created with a blanket refer for 
> clojure.core; removing the mapping for e.g. '== in user would require using 
> ns-unmap.
>
> Just use a different namespace.
>
> - Chas
>
> On Nov 22, 2012, at 8:40 AM, Frederik De Bleser wrote:
>
> Hi,
>
> I'm trying to use core.logic using the following namespace expression 
> (modelled on core.logic's own test file):
>
> (ns user
>   (:refer-clojure :exclude [==])
>   (:use clojure.core.logic))
>
> However, this gives the following warning:
>
> WARNING: == already refers to: #'clojure.core/== in namespace: user, 
> being replaced by: #'clojure.core.logic/==
>
> It seems that the "refer-clojure" line has no effect. What am I doing 
> wrong?
>
> Kind regards,
>
> Frederik
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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: class loading problem in embedded clojure

[Vladimir Tsichevski]

Hi,

nobody still cannot explain why

PlatformUI (PlatformUI/getWorkbench)

works, and

(PlatformUI/getWorkbench)

does not?

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

New Clojurescript Project: browsing the web collectively.

[Jeremy Kross]

Hi all,

I wrote a little thing in Clojurescript.  Hopefully someone here will find 
it interesting.  Its a bookmarklet that lets users on a website see one 
another and interact.

http://www.treklet.com

You can click Try it Now to give it a run. Let me know if anyone has 
thoughts.

Jeremy







-- 
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 - Conjure 2.1.1 - Lightweight mocking library

[Alex Baranosky]

Glad you like it.  That situation has never come up, because usually in
unit tests you don't have so many calls in a loop.

On Sat, Dec 1, 2012 at 12:02 AM, faenvie  wrote:

> I tried it out and like it.
>
> i esp. inspiring to see how you do the lein multi-deps-test against
> clojure-versions 1.2 to 1.5.
>
> could the state that builds up in call-times cause mem-resource-problem
> with long-running-loops in fake-context ?
>
> but normally you don't have those in unit-testing ... and could
> also fallback to using with-redefs.
>
> if it integrates well with core.contracts, test.generative etc.
> then its perfectly ok to use.
>
> thank you & have successful time
>
>
> On Tuesday, November 27, 2012 9:22:29 AM UTC+1, Alex Baranosky wrote:
>>
>> Conjure is a lightweight mocking library intended to be used on top of
>> clojure.test.
>>
>> We've been using it at Runa for a long time, and it is compatible with
>> all versions of Clojure from 1.2 to 1.5-beta1.
>>
>> https://github.com/**amitrathore/conjure
>>
>> Alex
>>
>>
>>  --
> 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: First test with JavaFx and blocked yet :(

[Christian Sperandio]

Thanks :)
I got my error. Because I declared my code as a class, my mind turned into a 
object logic and I forget I was always in Clojure and in functional mind. 

I'd like understand an another point too. When I generate a jar with lein 
uberjar, the code works. But if I do only a lein jar, the running failed with a 
NoClassDef exception. Even if when I run the jar I use the java command's 
option -cp to give the jfxrt.java's place. 
Do I forget something?


Chris

Le 1 déc. 2012 à 01:14, Kevin Downey  a écrit :

> here is an example https://gist.github.com/4179694
> 
> 
> On Fri, Nov 30, 2012 at 4:13 PM, Kevin Downey  wrote:
> javafx.application.Application/launch is looking at the class that the method 
> that calls it belongs to, in this case it belongs to the IFn class generated 
> for the -main function, there is an arity for launch that takes the class you 
> want to use instead of the weird detection thing
> 
> 
> 
> 
> 
> On Fri, Nov 30, 2012 at 3:38 PM, Christian Sperandio 
>  wrote:
> Hi,
> 
> I'm testing JavaFX with Clojure 1.4 and I've got some issues.
> I wrote this code:
> (ns test-javafx2-clj.core
>   (:import javafx.application.Application
>javafx.stage.Stage
>(javafx.scene Parent Scene))
>   
>   (:gen-class
>:extends javafx.application.Application))
> 
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>   (println "Before the launch call")
>   (javafx.application.Application/launch args))
> 
> (defn -start
>   [this stage]
>   (println "Arf!"))
>   ;(.setTitle stage "Hello World!"))
> 
> My project.clj is the following:
> (ns test-javafx2-clj.core
>   (:import javafx.application.Application
>javafx.stage.Stage
>(javafx.scene Parent Scene))
>   
>   (:gen-class
>:extends javafx.application.Application))
> 
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>   (println "Before the launch call")
>   (javafx.application.Application/launch args))
> 
> (defn -start
>   [this stage]
>   (println "Arf!"))
>   ;(.setTitle stage "Hello World!"))
> 
> 
> I build my jar with the command lein uberjar, and when I launch the generated 
> jar I get this error:
> Exception in thread "main" java.lang.RuntimeException: Error: class 
> test_javafx2_clj.core$_main is not a subclass of 
> javafx.application.Application
>   at javafx.application.Application.launch(Application.java:211)
>   at test_javafx2_clj.core$_main.doInvoke(core.clj:14)
>   at clojure.lang.RestFn.invoke(RestFn.java:397)
>   at clojure.lang.AFn.applyToHelper(AFn.java:159)
>   at clojure.lang.RestFn.applyTo(RestFn.java:132)
>   at test_javafx2_clj.core.main(Unknown Source)
> 
> It's very strange because I well wrote the :extends  
> javafx.application.Application. So, I don't understand why I've got this 
> error.
> 
> Thanks for your help.
> 
> Chris
> -- 
> 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?
> 
> 
> 
> -- 
> 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

-- 
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 - Conjure 2.1.1 - Lightweight mocking library

[faenvie]

I tried it out and like it.

i esp. inspiring to see how you do the lein multi-deps-test against 
clojure-versions 1.2 to 1.5.

could the state that builds up in call-times cause mem-resource-problem 
with long-running-loops in fake-context ?

but normally you don't have those in unit-testing ... and could
also fallback to using with-redefs.

if it integrates well with core.contracts, test.generative etc.  
then its perfectly ok to use.

thank you & have successful time

On Tuesday, November 27, 2012 9:22:29 AM UTC+1, Alex Baranosky wrote:
>
> Conjure is a lightweight mocking library intended to be used on top of 
> clojure.test.
>
> We've been using it at Runa for a long time, and it is compatible with all 
> versions of Clojure from 1.2 to 1.5-beta1.
>
> https://github.com/amitrathore/conjure
>
> Alex
>
>
>

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