Re: Adding up numbers, quickly

This is a case where I would definitely recommend using core.matrix / vectorz-clj (let [a (array :vectorz (range 1000)) b (array :vectorz (range 1000 2000))] (criterium/quick-bench (esum (sub a b => Execution time mean : 2.266914 µs Or it's even faster if you notice that you c

Re: Adding up numbers, quickly

Thanks @Mikera. I had a look at using core.matrix, but what I couldn't figure out is how to quickly get the data into core.matrix form. For instance, if I take my PersistentList of Doubles from the example then getting it into a vectors array takes: (criterium/quick-bench (array :vectorz a)) E

Re: Testing existing java code with clojure tests from ant / gradle

I wrote cljunit (https://github.com/mikera/cljunit) to address precisely this problem. cljunit lets you run any clojure.test tests using a simple JUnit test wrapper. This means you get Eclipse integration etc. for free, and it can integrate nicely with any build tools that have JUnit support.

Re: Adding up numbers, quickly

On Thursday, 16 October 2014 18:04:39 UTC+8, Jony Hudson wrote: > > Thanks @Mikera. I had a look at using core.matrix, but what I couldn't > figure out is how to quickly get the data into core.matrix form. For > instance, if I take my PersistentList of Doubles from the example then > getting it

Re: Testing existing java code with clojure tests from ant / gradle

Hi, that looks really nice, exactly what I need. I just wonder, how do you integrate the clojure source code into your projects? For example, using gradle, is it enough to have a src/test/clj folder and include the clojure jar in the gradle build as a dependency? How did you do that? Best Regar

Re: [ANN] Quickie 0.3.5

Congrats on publishing the tool! Just to clarify - this isn't quite a parallel test runner. You're just testing the namespaces in parallel. Consider the case where you have 5 namespaces, 4 of which have a single test in them, and one of which has 100 tests in it. Assume all tests have two as

java.jdbc - as-arrays? - unique column names

Do you use `:as-arrays? true` with java.jdbc to return result sets as a sequence of arrays (rather than the default sequence of maps)? Does the forced uniqueness of column names (in the first array returned) cause you problems? Ragnar Dahlen has proposed an enhancement that would allow that uni

I am looking for Clojure job

Hi, I am looking for job. Detailed resume is here . My github username is eldargab (Clojure work is mostly under dar-clojure organization

Re: A proposal for an alternative implementation of clojure.core/transduce

Am Mittwoch, 15. Oktober 2014 18:34:39 UTC+2 schrieb Daniel James: > > [...] > In my proposal above, nothing is changing about the fact that transducers > transform reducing functions to new reducing functions. The simple change > is to use the reducing function that is produced by a transformati

Modelling in Clojure

Hello Clojure people, First up, apologies because this is going to be a long message. Howver, if you do have the time to read and respond, then I would be extremely grateful! Recently I've decided to give Clojure a proper go. Over the past year or so I've paid it a bit of attention: I've read

Re: Modelling in Clojure

Hi Tom, Clojure views software architecture in a fundamentally different way to object orientated languages. In some areas, Clojure best practice is diametrically opposite to OOP best practice. One of the key ideas of OOP is encapsulating data, but Clojure entirely rejects this. In Clojure, raw d

Namespace circular dependencies

Hi all, I'm a little confused about circular namespace dependencies and what is allowed and not allowed. My understanding was that Clojure did not permit cycles in the namespace dependency graph. I dimly recall seeing an error about this at some point and I had seen code in e.g. tools.namespace wh

Re: Modelling in Clojure

On Thu, Oct 16, 2014 at 3:49 PM, James Reeves wrote: > > {:name "Alice", :email "al...@example.com"} > > At this point, stop. You have your data model. > > > I think that coming from OO, the most disconcerting piece of Clojure's philosophy is that it is relatively rare in Clojure to publish a

Re: Modelling in Clojure

On Oct 16, 2014, at 5:08 PM, Mark Engelberg wrote: > But let's say later you decide you want your data model to be {:first-name > "Alice", :last-name "Beasley", :email "al...@example.com"}, and you want to > change name to be a computed value that concatenates first and last names -- > this is

Re: Modelling in Clojure

On 17 October 2014 01:08, Mark Engelberg wrote: > > But let's say later you decide you want your data model to be {:first-name > "Alice", :last-name "Beasley", :email "al...@example.com"}, and you want > to change name to be a computed value that concatenates first and last > names -- this is goin

Re: A proposal for an alternative implementation of clojure.core/transduce

On Thursday, October 16, 2014 1:54:03 AM UTC-4, Michael van Acken wrote: > > >> This is a change I am interested in as well. Just yesterday I was bitten > by the fact that in > the 3-arity case the init value of transduce defaults to (f) instead of > ((xform > f)): > > While experimenting I wa

Re: Modelling in Clojure

> > Sure, that's the theory behind encapsulation, but I'm not convinced there > are many cases in practice where the API can remain consistent while the > data changes. > > I'm not, either. Models that have little or no abstraction --basically aggregates of related items-- end up having API

Re: Modelling in Clojure

I am new to clojure. My question how to handle version if we expose data directly as api, any schema change will break the api which may impact third party users. On Friday, 17 October 2014 15:23:10 UTC+11, Armando Blancas wrote: > > Sure, that's the theory behind encapsulation, but I'm not conv

Re: Modelling in Clojure

Every programming language is a (somewhat) unique approach to programming. So they all have their ways. Java is best expressed using Java best practices. Python is best expressed using Python best practices. Of course Clojure too is best expressed using Clojure best practices. Having said that; I

Re: Modelling in Clojure

Right, my point wasn't just about "data change", it was more specifically about the addition or change of "computed fields". In Clojure, non-computed fields are usually accessed directly by keyword, whereas computed fields require an actual API. This difference in access style complicates things

Re: Modelling in Clojure

On Fri, Oct 17, 2014 at 12:47 PM, Rui Yang wrote: > I am new to clojure. > > My question how to handle version if we expose data directly as api, any > schema change will break the api which may impact third party users. > You can't protect the consumers of your API. You publish your new API and

Re: Namespace circular dependencies

> So, I'm confused. I'm not sure what is allowed and under what circumstances, > and I'm not sure what I should be validating here. Zach very reasonably > argued that Clojure clearly permits this since Manifold works, but I'm not > sure if this is just a happy accident. Looking at the clojure.co

Re: A proposal for an alternative implementation of clojure.core/transduce

Am Freitag, 17. Oktober 2014 04:02:52 UTC+2 schrieb Daniel James: > > Hi Michael, > > I’m glad you are in favor of this change; however, and with tongue firmly > in cheek, you’ve taken a beautiful thing and corrupted it, which I can’t > condone. ;) > > Let me offer an explanation as to why I half