Re: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

I'm missing something, alter-var-root'ing *clojure-version* works just fine
when calling (clojure-version).

(alter-var-root #'*clojure-version* assoc :qualifier "patched")
(clojure-version)
;=> "1.8.0-patched"

Thanks,
Ambrose

On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> I don't think CLJ-1845  had
> the intended effect.
>
> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply
> f args
> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> user=> (load)
> "patched"
> nil
> user=> (require 'clojure.core :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload-all)
> nil
>
> I was expected "patched" to be printed with each call to `load` via
> `require`.
>
> Do others observe this also?
>
> Thanks,
> Ambrose
>
>
> On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller  wrote:
>
>> Clojure 1.8.0-RC2 is now available. *This build is a "release
>> candidate"!* We would appreciate any and all testing you can do on your
>> own libraries or internal projects to find problems.
>>
>> Try it via
>>
>>- Download:
>>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
>>- Leiningen: [org.clojure/clojure "1.8.0-RC2"]
>>
>> Below are the changes since 1.8.0-RC1. See the full 1.8 change log here:
>> https://github.com/clojure/clojure/blob/master/changes.md.
>>
>>- CLJ-1846  Fix
>>VerifyError when primitive type hints are incorrect. These cases now throw
>>compiler errors.
>>   - Example: (defn foo ^long [] 1)  (Integer/bitCount ^int (foo))
>>   - In this example, foo returns a long but is type hinted
>>   (incorrectly) as an int. This case will now throw a compilation error. 
>> The
>>   correct way to do this is with a cast:  (Integer/bitCount (int
>>   (foo)))
>>- CLJ-1825  Fix
>>compilation errors on direct linking of anonymous recursive functions
>>
>> --
>> 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: [ANN] Clojure 1.8.0-RC2

[Alex Miller]

I see the same and I suspect it's because of the forward declare.  :(


On Friday, November 20, 2015 at 12:25:28 AM UTC-6, Ambrose 
Bonnaire-Sergeant wrote:
>
> I don't think CLJ-1845  had 
> the intended effect.
>
> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply 
> f args
> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> user=> (load)
> "patched"
> nil
> user=> (require 'clojure.core :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload-all)
> nil
>
> I was expected "patched" to be printed with each call to `load` via 
> `require`.
>
> Do others observe this also?
>
> Thanks,
> Ambrose
>
>

-- 
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: Any chance of core.logic getting extended with probKanren?

[David Nolen]

Definitely interested in it! But I don't have time to work on it myself. So
the likelihood of this feature landing is entirely dependent on
contributions :)

HTH,
David

On Fri, Nov 20, 2015 at 7:01 AM, Henrik Larsson 
wrote:

> I have started to play around with ProbLog2 and find the concept of
> probabilistic logic programming to be super fun. When googeling miniKanren
> and probabilistic logic programming the following came up:
> https://github.com/webyrd/probKanren
>
> So my question now is what are the chances that something like probKanren
> getting implemented in core.logic and how advance is probKanren vs
> ProbLog2? What im after is the conditional probabilites that ProbLog2 can
> handle.
>
> There are some documentation on core.logic (
> https://github.com/clojure/core.logic/wiki/CLP(Prob)) but it is dated at
> 2013 and im not sure what the roadmap is for core.logic or if it even has a
> roadmap.
>
>
> Thanks for any input regarding this.
>
> Best regards Henrik
>
> --
> 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: [ANN] Clojure 1.8.0-RC2

[Nicola Mometto]

*clojure-version* is not a function, it's not affected by direct linking

> On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> I'm missing something, alter-var-root'ing *clojure-version* works just fine 
> when calling (clojure-version).
> 
> (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> (clojure-version)
> ;=> "1.8.0-patched"
> 
> Thanks,
> Ambrose
> 
> On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant 
>  wrote:
> I don't think CLJ-1845 had the intended effect.
> 
> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f 
> args
> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> user=> (load)
> "patched"
> nil
> user=> (require 'clojure.core :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload-all)
> nil
> 
> I was expected "patched" to be printed with each call to `load` via `require`.
> 
> Do others observe this also?
> 
> Thanks,
> Ambrose
> 
> 
> On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller  wrote:
> Clojure 1.8.0-RC2 is now available. This build is a "release candidate"! We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
> 
> Try it via
>   • Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
>   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> Below are the changes since 1.8.0-RC1. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>   • CLJ-1846 Fix VerifyError when primitive type hints are incorrect. 
> These cases now throw compiler errors.
>   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int (foo))
>   • In this example, foo returns a long but is type hinted 
> (incorrectly) as an int. This case will now throw a compilation error. The 
> correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
>   • CLJ-1825 Fix compilation errors on direct linking of anonymous 
> recursive functions
> 
> -- 
> 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.

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

Any chance of core.logic getting extended with probKanren?

[Henrik Larsson]

I have started to play around with ProbLog2 and find the concept of 
probabilistic logic programming to be super fun. When googeling miniKanren 
and probabilistic logic programming the following came up:
https://github.com/webyrd/probKanren

So my question now is what are the chances that something like probKanren 
getting implemented in core.logic and how advance is probKanren vs 
ProbLog2? What im after is the conditional probabilites that ProbLog2 can 
handle.

There are some documentation on core.logic 
(https://github.com/clojure/core.logic/wiki/CLP(Prob)) but it is dated at 
2013 and im not sure what the roadmap is for core.logic or if it even has a 
roadmap.


Thanks for any input regarding this.

Best regards Henrik

-- 
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: Data visualization workshops post-mortem

[bpbb9b]

For what sounds like it was a great success, I wouldn't call this a 
"post-mortem", as though it's dead! Very useful notes


On Thursday, November 19, 2015 at 1:51:06 PM UTC, Karsten Schmidt wrote:
> For those interested in data visualization with CLJ/CLJS, my thi.ng
> libs, reagent & figwheel, I've recently been teaching two 3-day
> workshops in London and published repos with fully commented source
> code, incl. a lengthy report of the last workshop here:
> 
> https://medium.com/@thi.ng/workshop-report-building-linked-data-heatmaps-with-clojurescript-thi-ng-102e0581225c
> 
> https://github.com/thi-ng/ws-ldn-1
> https://github.com/thi-ng/ws-ldn-2
> 
> Best, 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 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] pex, a powerful PEG parsing library

[Ghadi Shayban]

The performance baseline was a pleasant surprise, but does get me thinking: 
How complex is Jackson?  It's thousands of lines of code.  I know I just 
wrote this library to help avoid writing recursive descent parsers 
manually, but maybe for JSON specifically an approach like Go's scanner [1] 
is worth pursuing in Java.

As for Pex itself, lots of areas of potential optimization:
1) Better char matchers -- like int-mask based ones.  Initial profiling 
suggested this.
2) Perhaps aggressive inlining of rules
3) Find out what Roberto Ierusalimschy did when he built a JIT for LPEG. 
 He said it improved perf by 3x, but it's not in mainline.
4) Implement the TestChar and TestCharset bytecodes from the LPEG paper -- 
I have the AST to be able to do it.  (It helps prevent call stack churn 
when you immediately jump into a rule and then fail because the first char 
doesn't match.)  There is a valuable match capture optimization to perform 
too.
5) Perhaps tear apart the StackEntry object into int[].  VM debugging was 
such a PITA, I would have never finished it if I did that at the outset.

