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

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 endles

Re: Poor parallelization performance across 18 cores (but not 4)

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

Re: Data visualization workshops post-mortem

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

Re: [ANN] pex, a powerful PEG parsing library

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

Any chance of core.logic getting extended with probKanren?

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

Re: Any chance of core.logic getting extended with probKanren?

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 >

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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]

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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>

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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 functi

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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

Re: [ANN] Clojure 1.8.0-RC2

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

Clojure Objects

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

Re: Clojure Objects

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

Re: Clojure Objects

What's the benefit to writing code like this? The only thing I could possibly see as being considered an advantage is that it encapsulates the file channel, but you've exposed that via a key anyway. - James On 21 November 2015 at 02:54, William la Forge wrote: > Code as data is the mantra. Fun

Re: Clojure Objects

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 includ

Re: Clojure Objects

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 No

Re: Clojure Objects

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

Re: Clojure Objects

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 ty

Re: Clojure Objects

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 th