Re: [ANN] Clojure 1.8.0-RC4 is now available

[Mikera]

On Thursday, 17 December 2015 14:59:37 UTC, Herwig Hochleitner wrote:
>
> Am 17.12.2015 02:35 schrieb "Mikera"  >:
>
> > What's the plan with Tuples more broadly?
>
> Speaking as a kibitzer to the process: Suppose somebody was to carry this 
> along, I'd like to see these points addressed:
>
> IIRC, the breaking factor to the proposal were slow-downs in real-world 
> programs, likely due to pollution of jvm's polymorphic inline caches. It 
> seems necessary to have a benchmark, exercising the data-structure part of 
> clojure.core with real-world degrees of polymorphism, replicating the 
> slow-downs, Rich saw for the proposal. When we have such a realistic basis, 
> to which we can amend expected best- and worst-cases, it's much easier to 
> have a conversion about expected benefits and draw-backs, performance wise.
>

I don't actually recall seeing any benchmarks showing slow-downs in 
real-world programs. Rich made an apparently unsubstantiated assertion that 
these exist but didn't provide his analysis (see CLJ-1517). 

On the other hand Zach ran some benchmarks on JSON decoding and found a 
roughly 2x speedup. That's a pretty big deal for code implementing JSON 
APIs (which is probably a reasonable example of real world, 
nested-data-structure heavy code).

Does anyone have any actual evidence of this supposed slowdown? i.e. is 
there a standard benchmark that is considered acceptable for general 
purpose / real world performance in Clojure applications? If so I'm happy 
to run it and figure out why any slowdown with Tuples is happening. My 
strong suspicion is that the following is true:
1) The Tuples generally provide a noticeable speedup (as demonstrated by 
the various micro-benchmarks)
2) There are a few hotspots where Tuples *don't* make sense because of PIC 
pressure / megamorphic call sites (repeated conj on vectors might be an 
example). These cases can revealed by more macro-level benchmarking.
3) We should be able to identify these cases of 2) and revert to generating 
regular PersistentVectors (or switching to Transients). In that case 
the Tuple patches may develop from being a debatable patch with some 
problematic trade-offs to a pretty clear all-round improvement (in both 
micro and macro benchmarks).

The key point regarding 3): code that is performance sensitive (certainly 
in core, maybe in some libs) should consider whether a Tuple is a good idea 
or not (for any given call-site). These may need addressing individually, 
but this is incremental to the inclusion of Tuples themselves. The 
performance comparison isn't as simple as "current vs. tuples patch", it 
should be "current vs. tuples patch + related downstream optimisation" 
because that is what you are going to see in the released version.

Also it should be remembered that JVMs are getting smarter (escape analysis 
allowing allocation of small objects on the stack etc.) and the Clojure 
compiler is also getting smarter (direct linking etc.). Tuples could 
potentially give further upside in these cases, so there is a broader 
context to be considered. My view is that the balance will shift more in 
favour of Tuples over time as the respective runtime components get smarter 
at taking advantage of type specialisation (happy to hear other views, of 
course).

 

> The second thing, bothering me about the proposal: To me (as a 
> non-authority on the matter), checking in generated files is borderline 
> unacceptable. I'd much rather see such classes generated as part of the 
> build process, e.g. by:
> - using ant or maven plugins to generate java source, or,
> - using macros to generate byte code as part of AOT compilation
>

I agree checking in generated files is a bad idea, that was why I actually 
created hand-coded variants of Zach's original Tuple code as part of 
CLJ-1517. My reasoning for this was as follows:
1) You do in fact want some hand-coded differences, e.g. making the 2-Tuple 
work as a MapEntry, having a single immutable instance of Tuple0 etc.). It 
is annoying to handle these special cases in a code generator
2) Class generation at compile time is fiddly and would complicate the 
build / development process (definitely not a good thing!)
3) It is simpler to maintain a small, fixed number of concrete Java source 
files than it is to maintain a code-generator for the same (which may be 
less lines of code, but has much higher conceptual overhead)
 

> 
>
> So, while the second point certainly would make a proposal more appealing, 
> the first one is mandatory due diligence. I'm really glad, that cognitect 
> acted as a gate-keeper there and saved us from microbenchmark-hell. 
>

Really? I think this CLJ-1517 issue is an example of how *not* to do OSS 
development.
a) Substantial potential improvements (demonstrated with numerous 
benchmarks) sitting unresolved for well over a year with limited / very 
slow feedback
b) Motivated, skilled contributors initially being 

Re: [ANN] Clojure 1.8.0-RC4 is now available

[Mikera]