[1] https://github.com/golang/go/blob/master/src/encoding/json/scanner.go

On Thursday, November 19, 2015 at 3:58:47 PM UTC-5, Colin Fleming wrote:
>
> I'm really impressed by how fast it is out of the box with basically no 
> optimisations. Tatu Saloranta is fanatical about Jackson performance, 
> getting to within 6x on the first attempt is very promising.
>
> On 20 November 2015 at 02:43, Ghadi Shayban  > wrote:
>
>> Thanks for taking a look.
>>
>> User-level bytecode allows me an easier choice to build a JIT or tracing 
>> infrastructure, while being far less complex than writing out JVM bytecode 
>> during grammar compile.
>>
>> Christophe has certainly been a help offline with design choices.  I 
>> wanted PEG, no ambiguity, unlike instaparse or parsnip.  Most of the API 
>> inspiration was from LPEG & Scala's Parboiled2.  Some of the VM internals 
>> are close to JRuby's Joni regex engine.
>>
>>
>>
>> On Thursday, November 19, 2015 at 8:24:37 AM UTC-5, bernardH wrote:
>>>
>>> This is interesting !
>>> It reminds me of Parsnip from C.Grand [0], have you considered it when 
>>> desining pex ? As your parser is focusing of characters, I am wondering : 
>>> could the operations triggered by the execution of your pex code be simple 
>>> enough to warrant actual compiling to JVM bytecode (at run time, with ASM 
>>> [1]) for maximum performance ?
>>>
>>> Best Regards,
>>>
>>> Bernard
>>>
>>> [0] https://github.com/cgrand/parsnip/
>>> [1] http://asm.ow2.org/
>>>
>>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@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: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

Thanks.

Here's a good test, feel free to use it.

(deftest direct-linking-for-load
  (let [original-load load
called? (atom nil)
logger (fn [& args]
 (reset! called? true)
 nil)]
(with-redefs [load logger]
  ;; doesn't actually load clojure.repl, but should
  ;; eventually call `load` and reset called?.
  (require 'clojure.repl :reload))
(is @called?)))

Thanks,
Ambrose

On Fri, Nov 20, 2015 at 10:55 AM, Alex Miller  wrote:

> I reopened the ticket. You can hold on the patch - I think we're going to
> make another change that will affect what the patch will be.
>
>
> On Friday, November 20, 2015 at 9:29:43 AM UTC-6, Ambrose
> Bonnaire-Sergeant wrote:
>>
>> I was going to reopen the ticket and create/test a patch. Does that work
>> for you?
>>
>> On Fri, Nov 20, 2015 at 10:22 AM, Ambrose Bonnaire-Sergeant <
>> abonnaireserge...@gmail.com> wrote:
>>
>>> Alex,
>>>
>>> That sounds correct.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Fri, Nov 20, 2015 at 10:10 AM, Alex Miller 
>>> wrote:
>>>
 I see the same and I suspect it's because of the forward declare.  :(


 On Friday, November 20, 2015 at 12:25:28 AM UTC-6, Ambrose
 Bonnaire-Sergeant wrote:
>
> I don't think CLJ-1845 
> had the intended effect.
>
> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched")
> (apply f args
> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> user=> (load)
> "patched"
> nil
> user=> (require 'clojure.core :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload)
> nil
> user=> (require 'clojure.tools.analyzer :reload-all)
> nil
>
> I was expected "patched" to be printed with each call to `load` via
> `require`.
>
> Do others observe this also?
>
> Thanks,
> Ambrose
>
> --
 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.
>

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

[Nicola Mometto]

It doesn't, but direct linking only affects invocations


> On 20 Nov 2015, at 15:21, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> Wait, how does the compiler know that *clojure-version* isn't a function?
> 
> On Fri, Nov 20, 2015 at 10:01 AM, Nicola Mometto  wrote:
> *clojure-version* is not a function, it's not affected by direct linking
> 
> > On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant 
> >  wrote:
> >
> > I'm missing something, alter-var-root'ing *clojure-version* works just fine 
> > when calling (clojure-version).
> >
> > (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> > (clojure-version)
> > ;=> "1.8.0-patched"
> >
> > Thanks,
> > Ambrose
> >
> > On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant 
> >  wrote:
> > I don't think CLJ-1845 had the intended effect.
> >
> > user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply f 
> > args
> > #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
> > "user$eval1241$fn__1242$fn__1243@1c857e6"]
> > user=> (load)
> > "patched"
> > nil
> > user=> (require 'clojure.core :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload-all)
> > nil
> >
> > I was expected "patched" to be printed with each call to `load` via 
> > `require`.
> >
> > Do others observe this also?
> >
> > Thanks,
> > Ambrose
> >
> >
> > On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller  wrote:
> > Clojure 1.8.0-RC2 is now available. This build is a "release candidate"! We 
> > would appreciate any and all testing you can do on your own libraries or 
> > internal projects to find problems.
> >
> > Try it via
> >   • Download: 
> > https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
> >   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> > Below are the changes since 1.8.0-RC1. See the full 1.8 change log here: 
> > https://github.com/clojure/clojure/blob/master/changes.md.
> >   • CLJ-1846 Fix VerifyError when primitive type hints are incorrect. 
> > These cases now throw compiler errors.
> >   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int 
> > (foo))
> >   • In this example, foo returns a long but is type hinted 
> > (incorrectly) as an int. This case will now throw a compilation error. The 
> > correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
> >   • CLJ-1825 Fix compilation errors on direct linking of anonymous 
> > recursive functions
> >
> > --
> > 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.
> 
> --
> 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 

Re: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

Alex,

That sounds correct.

Thanks,
Ambrose

On Fri, Nov 20, 2015 at 10:10 AM, Alex Miller  wrote:

> I see the same and I suspect it's because of the forward declare.  :(
>
>
> On Friday, November 20, 2015 at 12:25:28 AM UTC-6, Ambrose
> Bonnaire-Sergeant wrote:
>>
>> I don't think CLJ-1845  had
>> the intended effect.
>>
>> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") (apply
>> f args
>> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
>> "user$eval1241$fn__1242$fn__1243@1c857e6"]
>> user=> (load)
>> "patched"
>> nil
>> user=> (require 'clojure.core :reload)
>> nil
>> user=> (require 'clojure.tools.analyzer :reload)
>> nil
>> user=> (require 'clojure.tools.analyzer :reload-all)
>> nil
>>
>> I was expected "patched" to be printed with each call to `load` via
>> `require`.
>>
>> Do others observe this also?
>>
>> Thanks,
>> Ambrose
>>
>> --
> 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: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

Wait, how does the compiler know that *clojure-version* isn't a function?

On Fri, Nov 20, 2015 at 10:01 AM, Nicola Mometto 
wrote:

> *clojure-version* is not a function, it's not affected by direct linking
>
> > On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> >
> > I'm missing something, alter-var-root'ing *clojure-version* works just
> fine when calling (clojure-version).
> >
> > (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> > (clojure-version)
> > ;=> "1.8.0-patched"
> >
> > Thanks,
> > Ambrose
> >
> > On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> > I don't think CLJ-1845 had the intended effect.
> >
> > user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched")
> (apply f args
> > #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> > user=> (load)
> > "patched"
> > nil
> > user=> (require 'clojure.core :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload)
> > nil
> > user=> (require 'clojure.tools.analyzer :reload-all)
> > nil
> >
> > I was expected "patched" to be printed with each call to `load` via
> `require`.
> >
> > Do others observe this also?
> >
> > Thanks,
> > Ambrose
> >
> >
> > On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller 
> wrote:
> > Clojure 1.8.0-RC2 is now available. This build is a "release candidate"!
> We would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems.
> >
> > Try it via
> >   • Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
> >   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> > Below are the changes since 1.8.0-RC1. See the full 1.8 change log here:
> https://github.com/clojure/clojure/blob/master/changes.md.
> >   • CLJ-1846 Fix VerifyError when primitive type hints are
> incorrect. These cases now throw compiler errors.
> >   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int
> (foo))
> >   • In this example, foo returns a long but is type hinted
> (incorrectly) as an int. This case will now throw a compilation error. The
> correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
> >   • CLJ-1825 Fix compilation errors on direct linking of anonymous
> recursive functions
> >
> > --
> > 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.
>
> --
> 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, 

Re: [ANN] Clojure 1.8.0-RC2

[Alex Miller]

I reopened the ticket. You can hold on the patch - I think we're going to 
make another change that will affect what the patch will be.


On Friday, November 20, 2015 at 9:29:43 AM UTC-6, Ambrose Bonnaire-Sergeant 
wrote:
>
> I was going to reopen the ticket and create/test a patch. Does that work 
> for you?
>
> On Fri, Nov 20, 2015 at 10:22 AM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
>
>> Alex,
>>
>> That sounds correct.
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Fri, Nov 20, 2015 at 10:10 AM, Alex Miller  
>> wrote:
>>
>>> I see the same and I suspect it's because of the forward declare.  :(
>>>
>>>
>>> On Friday, November 20, 2015 at 12:25:28 AM UTC-6, Ambrose 
>>> Bonnaire-Sergeant wrote:

 I don't think CLJ-1845  
 had the intended effect.

 user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched") 
 (apply f args
 #object[user$eval1241$fn__1242$fn__1243 0x1c857e6 
 "user$eval1241$fn__1242$fn__1243@1c857e6"]
 user=> (load)
 "patched"
 nil
 user=> (require 'clojure.core :reload)
 nil
 user=> (require 'clojure.tools.analyzer :reload)
 nil
 user=> (require 'clojure.tools.analyzer :reload-all)
 nil

 I was expected "patched" to be printed with each call to `load` via 
 `require`.

 Do others observe this also?

 Thanks,
 Ambrose

 -- 
>>> 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: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

I was going to reopen the ticket and create/test a patch. Does that work
for you?

On Fri, Nov 20, 2015 at 10:22 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> Alex,
>
> That sounds correct.
>
> Thanks,
> Ambrose
>
>
> On Fri, Nov 20, 2015 at 10:10 AM, Alex Miller  wrote:
>
>> I see the same and I suspect it's because of the forward declare.  :(
>>
>>
>> On Friday, November 20, 2015 at 12:25:28 AM UTC-6, Ambrose
>> Bonnaire-Sergeant wrote:
>>>
>>> I don't think CLJ-1845 
>>> had the intended effect.
>>>
>>> user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched")
>>> (apply f args
>>> #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
>>> "user$eval1241$fn__1242$fn__1243@1c857e6"]
>>> user=> (load)
>>> "patched"
>>> nil
>>> user=> (require 'clojure.core :reload)
>>> nil
>>> user=> (require 'clojure.tools.analyzer :reload)
>>> nil
>>> user=> (require 'clojure.tools.analyzer :reload-all)
>>> nil
>>>
>>> I was expected "patched" to be printed with each call to `load` via
>>> `require`.
>>>
>>> Do others observe this also?
>>>
>>> Thanks,
>>> Ambrose
>>>
>>> --
>> 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: [ANN] Clojure 1.8.0-RC2

[Ambrose Bonnaire-Sergeant]

Aha, thanks!

On Fri, Nov 20, 2015 at 10:35 AM, Nicola Mometto 
wrote:

> It doesn't, but direct linking only affects invocations
>
>
> > On 20 Nov 2015, at 15:21, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> >
> > Wait, how does the compiler know that *clojure-version* isn't a function?
> >
> > On Fri, Nov 20, 2015 at 10:01 AM, Nicola Mometto 
> wrote:
> > *clojure-version* is not a function, it's not affected by direct linking
> >
> > > On 20 Nov 2015, at 14:56, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> > >
> > > I'm missing something, alter-var-root'ing *clojure-version* works just
> fine when calling (clojure-version).
> > >
> > > (alter-var-root #'*clojure-version* assoc :qualifier "patched")
> > > (clojure-version)
> > > ;=> "1.8.0-patched"
> > >
> > > Thanks,
> > > Ambrose
> > >
> > > On Fri, Nov 20, 2015 at 1:24 AM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> > > I don't think CLJ-1845 had the intended effect.
> > >
> > > user=> (alter-var-root #'load (fn [f] (fn [& args] (prn "patched")
> (apply f args
> > > #object[user$eval1241$fn__1242$fn__1243 0x1c857e6
> "user$eval1241$fn__1242$fn__1243@1c857e6"]
> > > user=> (load)
> > > "patched"
> > > nil
> > > user=> (require 'clojure.core :reload)
> > > nil
> > > user=> (require 'clojure.tools.analyzer :reload)
> > > nil
> > > user=> (require 'clojure.tools.analyzer :reload-all)
> > > nil
> > >
> > > I was expected "patched" to be printed with each call to `load` via
> `require`.
> > >
> > > Do others observe this also?
> > >
> > > Thanks,
> > > Ambrose
> > >
> > >
> > > On Mon, Nov 16, 2015 at 9:32 AM, Alex Miller 
> wrote:
> > > Clojure 1.8.0-RC2 is now available. This build is a "release
> candidate"! We would appreciate any and all testing you can do on your own
> libraries or internal projects to find problems.
> > >
> > > Try it via
> > >   • Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC2
> > >   • Leiningen: [org.clojure/clojure "1.8.0-RC2"]
> > > Below are the changes since 1.8.0-RC1. See the full 1.8 change log
> here: https://github.com/clojure/clojure/blob/master/changes.md.
> > >   • CLJ-1846 Fix VerifyError when primitive type hints are
> incorrect. These cases now throw compiler errors.
> > >   • Example: (defn foo ^long [] 1)  (Integer/bitCount ^int
> (foo))
> > >   • In this example, foo returns a long but is type hinted
> (incorrectly) as an int. This case will now throw a compilation error. The
> correct way to do this is with a cast:  (Integer/bitCount (int (foo)))
> > >   • CLJ-1825 Fix compilation errors on direct linking of anonymous
> recursive functions
> > >
> > > --
> > > 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.
> >
> > --
> > 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 

Re: [ANN] lein-virgil, a plugin for mixed Clojure/Java development

[Gerrit Jansen van Vuuren]

really cool!, I definitely have use for this. gone are the days I change, 
reload repl, test :)

On Thursday, 19 November 2015 07:02:17 UTC+1, Zach Tellman wrote:
>
> It's been an uncomfortably long time since I released a new library, so 
> here we go.  This plugin solves a problem that has endlessly bothered me 
> (and hopefully a number of other people which is greater than zero), which 
> is that changing any Java files in a project requires completely reloading 
> the REPL session.  But no longer: https://github.com/ztellman/virgil. 
>  This project, named for everyone's favorite psychopomp, leverages the 
> compiler APIs within the JDK to live-reload the classes without a bit of 
> fuss.
>
> This code works for me, and will probably work for most simple use cases, 
> but I wouldn't be surprised if there are some more complex cases that don't 
> work perfectly.  Bug reports are welcome.
>

-- 
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: Poor parallelization performance across 18 cores (but not 4)

[David Iba]

Andy: Heh, glad to hear that I'm not the only one facing this issue, and I 
appreciate the encouragement since it's been kicking my ass the past week 
:)  On the bright side, as someone coming from more of a math background, 
this has forced me to learn a lot about how cpus/threads/memory/etc. work!

Herwig: I just got a chance to look through that thread you linked - sounds 
very very similar to what I'm encountering!

Niels: Glad to hear you're able to replicate the behavior.  I was also 
using claypoole's unordered pmap myself but excluded it in my code examples 
for simplicity :)  One thing to note that's tricky about benchmarking with 
hyperthreading enabled is that for fully CPU-bound jobs that don't share 
any cache and whatnot, if you're using all virtual-cores (8 in your case), 
a 2X slowdown would be expected.  Furthermore, if you launch less than the 
number of vCPUs available, it's possible that both threads get assigned to 
the same vCPU and thus again might run in 2X the time.  I noticed this 
seemed to happen more when the threads were spawned from the same java 
process (probably b/c it's presumed they can share cache) as opposed to 
separate processes.  So IMO the best way to test in this setting (without 
disabling HT) is to max out the vCPUs and compare against the expected 2X 
slowdown.

I think the "multiple threads allocating simultaneously" hypothesis makes 
the most sense so far.  This TLAB setting is interesting and I'll 
definitely give adjusting that a try - is setting the jvm option 
"-XX:+MinTLABSize" (like in the stackoverflow link Andy posted) the best 
way to go about this?

On Friday, November 20, 2015 at 5:53:42 PM UTC+9, Niels van Klaveren wrote:
>
> For what it's worth, here's the code I've been using while experimenting 
> along with this at home.
>
> Basically, it's a for loop over a collection of functions and a collection 
> of core counts, running a fixed number of tasks.
> So every function it can step up from running f on one core n times to f 
> on x cores one time. I use com.climate/claypoole's unordered pmap, which 
> gives a nice abstraction over spawning futures.
>
> Included are two function sets: summation and key assoc (since the 
> cross-comparison used in the OP bugged me a bit)
> Suggestions for alterations are welcome, but tests I ran seem to show that 
> all variants of the functions slow down considerably the more it is run in 
> parallel. (2-3x overhead compared to a single core run).
>
> Granted, I only could test this on a 4 core (8 hyperthreading) machine.
>
> Thursday, November 19, 2015 at 9:58:47 PM UTC+1, Andy Fingerhut wrote:
>>
>> David:
>>
>> No new suggestions to add right now.  Herwig's suggestion that it could 
>> be the Java allocator has some evidence for it given your results.  I'm not 
>> sure whether this StackOverflow Q on TLAB is fully accurate, but it may 
>> provide some useful info:
>>
>>
>> http://stackoverflow.com/questions/26351243/allocations-in-new-tlab-vs-allocations-outside-tlab
>>
>> I mainly wanted to give you a virtual high-five, kudos, and thank-you 
>> thank-you thank-you thank-you thank-you for taking the time to run these 
>> experiments.  Similar performance issues with many threads in the same JVM 
>> on a many-core machine have come up before in the past, and so far I don't 
>> know if anyone has gotten to the bottom of it yet.
>>
>> Andy
>>
>>
>> On Wed, Nov 18, 2015 at 10:36 PM, David Iba  wrote:
>>
>>> OK, have a few updates to report:
>>>
>>>- Oracle vs OpenJDK did not make a difference
>>>- Whenever I run N>1 threads calling any of these functions with 
>>>swap/vswap, there is some overhead compared to running 18 separate 
>>>single-run processes in parallel.  This overhead seems to increase as N 
>>>increases.
>>>- For both swap and vswap, the function timings from running 18 
>>>   futures (from one JVM) show about 1.5X the time from running 18 
>>> separate 
>>>   JVM processes.
>>>   - For the swap version (f2), very often a few of the calls would 
>>>   go rogue and take around 3X the time of the others.
>>>  - this did not happen for the vswap version of f2.
>>>   - Running 9 processes with 2 f2-calling threads each was maybe 4% 
>>>slower than 18 processes of 1.
>>>- Running 4 processes with 4 f2-calling threads each was mostly the 
>>>same speed as the 18x1, but there were a couple of those rogue threads 
>>> that 
>>>took 2-3X the time of the others.
>>>
>>> Any ideas?
>>>
>>> On Thursday, November 19, 2015 at 1:08:14 AM UTC+9, David Iba wrote:

 No worries.  Thanks, I'll give that a try as well!

 On Thursday, November 19, 2015 at 1:04:04 AM UTC+9, tbc++ wrote:
>
> Oh, then I completely mis-understood the problem at hand here. If 
> that's the case then do the following:
>
> Change "atom" to "volatile!" and "swap!" to "vswap!". See if that 
> changes anything. 
>

Clojure Objects

[William la Forge]

Code as data is the mantra. Functions and closures as data. So why not 
objects as data? What I propose is nothing new, but perhaps a new style.

Making objects from map structures is simple enough in Clojure. And easy 
enough to put functions in a map. So why not closures? A closure in a map 
is a lot like an object method, hmm?

I found clojure components to be inspirational. But as light-weight as they 
are, components are still too heavy-weight to be objects. But a simple map 
seems ideal. And with only a map instead of a record or deftype, 
composition is simplicity itself. But the key idea here comes from clojure 
components: contents of the map should be configuration parameters or 
architecture, but not state. Put state in an atom and then (optionally) put 
the atom in the map. But once an object is formed, the contents of the map 
should not change. There should be no need to update a reference to this 
map.

Below is what I am calling a Clojure Object. Like a Java object, the method 
holds both data and methods (closures). Note that, because we are using 
closures, local data can be accessed without having to be put in the map. 
For example, the file-channel variable is not accessed via the map and need 
not have been added to the map.

Bill

(ns aatree.db-file
  (:require [clojure.tools.logging :as log])
  (:import (java.nio.channels FileChannel)
   (java.nio.file OpenOption StandardOpenOption)))

(defn db-file-open
  ([file opts]
(db-file-open (assoc opts :db-file file)))
  ([opts]
(if (not (:db-file opts))
  (throw (Exception. "missing :db-file option")))
   (let [file (:db-file opts)
 ^FileChannel file-channel
 (FileChannel/open (.toPath file)
   (into-array OpenOption
   [StandardOpenOption/CREATE
StandardOpenOption/READ
StandardOpenOption/WRITE]))
 opts (assoc opts :db-file-channel file-channel)
 opts (assoc opts
:db-close
(fn []
  (try
(.close file-channel)
(catch Exception e
  (log/warn e "exception on close of db-file")))
  (dissoc opts :db-file-channel)))
 opts (assoc opts
:db-file-empty?
(fn []
  (= 0 (.size file-channel
 opts (assoc opts
:db-file-read
(fn [byte-buffer position]
  (.read file-channel byte-buffer position)))
 opts (assoc opts
:db-file-write
(fn [byte-buffer position]
  (.write file-channel byte-buffer position)))
 opts (assoc opts
:db-file-write-root
(fn [byte-buffer position]
  (.force file-channel true)
  (.write file-channel byte-buffer position)
  (.force file-channel true)))
 opts (assoc opts
:db-file-force
(fn []
  (.force file-channel true)))]
 opts)))

-- 
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: Clojure Objects

[William la Forge]

The advantage of maps over records is if I have 3 objects as maps I can
easily munge them into a single map. But if I have 3 objects as records, I
loose that option. OK, I can nest records inside each other but it is not
the same. With objects as maps I've got something closer to mixins. But not
type based.

Hmm. Guess the mixins thing is the real advantage. But mixins into objects
rather than extending a type with functions.

Now I did find this:

Function maps are maps of the keywordized method names to ordinary fns

   - this facilitates easy reuse of existing fns and maps, for code
   reuse/mixins without derivation or composition


The above was taken from http://clojure.org/protocols
where it was talking about extend.

It is very similar. But it is more about extending the polymorphic methods.
While I'm talking about extending an object. And aggregating in additional
data as well as methods.


On Sat, Nov 21, 2015 at 12:29 AM, Timothy Baldridge 
wrote:

> You might want to read up on records and protocols in clojure. This is
> pretty much the use case for which they were designed.
>
> Timothy
>
> On Friday, November 20, 2015, William la Forge 
> wrote:
>
>> You can tell I'm still new to clojure. The composition should have been
>> written like this:
>>
>> (-> opts (db-file-open) (db-cache-start) etc)
>>
>> --
>> 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.
>>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/N-UG4jh8FDY/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Clojure Objects

[William la Forge]

James,

The advantages of one style over another are often subtle. And indeed, a 
single object written this way has no real advantage. Poor choice, but it 
was the only code I have written in this way so far. The addition of 
closures only occurred to me while writing this piece of code.

I included the file-channel in the map more on principle than anything 
else. Opinionated Clojure does not try to encapsulate the way Java does, or 
such has been my impression anyway. I do sometimes encapsulate when I want 
the API to be clearer, but otherwise not.

The reason for having this "type of object" at all is that I was going to 
have 3 copies of the same code. Which I find to be a bad thing.

One thing I left out was that in aatree.core I have functions which call 
the "object methods". These functions are implemented like this: 

(defn do-something [arg1 arg2 opts] ((:do-something opts) arg1 arg2))

This gives me a lot of decoupling. opts then is the "object" map. But it 
can be a munged together map of lots of key/value pairs from a lot of 
different "types of objects". Composition goes something like this in its 
simplest form:

(opts -> (db-file-open) (db-cache-open) etc)

I end up composing a lot of things richly but with simplicity. Being new to 
Clojure, I am fascinated by all this. And as I add more and more 
capabilities, it looks like everything stays quite stable--which is exactly 
the opposite of my experience in working with Java objects.

Bill

-- 
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: Clojure Objects

[William la Forge]

Timothy,

I've been thinking about this a bit more and I see that you can supply data 
via a function in a function map that is part of extend. And while self 
reference between the various parts of a composite can get awkward, you can 
always revert to a function to complete that self-reference the same way I 
do with my core functions which have no knowledge of the implementations 
involved, except that you may be forced to do reflection.

I think the approach I am proposing is simpler both in that it avoids some 
of the boiler plate (thought I'd never say that about Clojure!) and 
completely bypasses the need for reflection. Within a composite (where opts 
is the name of the composed map) you can easily call any "method" like 
this: ((:some-method opts) arg1 arg2) without worrying about the order in 
which things are defined--one of the big weaknesses of Clojure compared to 
Java. Of course, now there is even less type checking that even the little 
that Clojure normally provides. But again, you can always define simple 
functions so that you don't end up invoking closures all over the place via 
(:method-key opts).

In any case, I'm having fun. And while the approach is not the fastest, I 
seem to be producing rock-solid stable code. Which for me is a great big 
plus!

-- 
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: Clojure Objects

[Timothy Baldridge]

You might want to read up on records and protocols in clojure. This is
pretty much the use case for which they were designed.

Timothy

On Friday, November 20, 2015, William la Forge  wrote:

> You can tell I'm still new to clojure. The composition should have been
> written like this:
>
> (-> opts (db-file-open) (db-cache-start) etc)
>
> --
> 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.
>


-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Clojure Objects

[William la Forge]

You can tell I'm still new to clojure. The composition should have been 
written like this:

(-> opts (db-file-open) (db-cache-start) etc)

-- 
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: Clojure Objects

[William la Forge]

Oh! Some minor edits. Which can be found 
here: https://github.com/laforge49/aatree/wiki/Clojure-Objects

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