On Thursday, 17 December 2015 04:34:58 UTC, Alex Miller wrote:
>
>
> On Wed, Dec 16, 2015 at 7:34 PM, Mikera  > wrote:
>
>>
>> What's the plan with Tuples more broadly? 
>>
>
> Don't know.
>
>
I'm willing to take another shot at at a patch for this, as I believe there 
is a decent performance win still on the table. 

But I need some guidance first from the core team on:
a) What "real world" benchmark(s) would be required to demonstrate an 
overall improvement?
b) If I can demonstrate an overall improvement on said benchmark(s), will 
the patch be accepted (otherwise I'm wasting my time)?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Need some direction on writing my .Net build script using clojure

[Erlis Vidal]

Hi all,

I would like to start using clojure at my workplace and I think I've found
a great opportunity. I need to write the build script for our .Net solution
and it will great if I can use clojure for this task.

What I would like to know is if we (the community) have something that is
suitable for this task.

Currently the build scripts are written in Powershell and they use a
library (Psake) that makes easy to invoke MSBuild, this is what I consider
I need to be able to write the script.

I was researching and I found boot-clj and the idea behind it is similar to
the idea behind Psake.

So guys, do you think boot-clj is the way to go or do you think I should be
looking into a different tool?

Any suggestion will be more than appreciated!

Regards,
Erlis

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.8.0-RC4 is now available

[Alex Miller]

I haven't talked to Rich about it recently, but I expect tuples will be 
reassessed at some point. I don't think more patches would be helpful at 
this time.

On Friday, December 18, 2015 at 6:08:39 AM UTC-6, Mikera wrote:
>
> On Thursday, 17 December 2015 04:34:58 UTC, Alex Miller wrote:
>>
>>
>> On Wed, Dec 16, 2015 at 7:34 PM, Mikera  wrote:
>>
>>>
>>> What's the plan with Tuples more broadly? 
>>>
>>
>> Don't know.
>>
>>
> I'm willing to take another shot at at a patch for this, as I believe 
> there is a decent performance win still on the table. 
>
> But I need some guidance first from the core team on:
> a) What "real world" benchmark(s) would be required to demonstrate an 
> overall improvement?
> b) If I can demonstrate an overall improvement on said benchmark(s), will 
> the patch be accepted (otherwise I'm wasting my time)?
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need some direction on writing my .Net build script using clojure

[Ralf Schmitt]

Erlis Vidal  writes:

> Hi all,
>
> I would like to start using clojure at my workplace and I think I've found
> a great opportunity. I need to write the build script for our .Net solution
> and it will great if I can use clojure for this task.
>
> What I would like to know is if we (the community) have something that is
> suitable for this task.
>
> Currently the build scripts are written in Powershell and they use a
> library (Psake) that makes easy to invoke MSBuild, this is what I consider
> I need to be able to write the script.
>
> I was researching and I found boot-clj and the idea behind it is similar to
> the idea behind Psake.
>
> So guys, do you think boot-clj is the way to go or do you think I should be
> looking into a different tool?

I'm just guessing here, but I don't think boot will help you much.

Have a look at Fake: https://fsharp.github.io/FAKE/

I've never used it, but I think it may be more suitable for building
.net programs.

-- 
Cheers
Ralf

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Boot 2.5

[Mimmo Cosenza]

Hi Sean,
FWIW, I confirm your words, even if I only used the 2.4.2 release and I stll 
have to understand a lot of thing about it.

cheers
mimmo

> On 18 Dec 2015, at 23:14, Sean Corfield  wrote:
> 
> Alan Dipert wrote on Wednesday, December 16, 2015 at 3:26 PM:
>> Boot, your friendly neighborhood functional build tool, has just hit version 
>> 2.5.  I invite you to try it out!
> 
> 
> As someone who was extremely skeptical about Boot when it first appeared and 
> who had some bad experiences with very early versions (and was perhaps rather 
> more public in my frustration than was appropriate), I want to say that I’ve 
> spent a couple of days with Boot 2.5 while I’ve been on vacation (taking care 
> of my wife, post-surgery) and I’m very impressed with how far this build tool 
> has come, how friendly and helpful the community is (in the #boot channel on 
> the Clojurians Slack), and how (relatively) easy it is to extend Boot to 
> perform new tasks!
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: recur does not work within some macros, how to deal with it?

[Witold Szczerba]

You are so right, the answer seems obvious now :)

Thanks,
Witold Szczerba

On Sat, Dec 19, 2015 at 1:57 AM, Herwig Hochleitner 
wrote:

> Use a function instead of the loop:
>
> (defn ws [req]
>   (with-channel req channel
> ((fn loop-f [x]
>(timer/schedule-task
>  3000
>  (println x)
>  (loop-f (+ x 1
>  0)))
>
> loop-recur is used to prevent unbounded stack growth, but the timer task
> acts as a sort of trampoline anyway, resetting the stack between each
> invokation. The lazy-seq macro works in a similar way.
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

recur does not work within some macros, how to deal with it?

[Witold Szczerba]

Hi,
I am doing my first steps in Clojure and I have a problem with "recur".
Here's an example of the HTTP Kit's handler I just wrote to test drive the
first Clojure piece of code of mine:

(defn ws [req]
  (with-channel req channel
(loop [x 1]
  (timer/schedule-task
3000
(println x)
(recur (+ x 1))

Trouble is, the org.httpkit.timer/schedule-task macro wraps my form with
"recur" inside a function, so recur does not schedule a new timer, it just
loops over (println x) form:

https://github.com/http-kit/http-kit/blob/2.1.19/src/org/httpkit/timer.clj#L27

As far as I can see, there are no named recursion targets, so how can I
loop the schedule?

Regards,
Witold Szczerba

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.8.0-RC4 is now available

[Herwig Hochleitner]

Apologies for the incoming wall of text, as well as for co-opting the -RC4
thread

TLDR:
-RC4 LGTM, I enjoy the startup-speed boost
- we need a benchmark before further evaluating the work on tuples

2015-12-18 13:02 GMT+01:00 Mikera :

>
> I don't actually recall seeing any benchmarks showing slow-downs in
> real-world programs. Rich made an apparently unsubstantiated assertion that
> these exist but didn't provide his analysis (see CLJ-1517).
>

I don't remember any benchmarks showing the slowdown either, but I'm taking
Rich's word for it.

On the other hand Zach ran some benchmarks on JSON decoding and found a
> roughly 2x speedup. That's a pretty big deal for code implementing JSON
> APIs (which is probably a reasonable example of real world,
> nested-data-structure heavy code).
>

Well I'm also taking your word for that and for the speedups that you saw
in other benchmarks. Whether it represents real-world usage, depends on the
shape of your test data. If the test data is just (repeat [:test :vector]),
then no it doen't represent real-world usage, because it would exercise
just one arity.
Is this benchmark, you're speaking of, posted somewhere the wider community
can review it? I'd like to play with it, see the speedup and try to break
it by adding polymorphism. I'd also be happy to help developing the test
cases.

I think it's good to have your tuple proposal around, so that we have
something to benchmark stock clojure against, but, before making a serious
push into core, we should have a test suite, that allows to run many
different permutations of enabled test cases (exercising various arities),
with clojure + various proposal patches, ideally on various jvms. Only then
we can get serious about discussing performance trade-offs.

Does anyone have any actual evidence of this supposed slowdown? i.e. is
> there a standard benchmark that is considered acceptable for general
> purpose / real world performance in Clojure applications?
>

If there were, somebody would probably have pointed it out. Right now, I
feel that any work is best spent on developing such a benchmark, to help
the community evaluate the situation.


> If so I'm happy to run it and figure out why any slowdown with Tuples is
> happening. My strong suspicion is that the following is true:
> 1) The Tuples generally provide a noticeable speedup (as demonstrated by
> the various micro-benchmarks)
>

(IMHO) Clojure has always been a big-picture language and reliable
end-to-end performance in a multi-tenant setup is more important than
looking good on alioth


> 2) There are a few hotspots where Tuples *don't* make sense because of PIC
> pressure / megamorphic call sites (repeated conj on vectors might be an
> example). These cases can revealed by more macro-level benchmarking.
>

There are many possible caveats:
- is the morphism degree of a protocol-call local to the callsite or global
to the protocol dispatch fn?
- does the gc take advantage of objects being uniformly sized and how much
of that will we lose?
- how much do the hot-spots shift amongst various programs?

3) We should be able to identify these cases of 2) and revert to generating
> regular PersistentVectors (or switching to Transients). In that case
> the Tuple patches may develop from being a debatable patch with some
> problematic trade-offs to a pretty clear all-round improvement (in both
> micro and macro benchmarks).
>

Well, before we have a comprehensive set of benchmarks, all we can really
do, is throw code at a wall and see if it sticks.

The key point regarding 3): code that is performance sensitive (certainly
> in core, maybe in some libs) should consider whether a Tuple is a good idea
> or not (for any given call-site). These may need addressing individually,
> but this is incremental to the inclusion of Tuples themselves. The
> performance comparison isn't as simple as "current vs. tuples patch", it
> should be "current vs. tuples patch + related downstream optimisation"
> because that is what you are going to see in the released version.
>

To be really honest, this sounds a bit like: If only cognitect shoved
tuples down the community's throat, people would start optimizing for them.
Which is true. It's also probable, that, after the dust settling, we'd end
up with somewhat better performance than we have now. We still shouldn't do
it that way.

Why not start with a tuple library, that we can use if we want increased
tuple performance? That certainly worked for cljx, even if people used to
complain about it.
(ns my.lib/awesome-ns
  (:refer-clojure :exclude [into conj vector vec])
  (:require [mikera.awesome/vectors :refer [into conj vector vec]]))

You could even include a flag in your tuple library to revert to core
functions, in order to benchmark against core without rewriting anything.

Also it should be remembered that JVMs are getting smarter (escape analysis
> allowing allocation of small objects on the stack etc.) 

Re: recur does not work within some macros, how to deal with it?

[Herwig Hochleitner]

Use a function instead of the loop:

(defn ws [req]
  (with-channel req channel
((fn loop-f [x]
   (timer/schedule-task
 3000
 (println x)
 (loop-f (+ x 1
 0)))

loop-recur is used to prevent unbounded stack growth, but the timer task
acts as a sort of trampoline anyway, resetting the stack between each
invokation. The lazy-seq macro works in a similar way.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

hara.concurrent.procedure "2.2.13" - parameterised control of current execution

[zcaudate]

Hey guys.

I've been playing with this idea for the last 6 months. Really excited to 
have finally written it up. Hope to get some feedback!

blog:
http://z.caudate.me/parameterised-execution-hara-concurrent-procedure/

docs:
http://docs.caudate.me/hara/hara-concurrent-procedure.html

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Boot 2.5

[Sean Corfield]

Alan Dipert wrote on Wednesday, December 16, 2015 at 3:26 PM:
Boot, your friendly neighborhood functional build tool, has just hit version 
2.5.  I invite you to try it out!

As someone who was extremely skeptical about Boot when it first appeared and 
who had some bad experiences with very early versions (and was perhaps rather 
more public in my frustration than was appropriate), I want to say that I’ve 
spent a couple of days with Boot 2.5 while I’ve been on vacation (taking care 
of my wife, post-surgery) and I’m very impressed with how far this build tool 
has come, how friendly and helpful the community is (in the #boot channel on 
the Clojurians Slack), and how (relatively) easy it is to extend Boot to 
perform new tasks!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] boot-expectations: run Expectations tests via Boot

[Sean Corfield]

What?
A Boot task to run Expectations tests.

Where?
https://github.com/seancorfield/boot-expectations

Thanks to:
Alan Dipert and Micha Niskin for their help and patience as I learned enough of 
Boot 2.5 to write this!

What’s next?
Task options to filter / exclude test. And anything else the community might 
want!

Why?
World Singles has a large and ugly Ant script for build / test / deploy stuff 
that calls out to Leiningen for various things. We’ve always wanted to replace 
it (or large parts of it) with Clojure but Leiningen plugins have never seemed 
a "good fit" for general purpose (non-Clojure) build stuff. Boot looks much 
more suitable with general purpose tasks and the Filesets abstraction. In order 
for us to switch to Boot, we must be able to everything we currently do with 
Leiningen, and we rely on lein-expectations and lein-autoexpect a lot, so 
running Expectations with Boot was a prerequisite and a first step!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Q] What would be the best approach or design for converting this common lisp code?

[Sungjin Chun]

Hi,

The code repo is https://github.com/wzrdsappr/trading-core .

If you look at the code, the main trading agent is designed using 
inheritance and the main
operation (consume) function mainly depends upon mutable update of agent's 
states.

As far as I know Clojure does not permit attribute inheritance and this 
kind of state update is
not recommended approach. 

What would be the best approach in Clojure?

Thank you in advance and sorry for my poor english.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] boot-expectations: run Expectations tests via Boot

[Sean Corfield]

boot-expectations 1.0.0 is available!

What?
A Boot task to run Expectations tests.

Where?
https://github.com/seancorfield/boot-expectations

Thanks to:
Alan Dipert and Micha Niskin for their help and patience as I learned enough of 
Boot 2.5 to write this!

What’s next?
Task options to filter / exclude test. And anything else the community might 
want!

The new 1.0.0 release now supports:

-c version — to specify the version of Clojure you want to run your tests with
-i pattern / -e pattern — to include / exclude project namespaces using regex
-v — verbose: prints each namespace completed as Expectations run

Why?
World Singles has a large and ugly Ant script for build / test / deploy stuff 
that calls out to Leiningen for various things. We’ve always wanted to replace 
it (or large parts of it) with Clojure but Leiningen plugins have never seemed 
a "good fit" for general purpose (non-Clojure) build stuff. Boot looks much 
more suitable with general purpose tasks and the Filesets abstraction. In order 
for us to switch to Boot, we must be able to everything we currently do with 
Leiningen, and we rely on lein-expectations and lein-autoexpect a lot, so 
running Expectations with Boot was a prerequisite and a first step!


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.