[ANN] Convex - A Clojure-inspired Lisp for the Internet of Value

[Mikera]

Convex is an open, decentralised platform for the Internet of Value - you 
can use it to create secure digital assets and implement applications 
involving secure value exchange using smart contracts.

You can test it out with the live REPL, documentation and sandbox at our 
developer site:

https://convex.world

The native smart contract language is Convex Lisp - a new language heavily 
inspired by Clojure but built from the ground up to support decentralised 
applications and interactive online development. Some notable features:

- Immutable, persistent data structures throughout. In fact - the entire 
global state of the Convex Virtual Machine (CVM) is a single persistent 
data structure.
- Every user account gets its own independent namespace with REPL control 
(access secured with Ed25519 digital signatures)
- Fully autonomous Actors executing smart contracts (can be used to 
implement digital assets, or potentially entire decentralised autonomous 
organisations)
- Fully online development environment including runtime, libraries and 
compiler built into the decentralised network - no extra toolchains 
required!
- All the usual power of Lisp: macros, functional programming etc.
- Syntax and language idioms heavily inspired by Clojure

Currently this is a public alpha release - we would love to get feedback 
and ideas from the Clojure community as we develop towards our production 
launch. We run a public discord server for those interested in joining the 
discussions or getting more involved:

https://discord.gg/vBeh2S8

Convex is backed by the non-profit Convex Foundation, dedicated to creating 
a powerful open network for the Internet of Value. If you are interested in 
creating an open, fair, sustainable and equitable solution for value 
exchange in the digital economy of tomorrow we would welcome your support.

Best regards,

  Mike and the Convex Team

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/c29019df-b199-4b90-9920-0856c66c5ad2n%40googlegroups.com.

Re: Migrating nREPL out of Clojure Contrib

[Mikera]

Why is the EPL a problem? It is pretty much the standard in the Clojure 
ecosystem, even for non-core libraries. As long as you keep future 
contributions under the EPL, surely you can just fork and drop the CLA 
requirement?

FWIW, I've been using nREPL for a "Clojure-like" experimental language and 
it has been awesome so far (see https://github.com/mikera/enchant). Thanks 
for the great work!


On Tuesday, 18 July 2017 20:48:15 UTC+8, Chas Emerick wrote:
>
> Hi all,
>
> I've been approached many, many times over the years (and more frequently 
> since the development and inclusion of socket-repl) about the potential of 
> moving nREPL[1] out of clojure contrib…either back to its original 
> location[2], or under one of the various Clojure community organizations. 
> I've generally demurred or ghosted on these suggestions, sometimes out of a 
> lack of time/attention, and often out of just not wanting to stir the pot. 
> The pace of them has quickened somewhat lately though, and I'd like to put 
> the whole topic to bed and hopefully get the project to a better footing in 
> the process.
>
> First, to stipulate a few things:
>
>1. nREPL is an essential bit of infrastructure in Clojure tooling
>2. On balance, I have neglected the project in recent years, to the 
>detriment of all of the users of the aforementioned tooling.
>3. On balance, contributors and potential contributors have been less 
>involved (or turned away entirely) because of the well-known friction that 
>comes with the contrib process and requirements. (tbh, this is a factor in 
>#2, though not the majority)
>4. No one (least of all me) would object to nREPL having its 
>contribution process managed through github or gitlab.
>
> So basically everyone wants nREPL to be a "regular" project, and subject 
> to and beneficiary of the same expectations as 99.9% of all of the other 
> OSS projects we all interact with daily. How does that happen?
>
>
> The only routes AFAICT are:
>
>1. to fork back elsewhere, which would require keeping the EPL license 
>and copyright assignment of the current codebase. Literally anyone can do 
>this at any time, without any coordination with anyone else.
>2. for me to reboot the project. This would not be difficult given I 
>"own" the vast majority of the project's commits. This would allow for the 
>elimination of the copyright assignment, and potentially a different 
>license (I'm partial to MPLv2, but we'll see). If this route is taken, we 
>could set up a project issue where the other contributors of nontrivial 
>patches could agree (or not) to the reconstitution of their code w/o the 
>copyright assignment, etc.
>
> In either case, this "new" nREPL project's artifacts would end up being 
> distributed under a different maven groupId (`com.cemerick`, if I'm to 
> continue deploying, etc). The clojure-contrib nREPL project remain, and any 
> releases that are done from it after the fork/reboot would continue to be 
> under the `org.clojure` coordinates. Downstream projects need to choose 
> whether or not to change dependencies; I'd expect the vast majority of 
> future motion to gravitate to the reboot, but that's just speculation at 
> this point.
>
>
> I would like to hear *here* (no more private mails, please! :-) from any 
> nREPL users, contributors, etc. As much as possible, I would like *not *to 
> debate/re-litigate the merits of contrib and its process here; let's focus 
> on what steps will yield the best outcome for nREPL and its stakeholders.
>
>
> Thanks!
>
>
> - Chas
>
> [1] https://github.com/clojure/tools.nrepl/
> [2] https://github.com/cemerick/nrepl
>

-- 
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: Cases of `RT/canSeq`

[Mikera]

One of the things that JVMs can do is create a small cache for the most 
recently seen classes in instanceof checks. I believe both OpenJDK and the 
Oracle JVM do this.

So if you check for both ISeq and Seqable, you may find that you get twice 
as many classes cached, and therefore see a performance benefit. Of course 
this is implementation dependant so YMMV.

On Friday, 19 May 2017 11:28:27 UTC+8, Tianxiang Xiong wrote:
>
> But if something is `ISeq`, it's `Seqable`, so checking for `Seqable` 
> alone should be sufficient. 
>
> Am I missing something here? Is there a performance performance benefit of 
> checking for `ISeq` *and* `Seqable` that I'm not aware of?
>
> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:
>>
>> Clearly not necessary from a functional perspective.
>>
>> However I believe the ordering of these tests will affect JVM 
>> optimisations. You want to test the common/fast cases first. And the JVM 
>> does some clever things with caching most recently used lookups, which will 
>> again behave differently if you test things in different orders.
>>
>> Benchmarking on realistic workloads would typically be required to 
>> determine the optimal order.
>>
>> FWIW I find it odd that the null check is third. This is extremely fast 
>> (certainly faster than instance checks) and is a very common case given the 
>> amount of nil usage in idiomatic Clojure code (as an empty seq), so I would 
>> probably put it first.
>>
>> On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:
>>>
>>> Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_ 
>>> `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?
>>>
>>> static public boolean canSeq(Object coll){
>>> return coll instanceof ISeq
>>> || coll instanceof Seqable
>>> || coll == null
>>> || coll instanceof Iterable
>>> || coll.getClass().isArray()
>>> || coll instanceof CharSequence
>>> || coll instanceof Map;
>>> }
>>>
>>>

-- 
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: Cases of `RT/canSeq`

[Mikera]

Clearly not necessary from a functional perspective.

However I believe the ordering of these tests will affect JVM 
optimisations. You want to test the common/fast cases first. And the JVM 
does some clever things with caching most recently used lookups, which will 
again behave differently if you test things in different orders.

Benchmarking on realistic workloads would typically be required to 
determine the optimal order.

FWIW I find it odd that the null check is third. This is extremely fast 
(certainly faster than instance checks) and is a very common case given the 
amount of nil usage in idiomatic Clojure code (as an empty seq), so I would 
probably put it first.

On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:
>
> Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_ 
> `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?
>
> static public boolean canSeq(Object coll){
> return coll instanceof ISeq
> || coll instanceof Seqable
> || coll == null
> || coll instanceof Iterable
> || coll.getClass().isArray()
> || coll instanceof CharSequence
> || coll instanceof Map;
> }
>
>

-- 
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 and RFC] Bifurcan: impure functional data strucures

[Mikera]

Looks cool! I'm going to mine this for ideas and potentially use it. FWIW 
I've also been implementing some Java functional data structures for my 
language design experiments. 

If anyone is interested happy to share code, my own motivations were:
- I wanted decent persistent Lists, Sets, Maps for language experiments 
without pulling in the whole of Clojure as a dependency
- I care about some operations that are not very efficient in Clojure 
(sublists and concatenation especially)
- It's actually quite a fun challenge writing functional data structures

I have the same annoyance that it isn't easy to play nicely with Clojure 
code unless you implement the Clojure interfaces (IPersistentVector etc.). 
It would be nice if Clojure used protocols so you could extend 
interoperability to arbitrary types, but I can't see any way that is going 
to happen and it probably isn't a good idea overall for performance 
reasons. 

So I agree the practical way forward would be to write Clojure "wrappers" 
that extend IPersistentVector etc. if you want to use bifurcan in Clojure.



On Tuesday, 28 March 2017 00:51:46 UTC+8, Zach Tellman wrote:
>
> This is a slightly irregular announcement, because it's not for a Clojure 
> library.  Rather, it's for a library written purely in Java: 
> https://github.com/lacuna/bifurcan.
>
> This is a collection of mutable and immutable data structures, designed to 
> address some of my personal frustrations with what's available in the 
> Clojure and Java ecosystems.  Notably, they have pluggable equality 
> semantics, so while they *can* use Clojure's expensive hash and equality 
> checks, they don't *have* to.  They also provide high-performance mutable 
> variants of the data structure which share an API with their immutable 
> cousins.  
>
> I'm posting it here to ask for people's thoughts on how, if at all, this 
> should be exposed as a Clojure library.  It would be simple to simply wrap 
> them in the Clojure interfaces and make them behave identically to 
> Clojure's own data structures, but that kind of obviates the point. 
>  However, creating an entirely new set of accessors means that we can't 
> leverage Clojure's standard library.
>
> It's possible that I'm alone in my frustrations, and no Clojure wrapper is 
> necessary.  But if this does solve a problem you have, I'd like to hear 
> more about what it is, and how you think Bifurcan might help.  Please feel 
> free to reply here, or to grab me at Clojure/West and talk about it there.
>
> Thanks in advance,
> Zach
>

-- 
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: Combinatorics partitions that preserves adjacency?

[Mikera]

Filtering and sorting each partition is going to be pretty expensive! If 
the list is long you will be discarding most of the results anyway.

I found a recursive way to do this that is fairly efficient, by observing 
that you either want to join two adjacent elements together in a partition 
or split at this point.

(defn ordered-partitions 
 ([[fst & more]]
   (ordered-partitions (list [fst]) more))
 ([init more]  
   (if (empty? more)
  (list init)
  (let [more-partitions (ordered-partitions more)
start (butlast init)
join (last init)]
(concat
  (map #(concat init %) more-partitions)
  (map #(let [[more-fst & more-more] %]
  (concat start (list (vec (concat join more-fst))) 
more-more)) more-partitions))

(time (count (ordered-partitions (range 20
"Elapsed time: 822.939961 msecs"
524288

i.e. you can compute half a million partitions in less than a second, which 
I think is decent?

On Thursday, 16 March 2017 11:35:55 UTC+8, Paul Gowder wrote:
>
> Hi everyone, 
>
> Does anyone know of a straightforward way to get something like 
> clojure.math/combinatorics/partitions that works more like partition in the 
> core library, that is, that only selects partitions with adjacent elements?
>
> In other words, right now this is the problem:
>
> (require '[clojure.math.combinatorics :as c])
> (c/partitions [:a :b :c] :min 2)
>
> => (([:a :b] [:c]) ([:a :c] [:b]) ([:a] [:b :c]) ([:a] [:b] [:c]))
>
> But that ([:a :c] [:b]) there in the second position isn't a proper 
> partition because :a and :c aren't adjacent in the original vector.  
>
> I feel like there's got to be a standard, canonical solution for this, or 
> some existing sequence or combinatorics function with a funny name that 
> just returns (([a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c])) in this 
> situation.  I just don't know it... 
>
> The best I can come up with is kind of a hackish workaround that only 
> works when the original vector is sorted, namely, flattening all the 
> partitions and testing to see whether they are sorted too, i.e.: 
>
> (require '[clojure.math.combinatorics :as c])
>
> (defn test-fn [part]
>   (let [f (flatten part)]
> (= f (sort f
>
> (filter test-fn (c/partitions [:a :b :c] :min 2))
>
> => (([:a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c]))  ; Yay! :-)
>
> And that works, but, as noted, only when the original vector is sorted. 
>  What if someone wanted to preserve adjacencies in an unsorted vector?
>
> All thoughts appreciated, thanks!
>
> Cheers,
>
> -Paul
>
>

-- 
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: Making a Java class implement ILookup

[Mikera]

You might want to try implementing a small wrapper class that implements 
ILookup.

Then you can do something like:

(:keyword (MyWrapper. my-obj))

Prefer composition over inheritance, etc.

On Wednesday, 1 March 2017 04:12:06 UTC+8, Ernesto Garcia wrote:
>
> Hi all,
>
> I am using Java class that acts as a map, but doesn't implement Map. (It's 
> not in my hands to modify it).
>
> I would like to do the usual lookup code:
> (:keyword my-obj)
>
> I can't make the class extend ILookup, as ILookup is an interface, not a 
> protocol.
>
> Do you know of any other way to achieve this?
> Wouldn't it be better if ILookup were a protocol?
>
> Thanks,
> Ernesto
>

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

[Mikera]

On Tuesday, 6 December 2016 10:47:42 UTC+8, James Reeves wrote:
>
> On 6 December 2016 at 01:28,  wrote:
>>
>> And the error messages are not good.
>>
>> So I was wondering: Is this a philosophical thing? Or is it an effort 
>> thing? And if it is an effort thing, is there some sort of plan for what 
>> effort to put in? And if so, can I help by closing tickets?
>>
>
> This is an issue that's been discussed often.
>
> The fundamental problem is that in a dynamically typed language, good 
> error messages are often at odds with runtime performance. The more checks 
> we add to catch specific scenarios, or to provide more descriptive 
> scenarios, the more performance tends to be impacted.
>
>
Runtime checks are clearly bad for performance, but this kind of thing can 
typically be done at compile time, with no runtime cost.

>

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

[Mikera]

Given recent events, I advise caution when it comes to relying on votes to 
make important decisions.

On Tuesday, 8 November 2016 23:33:43 UTC+8, Alex Miller wrote:
>
> In the spirit of the US election today, I thought I would mention voting 
> on Clojure tickets. Clojure manages bugs and enhancement requests in JIRA 
> . Anyone can create a JIRA account 
>  and vote on open 
> tickets in the system (no contributor agreement 
>  is required to vote).
>
> In the core team, we look at votes on tickets to be aware of what the 
> community cares about and as one input to the order in which tickets are 
> considered. However, the most-voted tickets in the system have fewer than 
> 30 votes and I suspect that there are many thousands of people with 
> opinions about which of these tickets are important.
>
> If you'd like to see the lists of the highest voted tickets in the system, 
> you can do so in these reports:
> - Highest voted defects 
> 
> - Highest voted enhancements 
> 
>
> Andy Fingerhut also has a weighted voting report 
> 
>  
> that updates about once a week. This show a different perspective - I'm not 
> sure which is more useful but I look at both.
>
> If you'd like to learn more about the process:
> - Overview  of 
> contribution links 
> - JIRA workflow 
> - A blog I wrote describing the process 
>  
>
> A few examples of highly voted issues that have been included in 1.9 so 
> far:
> - CLJ-1224  Records do not 
> cache hash like normal maps (21 votes)
> - CLJ-1298  Add more type 
> predicate fns to core (18 votes)
> - CLJ-1744  Unused 
> destructured local not cleared, causes memory leak (17 votes)
> - CLJ-1242  = on sorted 
> collections with different key types incorrectly throws (7 votes)
> - CLJ-401    Add seqable? 
> predicate (7 votes)
>
> Alex
>
>
>
>

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

[Mikera]

In my moments of insanity / hammock time I've toyed with making a typed 
variant of Clojure. Somewhat inspired by core.typed, but I feel that to be 
effective a type system needs to be deeply integrated with the compiler and 
standard library, not just a standalone tool.

Types would themselves be an abstraction, supporting the following 
operations:
- Intersection with another type (N or And)
- Union with another type (U or Or)
- Checking is a type is a subclass of another type (extends?)
- Checking if a value conforms to the type (instance?)

Abstractions themselves would be possible to define as types, so you could 
have the Seqable type:

(defabstraction Seqable )

(defn process-sequence [^Seqable s]
  (let [things (seq s)]   ;; guaranteed to work by type system
 ...)

Java classes would conform to the Type abstraction, so you can still use 
Clojure-style Java type hints for interop.

Anything passed to a typed parameter would be verified to be either:
- A valid subtype, in which case everything is OK
- Something that cannot be a valid subtype, in which case you get a 
compiler error
- A potentially valid value (either untyped or an intersecting type), in 
which case a runtime check is inserted (and maybe an optional warning...)

Types could be parameterised, so you can have types like:

(ListOf Integer)
(Nullable String)
(ArrayOfShape [10 10])
(ExactValue "Foo")
(Or String Integer)

Occurrence typing would mean that stuff like the following is valid:

(defn foo [^(Nullable (Or String Integer)) x]
  (cond 
 (nil? x) 
 (Integer? x) (+ x 5)   ;; valid addition, can prove it is an 
Integer
 (String? x) (.charAt x 0);; no type hint required, can prove it 
must be a non-null string
 ))

Since branching on type is a common idiom, it would also support type-based 
overloading of functions:

(defn foo
  ([^Null x] )
  ([^Integer x] )
  ([^String x] ))

Untyped code would look still look like regular Clojure. Types would always 
be optional.



On Sunday, 6 November 2016 07:14:39 UTC+8, Didier wrote:
>
> Spectrum (https://github.com/arohner/spectrum) seems quite interesting. I 
> haven't tried spec yet, but form quick glance, it looks just as annoying as 
> typed clojure to use.
>
> I think I'm imagining something simpler though. Say a system that just 
> used already existing Clojure type hints, and performed compile time checks 
> about to whatever level is possible given the provided annotation.
>
> So say I did:
>
> (def ^int something "test")
>
> This would fail at compile time.
>
> Similarly:
>
> (def ^String something "test")
> (inc something)
>
> It would fail at compile time.
>
> Or:
>
> (defn inc2 [^Long a]
>   (inc (inc a)))
> (inc2 1.80)
>
> Would also fail.
>
> And hopefully this:
>
> (defn ^Long inc2 [^Long a]
>   (inc (inc a)))
> (def temp ["test", 2.48])
> (map inc2 temp)
>
> Would also fail. Because the type checker would infer that the vector has 
> String or Double as type, and inc2 expects none of these.
>
> Or:
>
> (conj ["a", "b"] "c")
>
> would still work.
>
> (conj ^Vec ["a", "b"] 10)
>
> would fail.
>
> Now I don't know, maybe this is too simple, not really useful, or maybe 
> its non trivial to implement. But I feel just small type checks like that 
> could be useful, and they wouldn't be too burdening.
>
> On Saturday, 15 October 2016 15:14:08 UTC-7, Didier wrote:
>>
>> I know a lot of people like to say how unhelpful Java like static typing 
>> is, and only more powerful type systems of the ML family add value, but 
>> I've been wondering recently if for Clojure it wouldn't make more sense to 
>> simply extend the type hints to enable an optional Java like static typing 
>> schemI the.
>>
>> It is my understanding that ML style static typing is incredibly 
>> difficult to add properly and without compromise to a dynamic language. 
>> That doing so limits the scope of type inference, rendering the task of 
>> adding type info more tedious then in ML languages themselves.
>>
>> ML style static typing provide enhanced safety grantees, but seem to add 
>> too much complexity to Clojure to be practical. What about a Java like 
>> static typing scheme though?
>>
>> I haven't found in practice that the safety of Clojure was an issue, as 
>> the REPL workflow tend to promote quite a lot of testing. So I'm not too 
>> worried about needing the state of the art of provable correctness for my 
>> programs. What has been a biggest cause of issue to me was refactoring and 
>> shared code base across a team. Those last two use cases are actually 
>> pretty well handled by Java like static type checking. Is it a powerful 
>> type checker, not really, but it enables most trivial type errors to be 
>> caught early, and it allows easier integration points for other devs to 
>> follow, as well as documentation for functions, better tools support and 
>> easier refactoring, while also enabling performance optimizations.
>>
>> I have limited 

Re: comp and partial vs ->>

[Mikera]

On Thursday, 27 October 2016 22:56:42 UTC+8, JHacks wrote:
>
> I have some confusion about how the function `comp` works, especially as
> compared to the threading macro `->>`.
>
> From the book *Clojure Programming* (pages 70-71 of Chapter 2: Functional
> Programming), the following two functions are described as functionally
> equivalent:
>
> (def camel->keyword
>   (comp keyword
> str/join
> (partial interpose \-)
> (partial map str/lower-case)
> #(str/split % #"(?<=[a-z])(?=[A-Z])")))
>
> (defn camel->keyword*
>   [s]
>   (->> (str/split s #"(?<=[a-z])(?=[A-Z])")
>(map str/lower-case)
>(interpose \-)
>str/join
>keyword))
>
> Why does the first function, `camel->keyword`, need to use `partial` with 
> the
> `map` and `interpose` functions? The second function, `camel->keyword*`, 
> does
> not need to use `partial`.
>

I actually prefer the following style to both of the above:

(defn camel->keyword*
 [s]
 (let [words (str/split s #"(?<=[a-z])(?=[A-Z])")
   lc-words (map str/lower-case words)
   joined-words (str/join "-" lc-words)]
   (keyword joined-words))) 

Reasons:
- Your intermediate values are explicitly named, which helps to make the 
code self-describing
- It is (marginally) more performant than the composed function case (I 
think exactly matches the threading macro)
- You can use the intermediate values in more than one of the following 
steps if needed, which can make refactoring / adding new features easier
- The ordering is (to me) more logical as it describes the stages of the 
transformation in the order they are performed.
- It is less "Clever". Clever code is generally bad for maintenance and 
future understanding. Both functional composition and the 
code-transformation effects of the threading macro represent conceptual 
overhead that you don't need to pay (in this case).


 

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Mikera]

On Friday, 7 October 2016 08:25:31 UTC+8, kovasb wrote:
>
> On Thu, Oct 6, 2016 at 4:46 PM, Dragan Djuric  > wrote:
>  
>
>> s more harm than good. I prefer to give users one Ford model T, than let 
>> them choose between 20 different horse carriages. And, if they can even 
>> choose the color, provided that their choice is black :)
>>
>
> Thanks the for the comments, which I largely agree with. 
>
> I understand your design philosophy and agree its a useful point in the 
> space to have. 
>
> One question:
>
> Is it possible to feed Neanderthal's matrix representation (the underlying 
> bytes) into one of these other libraries, to obtain 
> computations Neanderthal doesn't support? 
>
> My situation: Neanderthal covers some of the algorithms I'd like to 
> implement. It looks easier to get started with and understand than the 
> alternatives. But down the line I'll likely want to do convolution, 
> sigmoid, the typical Neural Network layers. Note, I don't care about 
> 'tensors' exactly; the bookkeeping to simulate a tensor can be automated, 
> but the fundamental operations cannot. So there is a question of whether to 
> just absorb the learning curve and shortcomings of these more general 
> libraries rather than to risk switching horses midstream. 
>
> I imagine I'm not alone in this.. if there was a straightforward story for 
> how to interop Neanderthal when necessary with some more general library 
> that would be powerful. Unfortunately I'm not sufficiently expert to 
> evaluate which of the choices would be most pragmatic and how to pull it 
> off. 
>

I'm hoping to work with Dragan to get core.matrix integration working with 
Neanderthal, now that Windows support is finally arriving. This would get 
you a few big advantages:
1. Neanderthal could be used as a drop-in replacement for other core.matrix 
implementations if it fits your use case
2. You would get extra core.matrix features (additional operations, higher 
dimensional array operations, type conversion, broadcasting etc. 
essentially for free)
3. We minimise the risk of fragmentation in the Clojure numerical ecosystem 
:-)
4. We could use Neanderthal as a optional backend for libraries like 
Incanter or our new NN libraries without any major re-engineering

I'm certainly willing to contribute a fully compliant core.matrix 
implementation for Neanderthal (will take me a couple of days as long as 
the Windows build works smoothly). This might not optimise all of the 
possible operations, but should get high performance in most of the common 
use cases.

Hope you will all support this effort!
 

>  

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Mikera]

Hi Dragan,

We have things working quite well (including stuff like cuDNN integration 
for convolution networks on the GPU). We also have all of the standard 
stuff (many different layer types, dropout, noise function, regularisation 
etc.). However I think it still needs a bunch of work before we stabilise 
on the core API.

Opening the source is not entirely my decision, this is a collaboration 
with the Thinktopic folks (Jeff Rose et al.). I'm personally in favour of 
being pretty open about this stuff but I do think that it would be a 
mistake if people build too much stuff on top of the wrong API which is 
likely to happen if we release prematurely.

Things I'm paricularly keen to have nailed down in particular before we go 
public:
1. A tensorflow-like DAG model that allows arbitrary operations to be 
composed compose into (possibly nested) graphs
2. Enough abstraction that different backends work (ClojureScript, 
Pure-JVM, Native, GPU etc.). core.matrix provides most of this, but there 
are still some deep-learning specific operations that need tuning and can 
be quite backend-specific, e.g. cuDNN has some specific ways of dealing 
with mini-batches which we need to get right. I'd love to try Neanderthal 
with this too if we can get the core.matrix integration working.
3. Decent, stable APIs for the algorithms that you typically want to run 
for mini-batch training, cross-validation etc.
4. Pluggable gradient optimisation methods (we currently have stuff like 
ADADELTA, SDG, ADAM etc. but would like to make sure this is sufficiently 
general to support any optimisation method)

I'll have a talk with the Thinktopic folks and see if we can come up with a 
timeline for a open source release. In the meantime, if anyone is *really* 
interested then we may be able to arrange collaboration on a private basis.




On Thursday, 6 October 2016 20:44:11 UTC+8, Dragan Djuric wrote:
>
> Hey Mike,
>
> A friend asked me if I know of any good (usable) deep learning libraries 
> for Clojure. I remembered you had some earlier neural networks library that 
> was at least OK for experimenting, but seems abandoned for your current 
> work in a similar domain. A bit of digging lead me to this post.
>
> I understand that this library may not be completely ready yet, but I 
> wandered wheter now you were able to give a better estimation of where it 
> stands in comparison with other DL offerings, like what deeplearning4j guys 
> are doing, or even with the established non-Java libraries such as Theano, 
> Torch, Caffe, and TensorFlow. What is the chance of you releasing it even 
> if it is not 100% ready? 
>
> I get the reluctance to commit to a certain API, but I don't think 
> everyone will rush to commit their code to the API you release anyway, and 
> the open development will certainly help both the (potential) users and 
> your team (by returning free testing & feedback).
>
>
> On Tuesday, May 31, 2016 at 7:17:35 AM UTC+2, Mikera wrote:
>>
>> I've been working with a number of collaborators on a deep learning 
>> library for Clojure. 
>>
>> Some key features:
>> - An abstract API for key machine learning functionality
>> - Ability to declare graphs / stacks of operations (somewhat analogous to 
>> tensorflow)
>> - Support for multiple underlying implementations (ClojureScript, JVM, 
>> CPU, GPU)
>> - Integration with core.matrix for N-dimensional data processing
>>
>> We intend to release as open source. We haven't released yet because we 
>> want to get the API right first but it is looking very promising.
>>
>> On Tuesday, 31 May 2016 02:34:41 UTC+8, kovasb wrote:
>>>
>>> Anyone seriously working on deep learning with Clojure?
>>>
>>> I'm working with Torch at the day job, and have done work integrating 
>>> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what 
>>> needs to be done. A bit too much to bite off on my own in my spare time. 
>>>
>>> So is anyone out there familiar enough with these tools to have a 
>>> sensible conversation of what could be done in Clojure?
>>>
>>> The main question on my mind is: what level of abstraction would be 
>>> useful?
>>>
>>> All the existing tools have several layers of abstraction. In 
>>> Tensorflow, at the bottom theres the DAG of operations, and above that a 
>>> high-level library of python constructs to build the DAG (and now of course 
>>> libraries going higher still). In Torch, its more complicated: there's the 
>>> excellent tensor library at the bottom; the NN modules that are widely 
>>> used; and various non-orthogonal libraries and modules stack on top of 
>>> those. 
>>>
>>> 

Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Mikera]

I've been working with a number of collaborators on a deep learning library 
for Clojure. 

Some key features:
- An abstract API for key machine learning functionality
- Ability to declare graphs / stacks of operations (somewhat analogous to 
tensorflow)
- Support for multiple underlying implementations (ClojureScript, JVM, CPU, 
GPU)
- Integration with core.matrix for N-dimensional data processing

We intend to release as open source. We haven't released yet because we 
want to get the API right first but it is looking very promising.

On Tuesday, 31 May 2016 02:34:41 UTC+8, kovasb wrote:
>
> Anyone seriously working on deep learning with Clojure?
>
> I'm working with Torch at the day job, and have done work integrating 
> Tensorflow into Clojure, so I'm fairly familiar with the challenges of what 
> needs to be done. A bit too much to bite off on my own in my spare time. 
>
> So is anyone out there familiar enough with these tools to have a sensible 
> conversation of what could be done in Clojure?
>
> The main question on my mind is: what level of abstraction would be useful?
>
> All the existing tools have several layers of abstraction. In Tensorflow, 
> at the bottom theres the DAG of operations, and above that a high-level 
> library of python constructs to build the DAG (and now of course libraries 
> going higher still). In Torch, its more complicated: there's the excellent 
> tensor library at the bottom; the NN modules that are widely used; and 
> various non-orthogonal libraries and modules stack on top of those. 
>
> One could try to integrate at the bottom layer, and then re-invent the 
> layers above that in Clojure. Or one could try to integrate at the higher 
> layers, which is more complicated, but gives more leverage from the 
> existing ecosystem. 
>
> Any thoughts?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
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: clj-spss 0.0.2 - a lightweight SPSS file reader for Clojure

[Mikera]

Hi all,

In the (unlikely?) event that someone else also faces the problem of 
reading / importing SPSS files within Clojure, I've released a small 
library that does exactly that.

https://github.com/mikera/clj-spss

Nothing fancy here: it is mostly just a Clojure wrapper for some old Open 
Data Foundation code.

Contributions / improvements welcome as always.

  Mike.

-- 
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: Porting Clojure to Native Platforms

[Mikera]

I would definitely second Tim's points. The JVM is very hard to beat once 
you factor in the GC and JIT requirements.

Worth noting that persistent data structures with structural sharing are 
used pretty much ubiquitously in Clojure and that these are *exactly* the 
kinds of data structures that benefit most from GC. 

An alternative scheme such as reference counting would perform extremely 
badly in comparison because structural sharing implies a *lot* of reference 
count updates, and writes to reference counts scattered across memory are 
expensive on modern machines (especially in concurrent situations). 

On Tuesday, 26 April 2016 04:50:45 UTC+8, tbc++ wrote:
>
> As someone who has spent a fair amount of time playing around with such 
> things, I'd have to say people vastly misjudge the raw speed you get from 
> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
> general use, dynamic language that is not based on the JVM and comes even 
> close to the speed of Clojure. 
>
> A LLVM/C++/RPython based version of Clojure would on a good day come in at 
> about 1/10 the speed of Clojure on the JVM for general use cases. 
>
>
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  > wrote:
>
>> > The main motivation would be performance gains.
>>
>> blah? so many impedance mismatches and layers of indirection that i
>> don't think it will gain much? i mean, it would probably be better to
>> spend time tuning gc parameters or something. just a rant / guess.
>> e.g. robovm is for some use cases perfectly fine performance wise
>> believe it or not.
>>
>> --
>> 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.
>>
>
>
>
> -- 
> “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 IoT?

[Mikera]

There are two companies I'm involved with that use Clojure for IoT:

Kemuri - http://www.kemurisense.com/
Silverline - http://silverline.mobi/

Both are in the space of assisted living for the elderly, Clojure is used 
mainly for the sensor data ingestion and analysis.

On Monday, 11 April 2016 00:07:23 UTC+8, rob wrote:
>
> An IOT company called Sensity based in the south bay was heavily 
> recruiting for their Clojure and Erlang stack last year.
> On Apr 10, 2016 2:12 AM, "Mimmo Cosenza"  > wrote:
>
>> Hi Gregg,
>> my team is working for a customer which is making a very intersting IoT 
>> device (named Linfa).
>> We use cljs on a nodejs running on a microcontroller, clojure to 
>> implement microservices on the back-end and cljs/react.js/react.native to 
>> implement the app to control the iot device from any platform (browser, 
>> desktop, iOS, Android). 
>> Here is a link of its picture:
>>
>> https://drive.google.com/open?id=0B6VEMmGF1rzZVGZLa0RCcHgtck0
>>
>> mimmo
>>
>> On 10 Apr 2016, at 00:38, Gregg Reynolds > > wrote:
>>
>> A very general question : is anybody other than me working with Clojure 
>> for IoT stuff?
>>
>> -- 
>> 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 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: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Mikera]

On Monday, 14 March 2016 18:21:15 UTC+8, Dragan Djuric wrote:
>
>
>>>
>> There is a set of BLAS-like API functions in core.matrix already. See: 
>> https://github.com/mikera/core.matrix/blob/develop/src/main/clojure/clojure/core/matrix/blas.cljc
>>
>
> GitHub history says they were added 7 days ago. Nevermind that they just 
> delegate, so the only BLAS-y thing is the 4 method names taken out  of 
> Neanderthal (BLAS has a bit more stuff than that), but why you reinvented 
> the wheel instead just creating core.matrix (or vectorz) implementation of 
> Neanderthal's API? 
>

The core.matrix API has been around a lot longer than Neanderthal, and 
presents an abstract API rather than being tied to any specific 
implementations. If there is any wheel-reinventing going on, it is 
Neanderthal :-)

The correct way to build these things is IMHO:
- User / library code depends on an implementation-agnostic abstraction 
(i.e. the core.matrix API)
- The user optionally specifies an implementation (or makes do with the 
default)
- The underlying implementation handles how that call gets executed 
(Neanderthal, vectorz-clj, Clatrix etc.)

It wouldn't make any sense to have core.matrix (the abstraction) depend on 
Neanderthal (the implementation) because that defeats the whole purpose of 
an implementation-agnostic API. And a hard dependency would rule the whole 
library out for any users who can't even run that particular implementation 
(including myself, due to lack of Windows support).
 

>  
>
>> Having said that, I don't personally think the BLAS API is a particularly 
>> good fit for Clojure (it depends on mutability, and I think it is a pretty 
>> clumsy design by modern API standards). But if you simply want to copy the 
>> syntax, it's certainly trivial to do in core.matrix.
>>
>
> If you look at Neanderthal's API you'll see that I took a great care to 
> make it fit into Clojure, which I think I succeeded. 
> Regarding mutability:
> 1) Neanderthal provides both mutable and pure functions
> 2) Trying to do numeric computing without mutability (and primitives) for 
> anything than toy problems is... well, sometimes it is better to plant a 
> Sequoia seed, wait for the tree to grow, cut it, make an abacus and compute 
> with it... 
>

Right, I agree you need both mutable and immutable options. That's why 
core.matrix provides both. But why are you pushing a new API rather than 
adopting the core.matrix one (or giving me PRs if you think it could be 
improved?)

2) I disagree with. Most real world data science is about data manipulation 
and transformation, not raw computation. 1% of people need to optimise the 
hell out of a specific algorithm for a specific use case, 99% just want 
convenient tools and the ability to get an answer "fast enough".
 

>
>
>> An important point to note is that they don't do the same thing at all: 
>> core.matrix is an API providing an general purpose array programming 
>> abstraction with pluggable implementation support. Neanderthal is a 
>> specific implementation tied to native BLAS/ATLAS. They should ideally work 
>> in harmony, not be seen as alternatives.
>>
>
> * Neanderthal has an agnostic api and it is not in any way tied to 
> BLAS/ATLAS *
> Neanderthal also has pluggable implementation support - and it already 
> provides two high-performance implementations that elegantly unify two very 
> different *hardware* platforms: CPU and GPU. And it does it quite 
> transparently (more about that can be read here: 
> http://neanderthal.uncomplicate.org/articles/tutorial_opencl.html)
>

OK, so you agree you want an abstract API with pluggable implementations... 
but that is exactly what the core.matrix API does!

But if you only offer native and GPU dependencies then you aren't really 
offering an agnostic API. Won't even work on my machine. could you add 
Windows support? Maybe you want to add pure JVM implementations as well? 
And for Clojure data structures? What about ClojureScript support? Sparse 
arrays? Oh, could you maybe support n-dimensional arrays? Datasets?

If you go down that path you will simply be reinventing core.matrix, and 
you will eventually come to realise why a lot of the core.matrix design 
decisions actually make sense. Believe me, I've been down that road :-)
 

>
>> Neanderthal is more closely comparable to Vectorz, which *is* a matrix 
>> implementation (and I think it matches or beats Neanderthal in performance 
>> for virtually every operation *apart* from large matrix multiplication for 
>> which ATLAS is obviously fantastic for).
>>
>  
> You think without having tried that. I tried that, and *Neanderthal is 
> faster for virtually *ALL* operations, even 1D. Yesterday I did a quick 
> measure of asum (1

Re: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Mikera]

On Monday, 14 March 2016 13:49:36 UTC+8, Leif wrote:
>
>
> I also think the core.matrix crusade is unnecessary.  Here are my two 
> cents:
>
> 1. No one jumps in every time someone writes a new web routing library 
> saying "No!  You'll fragment the clojure
> web routing community!  Use compojure!"  I think we should pick and 
> choose based on our needs.
>

Hi Leif,

Absolutely agree that we should choose libraries based on our needs.

However there is huge value to having standard abstractions that everyone 
can code to if you want to create an ecosystem of compatible tools. 
Consider these examples:
a) The Clojure "sequence" abstraction
b) The Ring handler / middleware abstraction
c) Transducers

All of these present a common abstraction that can support many different 
implementations and use cases. core.matrix does exactly the same for array 
programming.

If someone reinvented transducers with a completely different API / syntax 
but a clever new implementation (e.g. for distributed parallel processing 
or something like that) then people would quite rightly say things like 
"why don't you just make that a transducer? It would be much better if we 
can use that with all our existing transducer code". 

All I'm really asking is that people use the core.matrix abstractions when 
doing numerical work, and we can all interoperate much more smoothly. For 
individual end users it isn't so much of an issue, however it is a *big* 
problem if tools / higher level libraries start adopting different APIs and 
representations. Then it isn't "choose the right library for your needs" 
but "choose between different competing stacks of libraries that don't 
interoperate". That's when fragmentation becomes a real problem. If you are 
interested in this topic, it is well worth reading about "The Curse of 
Lisp".

2. We should build on well-tested, stable APIs, true.  Dragan has built on 
> top of BLAS (basically stable for over
> 35 years) and LAPACK (25-35 years depending on how you count).
>

There is a set of BLAS-like API functions in core.matrix already. 
See: 
https://github.com/mikera/core.matrix/blob/develop/src/main/clojure/clojure/core/matrix/blas.cljc

Having said that, I don't personally think the BLAS API is a particularly 
good fit for Clojure (it depends on mutability, and I think it is a pretty 
clumsy design by modern API standards). But if you simply want to copy the 
syntax, it's certainly trivial to do in core.matrix.

Note that none of these (core.matrix blas namespace, Neanderthal) are 
actually real BLAS (which is a native API that you can't call directly from 
Clojure). They are all just wrappers that adopt a similar syntax and 
delegate to the underlying implementation after a bit of parameter 
manipulation / data marshalling.
 

> 3. Dragan has no need or desire to implement the core.matrix API, but I'm 
> sure someone that wants native speed
> *and* compatibility with core.matrix will do so when the need arises.
> 4. If you want accessibility to the widest possible community of numerical 
> programmers, bear in mind that most
> of them aren't clojure or even java programmers anyway.  BLAS and 
> LAPACK are the way to make them feel
> at home.  Pure-java numerical programming is a rather strange 
> cul-de-sac community already.
> 5. Numerical programming is a field where you, unfortunately, have to drop 
> layers of abstraction more
> frequently than other fields.  I'd rather drop down into ATLAS than 
> < matrix class here>>.
>
> In short, having two libraries that do the same thing is not a problem, 
> and if it becomes a problem, I think we as a community can deal with it 
> fairly quickly.
>
> --Leif
>

An important point to note is that they don't do the same thing at all: 
core.matrix is an API providing an general purpose array programming 
abstraction with pluggable implementation support. Neanderthal is a 
specific implementation tied to native BLAS/ATLAS. They should ideally work 
in harmony, not be seen as alternatives.

Neanderthal is more closely comparable to Vectorz, which *is* a matrix 
implementation (and I think it matches or beats Neanderthal in performance 
for virtually every operation *apart* from large matrix multiplication for 
which ATLAS is obviously fantastic for).

Ultimately, I'm trying to encourage people to work towards an ecosystem for 
Clojure(Script) that rivals the Python or R ecosystems. It's still going to 
take a fair bit of work to get there, but is perfectly feasible. I think we 
need:
a) core.matrix as a common abstraction that people can use to develop user 
level code as well as higher level libraries (environments like Incanter, 
data processing tools, deep learning etc.)
b) A really good pure JVM implementation (currently Vectorz / vectorz-clj 

Re: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)

[Mikera]

On Friday, 11 March 2016 09:21:09 UTC+8, arthur.ma...@gmail.com wrote:
>
> Renjin and Spark's dataframes are not going to be easily removed from 
> their respective codebases, as far as my brief perusal of the source can 
> tell. I agree that N-D DataFrames would be a good addition to the 
> ecosystem, similar to the goals of Python's xarray (xarray.pydata.org). 
> However, it is not a priority for myself as of this time. Thanks for 
> pointing out the DataSet proposal. I'll take a look at that later.
>
> On a slightly related note, where is the best place to ask core.matrix 
> questions? I have some small questions about sparse matrix support in 
> core.matrix, and what sparse formats are implemented.
>

There is the Numerical Clojure group: 
https://groups.google.com/forum/#!forum/numerical-clojure

For quick questions / discussion many people are on the #data-science 
channel in the Clojure slack  

Or you can just file a core.matrix issue with a question: I'm usually quite 
responsive with these and they may serve as a reference for future people 
who run into similar questions: 
https://github.com/mikera/core.matrix/issues

-- 
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: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Mikera]

On Monday, 14 March 2016 08:19:25 UTC+8, Dragan Djuric wrote:
>
> On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:
>
>> It would be great if Neanderthal simply implemented the core.matrix 
>> protocols, then people could use it as a core.matrix implementation for 
>> situations where it makes sense. I really think it is an architectural 
>> dead-end for Neanderthal to develop a separate API. You'll simply get less 
>> users for Neanderthal and fragment the Clojure library ecosystem which 
>> doesn't help anyone.
>>
>
> Mike, I explained that many times in detail what's wrong with core.matrix, 
> and I think it is a bit funny that you jump in every time Neanderthal is 
> mentioned with the same dreams about core.matrix, without even trying 
> Neanderthal, or discussing the issues that I raised. Every time your answer 
> is that core.matrix is fine for *YOUR* use cases. That's fine with me and I 
> support your choice, but core.matrix fell short for *MY* use cases, and 
> after detailed inspection I decided it was unsalvageable. If I thought I 
> could improve it, it would have been easier for me to do that than to spend 
> my time fiddling with JNI and GPU minutes.
>

It would be great if you could explain this statement. What *precisely* are 
your technical objections?

Please remember that core.matrix is primarily intended as an API, not a 
matrix implementation itself. The point is that different matrix 
implementations can implement the standard protocols, and users and library 
writers can then code to a standard API while maintaining flexibility to 
use the implementation that best suits their use cases (of which 
Neanderthal could certainly be one).
 

>
> I understand your emotions about core.matrix, and I empathize with you. I 
> support your contributions to Clojure open-source space, and am glad if 
> core.matrix is a fine solution for a number of people. Please also 
> understand that it is not a solution to every problem, and that it can also 
> be an obstacle, when it fells short in a challenge.
>

Interested to understand that statement. Please let me know what use cases 
you think don't work for core.matrix. A lot of people have worked on the 
API to make it suitable for a large class of problems, so I'm interested to 
know if there are any we have missed. 

For any point you have here, I'm happy to either:
a) Explain how it *does* work
b) Take it as an issue to address in the near future.
 

>  
>
>> In the absence of that, we'll just need to develop separate BLAS 
>> implementations for core.matrix. 
>>
>
> I support you. If you do a good job, I might even learn something now and 
> improve Neanderthal.
>  
>
>> Would be great if you could implement the core.matrix protocols and solve 
>> this issue. It really isn't much work, I'd even be happy to do it myself if 
>> Neanderthal worked on Windows (last time I tried it doesn't).
>>
>
> I am happy that it is not much work, since it will be easy for you or 
> someone else to implement it ;) Contrary to what you said on slack, I am 
> *not against it*. I said that many times. Go for it. The only thing that I 
> said is that *I* do not have time for that nor I have any use of 
> core.matrix.
>
> Regarding Windows - Neanderthal works on Windows. I know this because a 
> student of mine compiled it (he's experimenting with an alternative GPU 
> backend for Neanderthal and prefers to work on Windows). As I explained to 
> you in the issue that you raised on GitHub last year, You have to install 
> ATLAS on your machine, and Neanderthal has nothing un-Windowsy in its code. 
> There is nothing Neanderthal specific there, it is all about comiling 
> ATLAS. Follow any ATLAS or Nympu + ATLAS or R + ATLAS guide for 
> instructions. Many people did that installation, so I doubt it'd be a real 
> obstacle for you.
>

Every time I have tried it has failed on my machine. I'm probably doing 
something wrong, but it certainly isn't obvious how to fix it. Can you 
point me to a canonical guide and binary distribution that works "out of 
the box"? 

-- 
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: XOR two arrays into a third on Clojure

[Mikera]

I have a useful library for image manipulation in Clojure, you may find it 
useful:

https://github.com/mikera/imagez

New ideas / PRs gratefully received!

On Sunday, 13 March 2016 04:14:34 UTC+8, James Elliott wrote:
>
> Interesting! This is the first time I have had to drop out of Clojure for 
> performance reasons. It is not too surprising, given that I am doing 
> low-level byte bashing in a tight loop to send pixels to a display over USB 
> at sixty frames per second. But it is surprising that nothing like this has 
> happened before in building my Clojure environment for running light shows.
>
> I have created a separate Java library which I am calling Wayang, to make 
> it easy for any Java project to drive this display. Once that’s done, I may 
> add a small Clojure convenience wrapper, or I may just have Afterglow use 
> Wayang directly. https://github.com/brunchboy/wayang
>
> But first I have a bunch of Java2D integration to implement!
>
> On Thursday, March 13, 2014 at 12:26:33 AM UTC-5, Ignacio Corderi wrote:
>>
>> Hey guys, here is a huge performance problem I'm trying to figure out:
>>
>> ;; Say you have 2 data arrays sitting out there of 1 MB
>>
>> (def one-mb (byte-array (* 1024 1024))) 
>> (def another-mb (byte-array (* 1024 1024))) 
>>
>> ;; and another one that should have the byte-by-byte XOR of the previous 
>> two 
>>
>> (def out-mb (byte-array (* 1024 1024)))
>>
>> ;; question is... how do you code this guy, so that it doesn't take 
>> forever
>>
>> (defn inplace-xor [a b out]
>>   (def ln (count a))
>>   (loop [x 0]
>> (if (< x ln)
>>   (do 
>> (aset-byte out x (bit-xor (nth a x) (nth b x)))
>> (recur (+ x 1))
>> 
>>
>> ;; checking the time 
>>
>> (time (inplace-xor one-mb another-mb out-mb))
>>
>> ;; takes about ~400ms which is well... A LOT
>>
>> ;; I'm happy to receive a solution that involves calling some java 
>> library...
>>
>> Thanks in advance!
>> -Ignacio
>>
>>  
>>
>

-- 
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: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)

[Mikera]

On Friday, 11 March 2016 09:09:14 UTC+8, Dragan Djuric wrote:
>
> This is already working well for the array programming APIs (it's easy to 
>> mix and match Clojure data structures, Vectorz Java-based arrays, GPU 
>> backed arrays in computations). 
>>
>
> While we could agree to some extent on the other parts of your post but 
> the GPU part is *NOT* true: I would like you to point me to a single 
> implementation anywhere (Clojure or other) that (easily or not) mixes and 
> matches arrays in RAM and arrays on the GPU backend. It simply does not 
> work that way.
>

You misunderstand my point. Obviously, there may need to be some copying 
when you move between managed and unmanaged memory. 

But I'm not talking about that: the point is that this can happen "under 
the hood", without the user needing to do explicit conversions etc. All 
thanks to the protocol implementations, you can mix and match GPU, native 
and Java backed instances with the same API. 

core.matrix can trivially do stuff like (add! native-array java-array) for 
example.

What's not to like about that?

-- 
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: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)

[Mikera]

core.matrix maintainer here.

I think it would be great to have more work on dataframe-type support. I 
think the right strategy is as follows:
a) Make use of the core.matrix Dataset protocols where possible (or add new 
ones)
b) Create implementation(s) for these protocols for whatever back-end data 
frame implementation is being used

The beauty of core.matrix is that we *can* support multiple implementations 
without fragmentation, because the protocol based approach means that every 
implementation can use the same API. This is already working well for the 
array programming APIs (it's easy to mix and match Clojure data structures, 
Vectorz Java-based arrays, GPU backed arrays in computations). We just need 
to do the same for DataFrames.

Now: the current core.matrix Dataset API is a bit focused on 2D data 
tables, but I think it can be extended to general N-dimensional dataframe 
capability. Would be a great project for someone to take on, happy to give 
guidance and help merge in changes as needed.

I don't have a particularly strong opinion on which Dataframe 
implementations are best, but it looks like Spark and Renjin are both great 
candidates and would be very useful additions to the Clojure numerical 
ecosystem. If we do things right, they should interoperate easily with the 
core.matrix APIs, making Clojure ideal for "glue" code across such 
implementations.

On Thursday, 10 March 2016 04:57:31 UTC+8, arthur.ma...@gmail.com wrote:
>
> Is there any desire or need for a Clojure DataFrame?
>
>
> By DataFrame, I mean a structure similar to R's data.frame, and Python's 
> pandas.DataFrame.
>
> Incanter's DataSet may already be fulfilling this purpose, and if so, I'd 
> like to know if and how people are using it.
>
> From quickly researching, I see that some prior work has been done in this 
> space, such as:
>
> * https://github.com/cardillo/joinery
> * https://github.com/mattrepl/data-frame
> * 
> http://spark.apache.org/docs/latest/sql-programming-guide.html#dataframes
>
> Rather than going off and creating a competing implementation (
> https://xkcd.com/927/), I'd like to know if anyone here is actively 
> working on, or would like to work on a DataFrame and related utilities for 
> Clojure (and by extension Java)? Is it something that's sorely needed, or 
> is everybody happy with using Incanter or some other library that I'm not 
> aware of? If there's already a defacto standard out there, would anyone 
> care to please point it out?
>
> As background information:
>
> My specific use-case is in NLP and ML, where I often explore and prototype 
> in Python, but I'm then left to deal with a smattering of libraries on the 
> JVM (Mallet, Weka, Mahout, ND4J, DeepLearning4j, CoreNLP, etc.), each with 
> their own ad-hoc implementations of algorithms, matrices, and utilities for 
> reading data. It would be great to have a unified way to explore my data in 
> the Clojure REPL, and then serve the same code and models in production.
>
> I would love for Clojure to have a broadly compatible ecosystem similar to 
> Python's Numpy/Pandas/Scikit-*/Scipy/matplotlib/GenSim,etc. Core.Matrix and 
> Incanter appear to fulfill a large chunk of those roles, but I am not aware 
> if they've yet become the defacto standards in the community.
>
> Any feedback is greatly appreciated.
>

-- 
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: unable to understand the behaviour of core.matrix/emap ( Bug maybe? )

[Mikera]

Yeah, confirmed this is a bug in vectorz-clj. Indexing error meant that the 
operator was getting applied to the first row twice, instead of once to 
each row.

There is a fix and regression tests in the develop branch already, will be 
fixed in next release (hopefully today if I have time)

On Friday, 19 February 2016 08:11:17 UTC+8, Sunil Nandihalli wrote:
>
> Hi Everybody
>  There seems to be a problem with core.matrix/emap implementation for 
> vectorz implementation
>
> sunil@peacock:~/work/wnmf/clj/wnmf$ lein repl
> Clojure 1.8.0
> wnmf.core=> (def t (m/array [[10] [20]]))
> #'wnmf.core/t
> wnmf.core=> (m/pm t)
> [[10.000]
>  [20.000]]
> nil
> wnmf.core=> (m/pm (m/emap / t 10))
> [[ 0.100]
>  [20.000]]
> nil
> wnmf.core=>
>
> can somebody please clarify this?
> Thanks,
> Sunil.
>

-- 
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: A doubt about core.matrix

[Mikera]

Hi Sunil,

You are correct that the naive code will eagerly produce the full matrix 
UxV, which may be very large :-)

I think your strategy of extracting rows and columns from U and V is the 
best one. Row and column extraction for dense matrices in vectorz-clj is 
very efficient since it just uses strided vectors, as is the dot product 
operation, so you probably won't see much of a performance overhead from 
doing it this way. I wouldn't worry about the verbosity - obviously you 
should encapsulate this logic in a function if you are doing it in many 
places.

Top tip: also remember to use (non-zero-indices W) if you want to know 
which elements of the sparse matrix are non-zero without iterating over 
every element

  Mike. 

On Tuesday, 16 February 2016 23:17:52 UTC+8, Sunil Nandihalli wrote:
>
> Hi Everybody,
>  I am newbie to core.matrix .. I have the following expression
>
> W -> a large spare matrix of size MxN
> U  -> a dense matrix of size MxK
> V ->  a dense matrix of size KxN
>
> and K << (M,N)
> (require [clojure.core.matrix :as m])
>
> I want to compute (m/mul W (m/* U V))
>
> m/mul computes element-wise product
>
> m/*  computes regular matrix multiplication
>
> I want to know if the above would compute full-matrix UV .. if it does 
> then I want to know if there is an elegant way to compute the 
> spare-resultant matrix without blowing up memory in the intermediate stage
>
> I am currently just extracting the corresponding rows and columns from U 
> and V for the elements which are non-zero in W .. but that seems 
> unnecessarily verbose...
>
> I am using the vectorz implementation of core.matrix
>
> Thanks in advance.
>
> Sunil.
>

-- 
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: Scripting with Clojure / "slow" boot time

[Mikera]

Good initiative, I've filled in a response to the survey.

One thing that strikes me is that the main issue with loading time is the 
time required to transitively load and compile all the referred namespaces 
(which can be a lot in a big project...). This in turn may trigger class 
loading of Java libraries, IO as various resources are initialised etc. An 
observation is that a lot of this is often not required initially, so there 
*might* be a clever strategy to mitigate this through laziness.

This could be something like:
- When loading the current namespace, *don't* load referred namespaces (yet)
- Create lazy placeholders within vars in the current namespace for (for 
every def, defn etc.)
- Only when the placeholder is deref'd / invoked then compile the relevant 
function and pull in dependencies. 
- After first deref / invocation, replace the placeholder with the full 
compiled function / value, so that subsequent access has no overhead

This would be a pretty big change, and might break tools that make 
assumptions about order of loading of namespaces... but I think it would 
solve 90% of the boot time problems if implemented correctly.

The other potentially big win would be concurrent loading of namespaces. 
Guess you are looking at that already?



On Wednesday, 10 February 2016 02:36:43 UTC+8, Alex Miller wrote:
>
> I'm doing some research on slow Clojure boot time and would be interested 
> in collecting info about example use cases where it's been a problem for 
> people.
>
> http://goo.gl/forms/eSpn8M5FNB
>
> I'm not expecting to release the results in any formal way, mostly looking 
> to use it to pull out particular use cases and/or commonalities across 
> anecdotes so that we can work on boot time problems that matter the most 
> (and solutions likely to help the most). Any numbers you can provide would 
> be great.
>
> Alex
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: core.matrix and incanter [WAS: Re: [ldnclj] Re: Suggestions for open source contributions?]

[Mikera]

Yes, I think so. Though they should be the "raw" functionality only 
e.g. I know some of the Incanter code adds quite a bit of syntactic sugar 
which is absolutely fine but I don't think belongs in core.matrix itself. 
Hence a lot of the Incanter code should ideally have the strategy "handle 
syntactic sugar as necessary, then delegate to the underlying core.matrix 
operation(s)".

I've looked briefly at the spark RDDs / datasets and I think they are fine 
targets for core.matrix dataset implementations. I'd favour integrating the 
implementation code into existing Spark wrapper libraries, if the 
maintainers are agreeable. This would be a great project for somebody, and 
would also really help us to develop the core.matrix dataset API (which is 
a bit spartan right now).


On Friday, 5 February 2016 19:18:14 UTC+8, Bruce Durling wrote:
>
> Mike, 
>
> That sounds really useful. So things like mapping and joining should 
> be in core.matrix then? 
>
> Just contemplating some PRs and where we should be looking. 
>
> I know there was talk about hooking up core.matrix to Spark RDDs. Has 
> anyone made any progress on that? It would be nice to pitch in there 
> too. 
>
> cheers, 
> Bruce 
>
> On Fri, Feb 5, 2016 at 10:26 AM, Mikera <mike.r.an...@gmail.com 
> > wrote: 
> > Hi Bruce, 
> > 
> > My view is that the following things should be in core.matrix 
> > - Fundamental dataset and array programming operations (slicing, access, 
> > reshaping, dimension labelling etc.) 
> > - Basic numerical operations (add, matrix multiply etc.) 
> > - Matrix operations that may have different underlying implementations 
> (SVD 
> > etc.) 
> > - Protocol based support for standard implementations (Java arrays, 
> Clojure 
> > vectors etc.) 
> > 
> > The following belong in other libraries: 
> > - More sophisticated algorithms building on the fundamental operations 
> > (statistical techniques, machine learning etc.) 
> > - Anything to do with user interaction (graphing, GUIs etc.) 
> > - Tools for IO / data access etc. 
> > 
> > This is just a guideline though - happy to consider any specific 
> function on 
> > a case by case base. Probably best done via issues, so please file if 
> you 
> > have any! 
> > 
> > On Friday, 5 February 2016 03:27:47 UTC+8, Bruce Durling wrote: 
> >> 
> >> Mike, 
> >> 
> >> I've had some of my team start using incanter 1.9.0. We've found and 
> >> reported some issues and would like to contribute. Is there a good 
> >> road map somewhere of what functions should stay in incanter and what 
> >> ones should live in clojure.core.matrix.dataset? I'd like to know that 
> >> any fixes we pursue would move towards the future design of incanter. 
> >> 
> >> cheers, 
> >> Bruce 
> >> 
> >> On Thu, Feb 4, 2016 at 10:01 AM, Mikera <mike.r.an...@gmail.com> 
> wrote: 
> >> > There is the start of a dataframe-like implementation in 
> >> > clojure.core.matrix.dataset 
> >> > 
> >> > Contributions in this area (or even just vigorous testing / issue 
> >> > reporting) 
> >> > would be very welcome! 
> >> > 
> >> > On Tuesday, 2 February 2016 17:44:51 UTC+8, Gregg Reynolds wrote: 
> >> >> 
> >> >> 
> >> >> 
> >> >> On Tue, Feb 2, 2016 at 2:22 AM, Mikera <mike.r.an...@gmail.com> 
> wrote: 
> >> >>> 
> >> >>> If you are interested in data science, help with core.matrix and 
> the 
> >> >>> associated libraries is always appreciated, and we are very 
> >> >>> contributor-friendly in the numerical Clojure community. 
> >> >> 
> >> >> 
> >> >> Speaking of which,  the topic of Clojure came up on the Julia 
> mailing 
> >> >> list 
> >> >> recently.  One comment was "I suspect the biggest issue is the lack 
> of 
> >> >> a 
> >> >> good dataframes library for Clojure,..."  So something along that 
> line 
> >> >> would 
> >> >> be a good project. 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups 
> >> > "London Clojurians" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> > an 
> >> > email to london-clojuri...@googlegroups.com. 
> >> > To post to this group, s

Re: [ldnclj] Re: Suggestions for open source contributions?

[Mikera]

Hi Bruce,

My view is that the following things should be in core.matrix
- Fundamental dataset and array programming operations (slicing, access, 
reshaping, dimension labelling etc.)
- Basic numerical operations (add, matrix multiply etc.)
- Matrix operations that may have different underlying implementations (SVD 
etc.)
- Protocol based support for standard implementations (Java arrays, Clojure 
vectors etc.)

The following belong in other libraries:
- More sophisticated algorithms building on the fundamental operations 
(statistical techniques, machine learning etc.)
- Anything to do with user interaction (graphing, GUIs etc.)
- Tools for IO / data access etc.

This is just a guideline though - happy to consider any specific function 
on a case by case base. Probably best done via issues, so please file if 
you have any!

On Friday, 5 February 2016 03:27:47 UTC+8, Bruce Durling wrote:
>
> Mike, 
>
> I've had some of my team start using incanter 1.9.0. We've found and 
> reported some issues and would like to contribute. Is there a good 
> road map somewhere of what functions should stay in incanter and what 
> ones should live in clojure.core.matrix.dataset? I'd like to know that 
> any fixes we pursue would move towards the future design of incanter. 
>
> cheers, 
> Bruce 
>
> On Thu, Feb 4, 2016 at 10:01 AM, Mikera <mike.r.an...@gmail.com 
> > wrote: 
> > There is the start of a dataframe-like implementation in 
> > clojure.core.matrix.dataset 
> > 
> > Contributions in this area (or even just vigorous testing / issue 
> reporting) 
> > would be very welcome! 
> > 
> > On Tuesday, 2 February 2016 17:44:51 UTC+8, Gregg Reynolds wrote: 
> >> 
> >> 
> >> 
> >> On Tue, Feb 2, 2016 at 2:22 AM, Mikera <mike.r.an...@gmail.com> wrote: 
> >>> 
> >>> If you are interested in data science, help with core.matrix and the 
> >>> associated libraries is always appreciated, and we are very 
> >>> contributor-friendly in the numerical Clojure community. 
> >> 
> >> 
> >> Speaking of which,  the topic of Clojure came up on the Julia mailing 
> list 
> >> recently.  One comment was "I suspect the biggest issue is the lack of 
> a 
> >> good dataframes library for Clojure,..."  So something along that line 
> would 
> >> be a good project. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "London Clojurians" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to london-clojuri...@googlegroups.com . 
> > To post to this group, send email to london-c...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/london-clojurians. 
> > 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: Suggestions for open source contributions?

[Mikera]

There is the start of a dataframe-like implementation in 
clojure.core.matrix.dataset

Contributions in this area (or even just vigorous testing / issue 
reporting) would be very welcome!

On Tuesday, 2 February 2016 17:44:51 UTC+8, Gregg Reynolds wrote:
>
>
>
> On Tue, Feb 2, 2016 at 2:22 AM, Mikera <mike.r.an...@gmail.com 
> > wrote:
>
>> If you are interested in data science, help with core.matrix and the 
>> associated libraries is always appreciated, and we are very 
>> contributor-friendly in the numerical Clojure community.
>>
>
> Speaking of which,  the topic of Clojure came up on the Julia mailing 
> list 
> <https://groups.google.com/forum/#!searchin/julia-users/clojure/julia-users/vGoc8araBVQ/BM7ZOtVeAAAJ>recently.
>   
> One comment was "I suspect the biggest issue is the lack of a good 
> dataframes library for Clojure,..."  So something along that line would be 
> a good project.
>

-- 
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: Suggestions for open source contributions?

[Mikera]

If you are interested in data science, help with core.matrix and the 
associated libraries is always appreciated, and we are very 
contributor-friendly in the numerical Clojure community.

On Monday, 1 February 2016 18:51:37 UTC+8, Steven Deobald wrote:
>
> Hey folks!
>
> Today is the first day nilenso has ever had an intern on-staff. He's been 
> in the industry for a few years but he's relatively new to Clojure. We try 
> to ramp people up as slowly and supportively as possible. For interns, we 
> figure writing (and re-writing, natch) open source is the safest place to 
> start.
>
> With that context set, does anyone on the list have suggestions for 
> projects we can guide him through? We will be working with him through some 
> the standard Clojure literature over the coming months, as well as 
> providing guidance with his patches/pull-requests.
>
> We're open to any shape of project: applications, libraries, tools. If you 
> have a Clojure project you would like help with (or that you wish someone 
> would start), we would love to evaluate it as a learning opportunity.
>
> Thanks everyone!
>
> Steven Deobald -- ⌀ -- nilenso.com
>

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

[Mikera]

There is a `pow` function in core.matrix, that computes powers over whole 
arrays at the same time.

Tests / patches to improve this always welcome.

On Tuesday, 3 June 2008 16:55:15 UTC+8, Jon wrote:
>
> As I could not find a ** function in boot.clj, I wrote this one: 
>
> (defn ** 
> "nth power of x" 
> [x n] 
> (if (== n 0) 
> 1 
> (* (if (bit-test n 0) x 1) 
> (** (* x x) (bit-shift-right n 1)) ) ) ) 
>
> In my opinion, it has one weakness: It loops forever when n<0, like in 
> (** 2 -3). The reason is that (bit-shift-right -1 1) returns -1. 
> If anybody knows a faster/better Clojure power function, let me 
> know. ;-) 
>
> /Jon

-- 
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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Mikera]

I share the same unease. I haven't quite fully been able to articulate all 
the reasons, but here are the things that concern me most:

1) Completing the API for data access with the representation

This is my biggest issue. Good practice IMHO is to keep APIs abstracted 
from underlying implementation details. There are many cases where you may 
want to change the underlying data representation without changing the API 
(adding indexing functionality, changing a "stored" value to a "calculated" 
value, caching of repeated values etc.) It is *really* annoying when you 
want to change the internal representation but have the problem of breaking 
all the callers who have hard-coded assumptions about the structure.

2) Refactoring challenges

It's pretty easy to refactor Java code with modern IDEs - changing method 
names, updating all references etc. Doing this in Clojure when everything 
is represented in nested data structures is a tricky task, because you 
typically don't have the ability to catch all uses of a particular part of 
a data structure. I've lost count of the number of times I have had 
hard-to-track bugs because of changed keywords etc.

This is less of an issue in small projects, but a much bigger issue once 
you have a large project that passed complex values between subsystems.

Furthermore, given that Clojure is a dynamically typed language, you 
typically have more tests to compensate for the lack of type safety being 
enforced by the compiler. Refactoring costs become even greater when you 
need to refactor a large number of tests as well.

3) Performance

If you express everything in nested data structures, you end up paying 
significant performance overheads
a) Lack of fast type-based dispatch (you can use defrecord / protocols, but 
then you are going the way of typed records anyway... so it isn't really 
pure data)
b) Validation at runtime of deeply nested structures is expensive. You 
often have to walk the entire tree to ensure compliance with a specific 
schema
c) Inherent overheads of boxing numbers. Less of a big deal for business 
domain objects, but problematic for the data scientists among us.
d) If your data structure represents "operations" you effectively need to 
write an "interpreter" to execute these. I'd rather have fast compiled code 
:-)
e) The JVM is very good at optimising method calls / object access access 
when it knows the types. With everything as "Object"... less so. You end up 
with lots of casts and instance checks.

Don't get me wrong, I think that immutable data as values are a great thing 
overall. But I would urge caution about an ideological crusade to "data all 
the things".

On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>
> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: 
> Distributed Computing for Clojure” 
> , I'm distracted by a 
> nagging worry that we —as a community— are somehow falling into the same 
> trap as the those advocating XML in the early 2000s. That said, it's a very 
> *vague* unease, because I don’t know much about why the industry seems to 
> have rejected XML as “bad”; by the time I started programming 
> professionally there was already a consensus that XML sucked, and that 
> libraries/frameworks that relied heavily on XML configuration files were to 
> be regarded with suspicion and/or distaste.
>
> So, am I incorrect in seeing a similarity between the “data > code” 
> mentality and the rise of XML? Or, assuming there is a legitimate 
> parallel, is it perhaps unnecessary to be alarmed? Does the tendency to use 
> edn instead of XML sidestep everything that went wrong in the 2000s? Or is 
> it the case that the widespread backlash against XML threw a baby out with 
> the bathwater, forgetting the advantages of data over code?
>
> Cheers,
> Josh
>

-- 
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: Migrating from Java/Spring to Clojure

[Mikera]

On Monday, 1 February 2016 05:19:17 UTC+8, John Krasnay wrote:
>
> Hi all,
>
> I'm migrating an application from Java/Spring to Clojure and I'm searching 
> for a good, functional approach. The app exposes a REST interface using 
> compojure-api and primarily interacts with a relational database and sends 
> email.
>
> I think most people end up passing their database connection (and other 
> stateful resources as required) around to non-pure functions that do the 
> side-effectful work, while trying to push as much business logic into pure 
> functions possible. My problem with this approach is that most of my app's 
> functionality is in database interactions, so most of my functionality ends 
> up being non-pure and difficult to test. For example, to unit test my 
> functions it seems I'd have to mock my database connection.
>
> Instead of this, I'm considering an approach where my functions instead 
> return a data structure containing a description of the side-effects to be 
> performed (e.g. "insert these rows into this table", "send this email", 
> ...), and having a single non-pure function that does all the 
> side-effectful work described by the structure.
>
> From what I've read, it seems is sort of how Haskell does IO in a pure 
> functional manner, using their IO monad.
>
> Has anyone tried this sort of approach? Are there any libraries that might 
> help? Any pitfalls I might be setting myself up for?
>

I'm sure that you could get this approach to work, but it sets off some 
alarm bells in my head.

Problems you may face:

a) You are effectively developing a programming language, where your 
state-affecting code is represented in data. Clojure already does that 
why reinvent the wheel? I'm reminded of Grrenspun's tenth rule of 
programming: "Any sufficiently complicated C or Fortran program contains an 
ad hoc, informally-specified, bug-ridden, slow implementation of half of 
Common Lisp."

b) Representing operations in code seems neat, but it gets tricky when you 
have dependencies between them. What if one operation requires conditional 
execution that depends on the result of a previous operation? You'll need 
branching and control flow to handle this in a general way, which is 
non-trivial. What if one set of side effects writes to places that are 
subsequently "read" by later operations? You'll need to mock or model a 
database engine if you want to test / simulate this directly.

c) Clojure is an dynamically typed language (sadly, one of it's few 
flaws) . The lack of compiler support for type verification makes it 
harder to keep track of exactly the type of data passing through your 
deeply composed functions and data structures. Trying to represent graphs 
of operations as data as well is only likely to make things worse. Yes 
there are tools such as Schema, but they have their own cost in terms of 
runtime performance (if you use them for validation) and runtime 
complexity. It's possible to get right, but I would predict quite a lot of 
pain along the way.

I'd strongly suggest trying this the more conventional Clojure way first 
(e.g. using Stuart Sierra's component approach). This can get pretty close 
to being a nice functional style, and is very easy to test (you just need 
to mock one or two components and you are usually good). You may ultimately 
find some areas why you want to implement a DSL, but trying to write the 
whole application in this fashion from the beginning seems to me like a bit 
of a high risk strategy. 
 

-- 
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.Java-Time 0.2.0

[Mikera]

Looks awesome, I'd definitely like to use this whenever I can guarantee 
running on Java 8 or above.

Question: is there any change of having a unified time API in Clojure? That 
supports both Joda time and Java time? And works with cljs? It is a bit 
frustrating to have to hard-code to specific time libraries rather using a 
good abstraction

On Wednesday, 13 January 2016 20:29:25 UTC+8, platon...@gmail.com wrote:
>
> Hello all,
>
> I've released a Java 8 Date-Time API wrapper some time ago but never 
> bothered to make a formal announcement. So here it is: Clojure.Java-Time. 
> 
> Please, feel free to check out the readme 
>  and 
> maybe even try using it :)
>
> Dependency vector: [clojure.java-time "0.2.0"]
>
> Have fun!
>

-- 
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: building with Leiningen within Maven

[Mikera]

Thanks for sharing, this is definitely something I have been interested in.

My use case is a little more specific: I'd like to be able to run a 
Clojurescript test suite as part of a larger Maven build. Has anyone 
managed to get something like this to work?

On Monday, 28 December 2015 05:06:23 UTC, Elango wrote:
>
> Hi everyone,
> I've recently need to come up with a workaround for building a project 
> that basically entails running a Leiningen build within Maven.  
>
> I think that it will get the job done, but it's also definitely not my 
> proudest moment...  which is why I would like to know if anyone understands 
> the original problem, which has something to do with the classloader and 
> how the Clojure code gets built (by Leiningen vs. by Maven):
>
>
> http://www.elangocheran.com/blog/2015/12/compiling-a-leiningen-project-from-maven/
>
> And out of curiosity, I wonder if anyone out there has thought about 
> quietly slipping in a Leiningen build step into a Maven build?
>
> Thanks,
> Elango
>

-- 
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: [Q] default decimal of Clojure is IEEE double, not BigDecimal

[Mikera]

I personally think the current approach is right. Most people don't need 
arbitrary precision decimals, so it makes sense to have the fastest 
implementation used as the default. This also follows the "principle of 
least surprise" for people who are coming from other languages.

If someone really wants to use arbitrary precision decimals, they can ask 
for it explicitly. But it wouldn't make sense to force this (quite 
significant) overhead on people who don't want them (or don't even realise 
the difference).

On Tuesday, 22 December 2015 23:47:43 UTC, Gary Fredericks wrote:
>
> Am I missing something? I realize doubles are generally faster because of 
> hardware implementations , but that seems orthogonal from the question of 
> syntax. I've several times thought idealistically that it could be better 
> to have the syntaxes switched (to reduce the amount of accidental floating 
> point use), and the only downsides I know of are A) surprising people 
> (especially people who think they can divide 2 by 3 without thinking about 
> it), and B) needing to be more careful when you're trying to use doubles 
> for performance. Maybe you were referring to B?
>
> Of course I do realize it's *way* too late to change it now ☺.
>
> Gary
>
> On Tuesday, December 22, 2015 at 9:23:43 AM UTC-6, Alex Miller wrote:
>>
>> It's done this way for performance.
>
>

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

[Mikera]

On Thursday, 17 December 2015 14:59:37 UTC, Herwig Hochleitner wrote:
>
> Am 17.12.2015 02:35 schrieb "Mikera" <mike.r.an...@gmail.com 
> >:
>
> > 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 
benchmar

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 <mike.r.an...@gmail.com 
> > 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: [ANN] Clojure 1.8.0-RC4 is now available

[Mikera]

Thanks Alex, working well for me and startup times certainly seem a bit 
snappier.

I also agree that APersistentVector should not implement IMapEntry. 
always seemed like a bad idea to so glad to see it rolled back.

What's the plan with Tuples more broadly? I worked on this many months ago 
along with Zach T and a couple of others, and we demonstrated some 
promising performance improvements (see e.g. 
https://gist.github.com/ztellman/3701d965228fb9eda084). I remain convinced 
we are still leaving some fairly big wins on the table here.

On Thursday, 17 December 2015 05:45:21 UTC+8, Alex Miller wrote:
>
> Clojure 1.8.0-RC4 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. 
>
> Of particular note, CLJ-1861 removes the interning of unused vars. This 
> change reduces compiled class size (clojure jar is 8% smaller), which 
> reduces classloading time, and thus improves startup time (in some tests 
> ~10-15% faster). Code that uses direct linking (like Clojure core) sees the 
> greatest benefits as most direct-linked vars are unused, but you may also 
> see some benefits with code that is not direct linked as well.  Feedback 
> on startup time or other impacts in actual projects (with or without direct 
> linking) is appreciated.
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC4
>- Leiningen: [org.clojure/clojure "1.8.0-RC4"]
>
> Below are the changes since 1.8.0-RC3. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1861  - Remove 
>unused var interning
>- CLJ-1161  - Clojure 
>-sources.jar includes a bad properties file in release builds
>- Commit ae7ac 
>
> 
>  - 
>Unrolls the remainder of the Tuple changes from earlier in the release 
>cycle, most significantly rolling back the addition of IMapEntry to 
>APersistentVector
>
>

-- 
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: Practical ways to deal with 'bag-of-properties' syndrome, AKA dynamic typing?

[Mikera]

I agree 100% that schema is a great tool, and solves some of the problems

I still think the absence of (optional) types is a big missing piece in the 
Clojure story, because of the following reasons:
1. The ideal time to check types is at compile time - you want immediate 
feedback if you do something wrong [ e.g. ((map inc) 1) ], not at runtime 
or in a separate static analysis check
2. Separate checking tools don't help with performance optimisation (one of 
the key benefits of static type systems)
3. Without types in the compiler, types will always be second class 
citizens and subject to proliferation
4. The compiler can infer many types automatically. Why should we spend 
human effort annotating types that the compiler should infer?
5. There are plenty of people who really like Clojure, but for whom the 
lack of static typing is a big downside

In reality, we already have some ad-hoc typing in the Clojure compiler 
(type hints, primitives etc.) as well as "types" that are well understood 
and widely used in Clojure libraries but not explicit (sequence abstraction 
etc.)

I think the ideal solution would be some kind of extensible optional type 
system, with the following properties:
1. Any expression has an optional type. If the type is nil or "Any" then it 
behaves just as regular current untyped Clojure code
2. Types are pluggable (e.g. you can have prismatic schema types, 
core.typed types, java class types, custom "abstraction" types like 
Sequence)
3. Types can be defined as named first class objects, and used as type hints
4. Functions can (optionally) be typed, with the rule that the resulting 
type is a (fn [type-signature-or-args]) which returns a new type (or 
indicates impossibility somehow)
5. Types support some standard operations sufficient to allow optimisations 
(intersection, union, instance? etc.)
6. You can choose your level of type checking (off, check at runtime, 
compiler warn on type error, compiler fail on type error etc.) for people 
who prefer different positions on the dynamic / static typing spectrum

I believe it would be possible to add this kind of typing scheme to Clojure 
incrementally without breaking existing untyped code. It could be added 
incrementally to libraries, so that the ecosystem could evolve over time to 
have statically defined types as libraries mature and the definition of 
abstractions becomes clearer.

Obviously only going to happen if clojure/core is behind it, but if there 
is interest I'm happy to write a hammock proposal.




On Tuesday, 1 December 2015 09:47:49 UTC+8, Colin Yates wrote:
>
> +1 to everything said so far.
>
> I also found that types are great for articulating a well-known, static 
> set of structures, but almost all of the projects I worked in in a strongly 
> and statically typed language (Java) involved living on the edge of typing 
> _just_ the right level of abstraction - specifically, code which really 
> only cared about one aspect of a type versus having so many types you 
> couldn’t see the wood for the trees. Structural typing (or duck typing if 
> you prefer) would have gone a long way. Typing the _end_ result - sure, but 
> discovering the end result quickly - not so much.
>
> In Clojure I can still name and describe my abstractions through Schema (I 
> use it religiously and it has solved so many pain points, particularly ‘6 
> months down the line’ - and it is turned on in production as the overhead 
> is negligible for my usage) but I have the flexibility to _not_ name them 
> as well and the ‘Any’ predicate is a fantastic nod to pragmatism.
>
> To put it another way, almost all of my pain points are looking at forms, 
> particularly long ’threaded’ forms and thinking ‘how on earth does that 
> sequence of transformations work’ rather than ‘exactly what data is that 
> expecting’.
>
> To be clear - the rigour of being forced to come up with a decent name for 
> an important abstraction is great, and (Java’s) types force you to do that, 
> but it also quickly becomes the demoralising stick that leads to 
> ‘ICantBeBotheredToThinkOfAnotherName’.
>
> When it comes to _consuming_ unfamiliar code then yeah, types are 
> incredibly potent as a form of documentation, assuming those types have 
> good names of course :-).
>
> So for me, Clojure maps and Prismatic Schema give me pretty much all of 
> the good stuff I got from typing in the first place. I miss the 
> ‘correctness’ check that strong and static types give you but that is a 
> small pain for the increased expressiveness I have of describing my 
> data/abstractions.
>
> On 1 Dec 2015, at 01:15, Timothy Baldridge  > wrote:
>
> I believe that working with maps is a lot like working with locals and 
> function names...nothing will help you with bad naming. So don't do stuff 
> like {:foo 42 :bar 33} when you can do stuff like {:min-age 42 :max-age 
> 33}. Also stick with sane naming conventions. Don't do {:maxAge 42} in some 
> places and 

Procedurally generated animation in Clojure

[Mikera]

Hi all,

I created a set of tools this weekend to produce procedurally generated 
animations in Clojure. May be of interest to those who like computer 
graphics and the more creative usages of Clojure!

Here's an example which I rendered overnight:
https://www.youtube.com/watch?v=94CtmzAUIBI

Source code using the Clisk library is here:
https://github.com/mikera/clisk/blob/develop/src/test/clojure/clisk/samples/animations.clj

Video encoding was done using the new Telegenic library which wraps JCodec:
https://github.com/mikera/telegenic

The original 2D source image was created by Roger Allen's "TweeGeeMee" 
twitterbot:
https://twitter.com/tweegeemee

Enjoy!





-- 
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: rand-nth on empty collections

[Mikera]

Personally I think nth is broken and should throw an exception when passed 
nil (which should be interpreted as an empty sequence)

=> (nth nil 10)
nil
=> (nth '() 10)
IndexOutOfBoundsException   clojure.lang.RT.nthFrom (RT.java:885)
=> (nth [] 10)
IndexOutOfBoundsException   clojure.lang.PersistentVector.arrayFor 
(PersistentVector.java:157)

We want to throw exceptions with invalid arguments surely? Otherwise errors 
just propagate and it gets harder to trace root causes of bugs.

Following this logic, rand-nth should throw an exception in all these cases 
too.


On Thursday, 1 October 2015 06:11:36 UTC+8, Marc O'Morain wrote:
>
> I think Mailbox app might have messed with the quoting in my last reply. I 
> hope it makes sense. 
>
> I'm not suggesting that the function be changed - Clojure's API 
> compatibility between versions is amazing and a fine example of great 
> engineering. 
>
> Reading other people's input on this thread has made it clear to my what I 
> find surprising - rand-nth does not behave like `first` when called on an 
> empty collection, and in my mind asking for the first element of a sequence 
> and asking for a random element of that sequence are similar operations. 
>
> I do see the point of view that nth throws on out-of-bounds access, so 
> rand-nth should too, but in that case I would expect rand-nth to throw too. 
>
> I would like to see that subtlety mentioned in the doc string. 
>
> Thanks Alex & all!
>
>
>
> On Wed, Sep 30, 2015 at 3:14 PM, Alex Miller  > wrote:
>
>> rand-nth cannot return a random element if there are no elements to 
>> return, so I do not find this surprising. Returning nil would be an invalid 
>> answer in my opinion.
>>
>> The rand-nth doc string implies that rand-nth will inherit the semantics 
>> of nth for the specified collection. nth will generally throw on an invalid 
>> index (and all indexes are invalid for an empty collection).
>>
>> For nil, the docstring for nth does not mention nil explicitly, so I 
>> would treat this as undefined behavior unless you consider it as a 
>> degenerate sequence. 
>>
>> The code (in RT.nthFrom()) explicitly handles this case and effectively 
>> treats nil as an infinite indexed source of nils, rather than as an empty 
>> sequence. In my own opinion (but maybe not Rich's), it seems to make more 
>> sense to take the sequence interpretation and say that on nil, nth should 
>> throw instead.
>>
>> So that might be a valid ticket. I'm not sure what, if any, negative 
>> consequences would arise out of existing uses of nth that rely on this 
>> behavior though. Given the number of things built on nth, it may be 
>> impossible to change this even if it made sense to.
>>
>> Alex
>>  
>> On Wednesday, September 30, 2015 at 6:38:49 AM UTC-5, Marc O'Morain wrote:
>>>
>>> Hi all,
>>>
>>> I was surprised by the fact that rand-nth thrown when called on an empty 
>>> collection - see http://dev.clojure.org/jira/browse/CLJ-925 
>>> 
>>>
>>> This behaviour is strange, since passing nil to rand-nth returns nil, 
>>> whereas in my experience, other Clojure functions treat nil and empty 
>>> collections in the same way (compare with next/rest/first, etc).
>>>
>>> http://dev.clojure.org/jira/browse/CLJ-925 was marked as Completed 
>>> without comment – is this the intended behaviour? If so, would you accept a 
>>> patch to update the docstring to make it clear that the function will throw 
>>> an exception when passed an empty collection?
>>>
>>> Thanks,
>>>
>>> Marc
>>>
>> -- 
>> 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 

Re: Building mixed Clojure/Java project

[Mikera]

Ironclad was designed to be built as a self-contained jar with all 
dependencies using the mvn assembly plugin, as follows:

mvn assembly:single

This does something pretty much equivalent to lein uberjar

I pushed a couple of updates including documenting how to build to the 
latest develop branch.

On Monday, 28 September 2015 02:45:13 UTC+8, Nicolás Berger wrote:
>
> Now I had to try it by miself :). My result: `mvn package` outputs the 
> jar (apart from running some tests, etc), but it doesn't work as `java 
> -jar ...` as I said: it's missing the :main entry point, and after 
> that I guess the dependencies will be missing (it's not an uberjar, so 
> we need to build the classpath in some way). 
>
> About ant, the closed issue I linked has a comment from mikera saying 
> "Good spot. I just deleted the build.xml - it's an old relic, and new 
> builds should just use the pom". But the build.xml is still there, so 
> it might work, after fixing the hardcoded paths like 
> "E:/Users/Mike/Desktop/ironclad.jar" (or creating those directories, 
> of course). 
>
> On Sun, Sep 27, 2015 at 3:10 PM, Gregg Reynolds <d...@mobileink.com 
> > wrote: 
> > Looks like  Ant to me. 
> > 
> > On Sat, Sep 26, 2015 at 7:01 PM, <cyc...@speakeasy.net > 
> wrote: 
> >> 
> >> Hi, I'm trying to run/compile the project at 
> >> https://github.com/mikera/ironclad, with Leiningen, and no luck. 
> >> 
> >> My first attempt was trying to run it with lein, but as there's no 
> >> project.clj, that failed. After some research, it looks like I'm 
> supposed 
> >> run the project from Java, not Clojure. So my second attempt was lein 
> javac 
> >> IronClad.java, but that did absolutely nothing. 
> >> 
> >> I found a build.xml makefile that looked promising, it had lines like: 
> >> 
> >>  
> >>  
> >>  >> 
> src="E:\Programs\eclipse\plugins\org.junit_4.8.1.v4_8_1_v20100427-1100\junit.jar"/>
>  
>
> >> 
> >> 
> >> but it looked generated by Eclipse, which I don't have. Also, I'm not 
> >> clear if that requires Maven or something. 
> >> 
> >> I'm running on Windows, and have installed JDK 1.7 and Leiningen, no 
> >> Maven/Eclipse or other Java-related tools. 
> >> 
> >> What is the best way to build this project? 
> >> 
> >> -- 
> >> 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 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: ClojureScript vs. Elm for Multiplayer Web Game

[Mikera]

I would definitely consider ClojureScript on the client plus Clojure on the 
server side. It's great to be able to build full-stack solutions using 
Clojure and share code across both the server and the browser, escpecially 
with the new .cljc support in Clojure 1.7

If you want an example of 2D game development in Clojure (with immutable 
data structures, event handling etc.) then my little game Ironclad may be 
interesting (it is a desktop client rather than ClojureScript however)
https://github.com/mikera/ironclad

There is also an article about building a card game (Omnigard) with 
ClojureScript here:
https://www.railslove.com/stories/my-way-into-clojure-building-a-card-game-with-om-part-1?locale=de-DE

On Monday, 21 September 2015 04:09:22 UTC+8, JvJ wrote:
>
> I'm trying to develop a small multiplayer in-browser card game (simple 2d 
> garphics), but I don't have  a lot of experience in web app development. 
>  I'll probably be handling client-server communication with Node.js.
>
> I do have experience with functional programming, so I was looking into 
> things like ClojureScript and the Elm language (http://elm-lang.org).
>
> If anyone has experience with game development in either or both of these 
> languages, which would you suggest?
>
> Thanks
>

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

[Mikera]

Go is fine for system-level programming, but I personally wouldn't use it 
as a web application programming language. Ten reasons to consider.:

1. There isn't really much speed difference on micro-benchmarks between JVM 
code and Go. See e.g.: http://benchmarksgame.alioth.debian.org/u64q/go.html

2. In many real-world cases JVM code will outperform Go, see e.g. 
http://zhen.org/blog/go-vs-java-decoding-billions-of-integers-per-second/

3. The JVM GC is superior to the GC in Go. This makes a big difference for 
complex applications with a lot of live objects on the heap, especially 
when dealing with stuff like immutable persistent data structures (and you 
want to use those, right?). Overall, I'd expect Clojure to easily 
outperform Go for these types of applications. 

4. The JVM startup time / memory overhead is irrelevant for long running 
server applications. If you are restarting the JVM regularly, you are 
definitely doing something wrong. The JVM is well tuned for long-running 
server side web applications in general, rather than the lightweight 
processes / scripts that are more suited to Go.

5. Functional programming is natural in Clojure and is IMHO the future for 
building modern applications

6. If you like the CSP stuff (goroutines, channels etc.), Clojure has the 
excellent core.async, which basically lets you do all the nice CSP type 
things in Clojure you can do in Go. However that isn't forced on you: 
Clojure supports a lot of other paradigms for concurrent programming. 
Choose what works best for you.

7. The open source library ecosystem on the JVM is awesome. There's nothing 
like it for any other language. Even if nobody has written a Clojure 
library that wraps up the functionality you need yet, using Java libraries 
from Clojure is very painless (often easier than using Java libraries from 
Java!)

8. Virtually all the key big data stuff depends on the JVM. Spark, Hadoop 
ecosystem etc. Being on the JVM is a valuable strategic choice if you are 
into data processing. / analytics.

9. Clojure has an compelling full stack development story with 
ClojureScript on the browser and Clojure on the server. It's pretty useful 
to be able to share code between the server and the client.

10. Once you've experienced interactive REPL driven web application 
development with stuff like Figwheel, you probably won't want to go back to 
anything else

On Monday, 14 September 2015 03:44:48 UTC+8, Alan Thompson wrote:
>
> Hi,
>
> I'm about to start a new web project and they are thinking about using Go 
> (golang) instead of a JVM (preferably Clojure) based approach.  The idea is 
> "BARE METAL SPEED!!!", but I really think the network and DB will be the 
> bottlenecks, not Clojure vs Go.
>
> Is anybody out there aware of any speed comparisons using Clojure/Pedestal 
> and/or Go?  I'm thinking basic measurements like connections/sec, latency, 
> simultaneous users, etc.
>
> Thanks,
> Alan
>

-- 
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: numbers, why?

[Mikera]

You can use *unchecked-math* if you want unchecked arithmetic behaviour:

=> (set! *unchecked-math* true)
true
=> (+ Long/MAX_VALUE Long/MAX_VALUE)
-2

On Friday, 4 September 2015 23:04:27 UTC+8, Ali M wrote:
>
> Ok, so to give myself a safe and consistent way to reason about this
> the addition operator, and probably other arithmetic operator 
> dont promote ouput 
>
> so long+ long = long or exception 
> long + bigint = bigint
>
> if i need outpout promition i can use +'
>
> hmmm, a bit tricky
>
> On Friday, September 4, 2015 at 10:51:15 AM UTC-4, dennis wrote:
>>
>> Because the literal is readed as BigInt:
>>
>> user=> (class 6546546546546546546850348954895480584039545804 )
>> clojure.lang.BigInt
>>
>> 2015-09-04 22:48 GMT+08:00 Ali M :
>>
>>> why?
>>>
>>> 
>>> user=> (+ 6546546546546546546850348954895480584039545804 
>>> 7548979534287548957345843954749357348757897)
>>> 6554095526080834095807694798850229941388303701N
>>>
>>> user=> (+ Long/MAX_VALUE Long/MAX_VALUE)
>>>
>>> ArithmeticException integer overflow  
>>> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>>>
>>> user=> Long/MAX_VALUE
>>> 9223372036854775807
>>> 
>>>
>>> Why the much bigger numbers get promoted, and a smaller number overflows?
>>>
>>> Thank you
>>> Ali
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> 庄晓丹 
>> Email:killm...@gmail.com xzh...@avos.com
>> Site:   http://fnil.net
>> Twitter:  @killme2008
>>
>>
>>

-- 
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 bootstrap, what am I missing here?

[Mikera]

A few things to consider:

1. Performance is a key consideration. The speed of the compiler is a major 
determinant of startup time for Clojure applications, which is very 
important to many people. Having the compilker written in Java probably 
helps a lot here - it is generally easier to write high performance JVM 
code in pure Java. Yes, it's also possible to write fast code in Clojure, 
but it typically isn't idiomatic and is much harder to write / maintain. It 
would be quite a challenge to write a compiler with equivalent performance 
in pure, idiomatic Clojure.
2. YMMV but while I find that Clojure is extremely productive for writing 
new code, it really helps to have a type system when maintaining code. When 
maintaining a complex beast like the Clojure compiler, I don't think 
Clojure is actually going to be much better than well-written Java in this 
regard.
3. The bits of Clojure that users interact with directly (clojure.core 
etc.) are mostly already written in Clojure. Curious folks can still 
examine the Clojure source code for the core functions. The Java stuff is 
mostly around the compiler and implementation details of data structures 
etc.

Personally, I think this falls into the "if it isn't broken, don't fix it" 
category.

On Monday, 24 August 2015 23:23:07 UTC+8, William la Forge wrote:
>
> Well gosh, Timothy, isn't Clojure code easier to maintain/extend than Java 
> code? There's a lot less boiler plate at least. Or is it just that Clojure 
> is superior mostly when multi-threading because of its use of immutables?
>
> Are you really saying that Clojure is not an advantageous choice for 
> implementing Clojure? Perhaps as a newbie I'm just oversold on Clojure? Or 
> are you just taking a short-term view and saying that a rewrite would carry 
> no IMMEDIATE advantages. Of course, the counter for that is that a rewrite 
> ALWAYS carries immediate advantages. :D
>
> On Monday, August 24, 2015 at 11:10:05 AM UTC-4, tbc++ wrote:
>>
>> " I would think that having Clojure implemented entirely in Clojure 
>> would have a number of advantages."
>>
>> I think that's the place you should start. List those advantages. 
>> Clojure-in-Clojure would be a "nice" thing to have...but I can't really 
>> think of any major features it would enable that aren't possible in Clojure 
>> already.
>>
>> One thing that would be nice to have would be to switch Clojure's Java 
>> interfaces over to protocols, e.g. `Counted` could be a protocol instead of 
>> a interface. But that could be done on the existing codebase, without the 
>> need for a full rewrite. 
>>
>> Timothy
>>
>> On Mon, Aug 24, 2015 at 9:03 AM, William la Forge  
>> wrote:
>>
>>> Step 2 in the classical bootstrap process for a language is to rewrite 
>>> it in itself. Clojure is more than capable of this. But Clojure continues 
>>> to rely on Java code for its implementation.
>>>
>>> Is there a reason why this was not done? Efficiency issues? A rush to 
>>> create something usable? I would think that having Clojure implemented 
>>> entirely in Clojure would have a number of advantages.
>>>
>>> I am sure there was a deliberate decision, not to complete the bootstrap 
>>> process. Is this documented anywhere?
>>>
>>> Just being a nosy newbie.
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “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: 0.1.0 core.async release?

[Mikera]

Here's the situation:
1) I have projects that I manage and release using Maven (e.g. 
core.matrix). The pom.xml is the master for project configuration which I 
edit directly.
2) I'd like to have a project.clj as well, as a convenience for other 
developers (there is clearly a demand - people sometimes contribute these 
to my Maven-managed libraries)
3) It would be nice if the project.clj could be updated automatically (with 
dependencies and version numbers at least)

I don't think it is a CCW issue as such, or at least it should probably be 
addressed in a way that is IDE-independent. Seems like the most appropriate 
solution would be some kind of config in clojure-maven-plugin that does 
this as a (optional?) build step, but I'm not expert enough on the Maven 
lifecycle to pinpoint exactly how this could be done.

Alternative option: have a warning when the pom.xml and project.clj are out 
of sync. Requires more manual work to fix, but at least reduces the risk of 
accidentally getting out of sync.

On Saturday, 8 August 2015 15:22:25 UTC+8, Laurent PETIT wrote:

 Hello Mike, I'd like to understand why you feel the need to convert the 
 pom to project.clj?

 Knowing those use cases better might help me think about what could be 
 done in ccw, or in clojure-maven-plugin, to remove this need. 

 Le samedi 8 août 2015, Mikera mike.r.an...@gmail.com javascript: a 
 écrit :

 Has anyone found a good way to automatically keep project.clj in sync 
 with the official pom.xml? Maybe using the clojure-maven-plugin or similar?

 I do this too for a number of libraries, but it's always a manual task 
 and prone to error at present

 On Saturday, 8 August 2015 07:45:41 UTC+8, Sean Corfield wrote:

 Clojure contrib projects are built via pom.xml so that’s where you 
 should look for version information.

 The project.clj file is a convenience for the developers/maintainers and 
 has nothing to do with the actual project version (although some 
 developers/maintainers try to keep their project.clj in sync).

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

 If you're not annoying somebody, you're not really alive.
 -- Margaret Atwood


 From: clo...@googlegroups.com on behalf of Daniel Compton
 Reply-To: clo...@googlegroups.com
 Date: Friday, August 7, 2015 at 3:50 PM
 To: Clojure
 Subject: Re: 0.1.0 core.async release?

 The version in the project.clj file is 0.1.0-SNAPSHOT, that'll probably 
 be it. 
 On Sat, 8 Aug 2015 at 9:12 AM Alex Miller al...@puredanger.com wrote:

 I don't where the 0.1.0 number is coming from, but yes there are plans 
 to do a round of work on core.async and release in the near future.


 On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:

 Is there a new release planned for core.async anytime in the near 
 future?

 The docs show some functionality that's not in the current release 
 [1].  Specifically offer! [2] which looks like it's slated for 0.1.0 
 (love 
 to switch to that from alts+timeout).

 Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)

 Regards,

 Kyle



 [1] https://github.com/clojure/core.async shows Latest release: 
 0.1.346.0-17112a-alpha
 [2] http://clojure.github.io/core.async/#clojure.core.async/offer!

 -- 
 Twitter: @kyleburton
 Github: https://github.com/kyleburton
 Blog: http://asymmetrical-view.com/
 Fun: http://snapclean.me/

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

 -- 
 --
 Daniel

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

Re: 0.1.0 core.async release?

[Mikera]

Has anyone found a good way to automatically keep project.clj in sync with 
the official pom.xml? Maybe using the clojure-maven-plugin or similar?

I do this too for a number of libraries, but it's always a manual task and 
prone to error at present

On Saturday, 8 August 2015 07:45:41 UTC+8, Sean Corfield wrote:

 Clojure contrib projects are built via pom.xml so that’s where you should 
 look for version information.

 The project.clj file is a convenience for the developers/maintainers and 
 has nothing to do with the actual project version (although some 
 developers/maintainers try to keep their project.clj in sync).

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

 If you're not annoying somebody, you're not really alive.
 -- Margaret Atwood


 From: clo...@googlegroups.com javascript: on behalf of Daniel Compton
 Reply-To: clo...@googlegroups.com javascript:
 Date: Friday, August 7, 2015 at 3:50 PM
 To: Clojure
 Subject: Re: 0.1.0 core.async release?

 The version in the project.clj file is 0.1.0-SNAPSHOT, that'll probably be 
 it. 
 On Sat, 8 Aug 2015 at 9:12 AM Alex Miller al...@puredanger.com 
 javascript: wrote:

 I don't where the 0.1.0 number is coming from, but yes there are plans to 
 do a round of work on core.async and release in the near future.


 On Friday, August 7, 2015 at 1:16:19 PM UTC-5, Kyle Burton wrote:

 Is there a new release planned for core.async anytime in the near future?

 The docs show some functionality that's not in the current release [1].  
 Specifically offer! [2] which looks like it's slated for 0.1.0 (love to 
 switch to that from alts+timeout).

 Are there (perhaps) tasks that need a dev? (yes, I'm offering to help)

 Regards,

 Kyle



 [1] https://github.com/clojure/core.async shows Latest release: 
 0.1.346.0-17112a-alpha
 [2] http://clojure.github.io/core.async/#clojure.core.async/offer!

 -- 
 Twitter: @kyleburton
 Github: https://github.com/kyleburton
 Blog: http://asymmetrical-view.com/
 Fun: http://snapclean.me/

 -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.

 -- 
 --
 Daniel

 -- 
 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 javascript:
 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 javascript:
 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 javascript:.
 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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[Mikera]

If you want a free / open source alternative, then Eclipse also offers a 
great environment for developing Java, Clojure and Python.

The Counterclockwise plugin for Eclipse is great - certainly has provided 
everything I want in a Clojure dev environment (integrated REPL, paredit 
mode, good syntax highlighting, integrated docstrings, auto-complete etc.)

On Monday, 3 August 2015 08:51:17 UTC+8, puzzler wrote:

 Intellij might be your best option for a unified development platform for 
 Java, Clojure, and Python.  It won't be free though.




-- 
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: Controlling growth rates of generators with test.check

[Mikera]

See:
https://github.com/clojure/test.check/commit/d4883873df73717629272d0ab71619d7e58c9c9e

On Wednesday, 29 July 2015 23:31:14 UTC+8, Mayank Jain wrote:

 Nice. Any updates on this?
 Is this a good idea?

 On Friday, May 15, 2015 at 12:13:06 PM UTC+5:30, Mikera wrote:

 Hi all,

 I am doing some generative testing with test.check and need a way to 
 control the growth rate of data structures (the regular linear growth 
 quickly makes the computations too large for meaningful testing usage). I 
 came up with the following solution to do this:

 (defn gen-resize 
   Creates a generator that pre-modifies the 'size' pramater with the 
 function f. Use if you want to 
have the size grow at a different rate from the normal linear scaling.
   ([f gen]
 (let [gf (or (:gen gen) gen paramter must be a test.check generator)
   new-gf (fn [rnd size]
(gf rnd (f size)))]
   (clojure.test.check.generators.Generator. new-gf

 Normal O(n) growth:

 (gen/sample gen/s-pos-int 30)
 = (1 2 3 2 4 5 4 7 6 3 3 7 10 4 8 11 14 12 6 10 9 1 8 21 12 16 25 25 21 
 6)

 Controlled O(sqrt(n)) growth:

 (gen/sample (gen-resize sqrt gen/s-pos-int) 30)
 = (1 2 2 2 2 4 3 3 3 3 4 3 5 1 2 3 2 4 4 2 2 3 6 6 2 5 5 4 6 3)

 So it seems to work, but is this a sane / recommended approach? Am I 
 relying too much on test.check internals?

   mikera



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

[Mikera]

Hi Alex, 

1.8.0-alpha3 is breaking core.matrix at the moment.

Root cause appears to be related to how protocols are being handled when 
used with Java arrays:

e.g. for the protocol implementation:
(extend-protocol mp/PImplementation
  (Class/forName [Ljava.lang.Object;)
(implementation-key [m] :object-array)
(meta-info [m]
  {:doc Clojure.core.matrix implementation for Java Object arrays})
(new-vector [m length] (construct-object-vector (long length)))
(new-matrix [m rows columns]
  (let [columns (long columns)
m (object-array rows)]
(dotimes [i rows]
  (aset m i (construct-object-vector columns)))
m))
(new-matrix-nd [m shape]
  (construct-nd shape))
(construct-matrix [m data]
  (construct-object-array data))
(supports-dimensionality? [m dims]
  (= dims 1)))

When called as:
(clojure.core.matrix.protocols/construct-matrix (object-array 1) [1])

Gives exception:
VerifyError (class: clojure/core/matrix$eval10586, method: invokeStatic 
signature: ()Ljava/lang/Object;) Incompatible object argument for function 
call  java.lang.Class.getDeclaredConstructors0 (:-2)

On Thursday, 30 July 2015 06:51:18 UTC+8, Alex Miller wrote:

 Clojure 1.8.0-alpha3 is now available.

 Try it via
 - Download: 
 https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha3
 - Leiningen: [org.clojure/clojure 1.8.0-alpha3]

 Tuples have been disabled after further analysis of performance impacts.

 This alpha has initial support for direct linking which you can enable 
 with -Dclojure.compiler.direct-linking=true

 Direct linking allows functions compiled with direct linking on to make 
 direct static method calls to most other functions, instead of going 
 through the var and the Fn object. This can enable further optimization by 
 the jit, at a cost in dynamism. In particular, directly-linked calls will 
 not see redefinitions.

 In alpha3, clojure.core is compiled with direct linking by default and 
 therefore other namespaces cannot redefine core fns and have those 
 redefinitions seen by core code.

 Functions declared as dynamic will never be linked to directly.

 As with all alphas, this represents ongoing work-in-progress that is 
 subject to change.


-- 
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: Java 8 Lambda Interop

[Mikera]

It could certainly be achieved in the Clojure compiler, by allowing 
(some-functional-interface .) to compile to the appropriate function 
call even if it doesn't implement IFn

It would be quite a big change though and would probably have some 
limitations, e.g.:
a) It probably wouldn't work with regular vars since it wouldn't be able to 
handle re-binding
b) You would probably have to type hint the some-functional-interface 
object in some way so that the compiler knows to do this at compile time

A less invasive option would be to just have some code to wrap functional 
interfaces in an appropriate IFn.

Worth a JIRA ticket for consideration at least?



On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote:

 Thanks for the reply Gary. Sounds like I'm on as good a track as I can be 
 with current Clojure.

 I am curious though why you say that it is unrealistic for IFn to support 
 arbitrary @FunctionalInterface. It certainly seems like it would require 
 compiler changes, but I would think that either through emitting bytecode 
 closer to Java 8 lambdas or through some form of type coercion it would 
 possible. For example, Groovy just coerces their Closures to any Single 
 Abstract Method type.

 I'm not sure how java.util.function.* as protocols would work, but still 
 would require implementing for each SAM you come across. IFn as a protocol 
 seems to address a different interop use case. Maybe for receiving a Java 
 lambda you want to use as if it's a Clojure function. 

 Most of the Java interop from Clojure is slick (sometimes more clear than 
 in Java itself), it would be unfortunate to leave functions as second-class 
 citizens for interop. Granted, there may be a simplicity argument against 
 this (maybe that's why Java varargs require an explicit array?).

 Andrew Oberstar

 On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com 
 javascript: wrote:

 On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com 
 javascript: wrote:

 Hi,

 I'm wondering if anyone has a good approach for making calls from 
 Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface 
 type.

 Ideally, IFn would transparently work, but I'm guessing that requires 
 some compiler changes.

 Right now, the best I can think of is a function or macro to reify a 
 wrapper around a Clojure function to implement all of the usual interfaces 
 from java.util.function.

 Anyone have any better ideas?

 Andrew Oberstar


 You're probably aware of this, but @FunctionalInterface is not a type, 
 it's an annotation. All it does is ensure, at compile time, that the 
 annotated element is an interface with a single non-default and non-static 
 method. At the type-system level, it's just an interface like any other, 
 and the lambda syntax is just a shorthand for an anonymous instance of a 
 well-defined type.

 Since the lambda syntax is java-compiler magic, you can't access it from 
 Clojure, and the most straightforward option right now is to actually know 
 which type is expected, e.g.:

 user= (- (doto (java.util.ArrayList.) (.add 1) (.add 2)) (.stream) 
 (.map (reify java.util.function.Function (apply [_ arg] (inc arg 
 (.collect (java.util.stream.Collectors/toList)))
 [2 3]
 user=

 As neither IFn nor Function are Clojure protocols, I do indeed think 
 you're best bet is a macro to essentially generate the above reify. You can 
 of course do a single macro that reifies to all of the protocols that you 
 need.

 I don't think it's realistic to hope that IFn will cover any arbitrary 
 @FunctionalInterface, as that is Java compiler magic. It may, in the 
 future, be extended to cover all of the standard ones in 
 java.util.function, or even all the ones in the standard library, but it's 
 not going to happen until Java 7 support is dropped. I guess the best you 
 could hope for in the short term would be to have IFn changed to a protocol.
  
 -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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

Re: Java 8 Lambda Interop

[Mikera]

Ah, I get what you are doing now.

Don't think that is likely to work unless Clojure starts making IFn 
instances implement the right java.util.function.* interfaces. Which seems 
unlikely given the conservatism of Clojure development. Having said that, I 
do think it is possible, have been playing around with a little toy 
language implementation that does something similar.

I think you are better off for now writing a function or macro that allows 
you to wrap a Clojure function as a java.util.function.Predicate and lets 
you do something like:

(.filter (predicate odd?))


On Tuesday, 28 July 2015 09:53:25 UTC+8, Andrew Oberstar wrote:

 Mikera, I think you're addressing a different interop concern. I'm 
 particularly interested in something like this:

 (- (IntStream/range 0 100) (.filter odd?) (.limit 5) (.collect 
 Collectors/toList))

 Where odd? is a normal Clojure IFn that I want to use when calling a 
 Java API that expects something implementing a single-method-interface 
 (Predicate in this case).

 Right now I need to do something like this:

 (defn lambda [f] (reify Predicate (test [x] (f x

 (- (IntStream/range 0 100) (.filter (lambda odd?)) (.limit 5) (.collect 
 Collectors/toList))

 Andrew Oberstar


 On Mon, Jul 27, 2015 at 8:16 PM Mikera mike.r.an...@gmail.com 
 javascript: wrote:

 It could certainly be achieved in the Clojure compiler, by allowing 
 (some-functional-interface .) to compile to the appropriate function 
 call even if it doesn't implement IFn

 It would be quite a big change though and would probably have some 
 limitations, e.g.:
 a) It probably wouldn't work with regular vars since it wouldn't be able 
 to handle re-binding
 b) You would probably have to type hint the some-functional-interface 
 object in some way so that the compiler knows to do this at compile time

 A less invasive option would be to just have some code to wrap functional 
 interfaces in an appropriate IFn.

 Worth a JIRA ticket for consideration at least?



 On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote:

 Thanks for the reply Gary. Sounds like I'm on as good a track as I can 
 be with current Clojure.

 I am curious though why you say that it is unrealistic for IFn to 
 support arbitrary @FunctionalInterface. It certainly seems like it would 
 require compiler changes, but I would think that either through emitting 
 bytecode closer to Java 8 lambdas or through some form of type coercion it 
 would possible. For example, Groovy just coerces their Closures to any 
 Single Abstract Method type.

 I'm not sure how java.util.function.* as protocols would work, but still 
 would require implementing for each SAM you come across. IFn as a protocol 
 seems to address a different interop use case. Maybe for receiving a Java 
 lambda you want to use as if it's a Clojure function. 

 Most of the Java interop from Clojure is slick (sometimes more clear 
 than in Java itself), it would be unfortunate to leave functions as 
 second-class citizens for interop. Granted, there may be a simplicity 
 argument against this (maybe that's why Java varargs require an explicit 
 array?).

 Andrew Oberstar

 On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com 
 wrote:

 On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com wrote:

 Hi,

 I'm wondering if anyone has a good approach for making calls from 
 Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface 
 type.

 Ideally, IFn would transparently work, but I'm guessing that requires 
 some compiler changes.

 Right now, the best I can think of is a function or macro to reify a 
 wrapper around a Clojure function to implement all of the usual 
 interfaces 
 from java.util.function.

 Anyone have any better ideas?

 Andrew Oberstar


 You're probably aware of this, but @FunctionalInterface is not a type, 
 it's an annotation. All it does is ensure, at compile time, that the 
 annotated element is an interface with a single non-default and non-static 
 method. At the type-system level, it's just an interface like any other, 
 and the lambda syntax is just a shorthand for an anonymous instance of a 
 well-defined type.

 Since the lambda syntax is java-compiler magic, you can't access it 
 from Clojure, and the most straightforward option right now is to actually 
 know which type is expected, e.g.:

 user= (- (doto (java.util.ArrayList.) (.add 1) (.add 2)) (.stream) 
 (.map (reify java.util.function.Function (apply [_ arg] (inc arg 
 (.collect (java.util.stream.Collectors/toList)))
 [2 3]
 user=

 As neither IFn nor Function are Clojure protocols, I do indeed think 
 you're best bet is a macro to essentially generate the above reify. You 
 can 
 of course do a single macro that reifies to all of the protocols that you 
 need.

 I don't think it's realistic to hope that IFn will cover any arbitrary 
 @FunctionalInterface, as that is Java compiler magic. It may, in the 
 future, be extended to cover

Re: What is the best way to pass log configs everywhere without a global var?

[Mikera]

On Saturday, 25 July 2015 22:50:55 UTC+8, crocket wrote:

 Logging libraries seem to rely on a global config. This looks like a 
 dangerous state that could blow up.
 I researched a little, and there seems to be reader monad and dependency 
 injection, all of which feel awkard.

 Is there not a decent approach to passing log config without a global var?


If you are using stuartsierra/component, it makes sense to have logging as 
a component within your overall system configuration.

I've found this to be a very useful approach in general: you can swap in / 
out different loggers for testing, you avoid a global var, it makes for 
really easy reloading at the REPL or running multiple concurrent versions 
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: #{:rant} Questions about contribution policy and clojure compiler source.

[Mikera]

On Sunday, 19 July 2015 00:03:04 UTC+8, Andy Fingerhut wrote:

 I don't think the tweets you link are the 'normal approach'. I would call 
 them pretty unusual in several aspects.  For one, I think that for the vast 
 majority of Clojure tickets created, no on asks and gets Rich's comments on 
 them before they are created.  Second, most end up being committed as the 
 submitter created them, with fewer rounds of review and updates.  Most of 
 them are a lot less work on the part of the contributor than the two 
 examples mentioned.

 Note: I am not saying that those two examples didn't happen, or that there 
 are no others like that.  I am saying they are unusual examples, as 
 compared to the great majority of Clojure tickets.  Most tickets that have 
 a change committed for them end up being committed as a patch submitted by 
 a contributor, without being implemented differently.

 It is fairly common for there to be months or years of waiting time for a 
 ticket to be considered.  Rich is one person, and like most people, he gets 
 to choose how much time he spends on volunteer projects, and what projects 
 those are.  Alex Miller spends a significant fraction of his time tending 
 to tickets and commenting on and reviewing patches.


This point (i.e. lead time) is by far my biggest gripe about the Clojure 
contribution process. It causes a number of problems:
A) Contributors get de-motivated waiting for feedback / communication
B) Patches often become stale. This wastes more time
C) People forget what they were thinking about months or years ago
D) Improvements take too long to get into Clojure (Zach's CLJ-1517 case is 
a good example)
E) It creates the perception (even if it is not the reality?) that Clojure 
is unfriendly to contributors

My practical suggestion is simple: Clojure needs more trusted maintainers 
who know particular parts of Clojure well and can work more closely with 
contributors to get patches in a good state for Rich to review, and 
potentially even merge the simpler types of changes (bug fixes, 
documentation updates, basic refactoring, indentation etc.). Rich's time 
can then be spent on the high value stuff (reviewing good quality patches 
only when they are ready in the view of the trusted maintainer, 
considering changes which impact language design etc.).

FWIW It's worth comparing the rate of development on Clojure vs. Linux:

Clojure: https://github.com/clojure/clojure/graphs/commit-activity (10 
commits per week)
Linux: https://github.com/torvalds/linux/graphs/commit-activity (500-1500 
commits per week)

Obviously Linux is a bigger project, but there is still only one BDFL in 
both cases (and I am sure both BDFLs are very busy!)

So how does Linus do it? The answer is organisation. Linux has many trusted 
subsystem maintainers who do most of the work reviewing and merging 
patches. Linus may have the final say on everything but the Linux community 
has done a lot of thinking and self-organisation to make sure that Linus is 
not usually the bottleneck. 

Also worth noting that Linus does indeed use pull requests (just not GitHub 
ones, see the extended discussion here if interested: 
https://github.com/torvalds/linux/pull/17#issuecomment-5654674 ). Not 
saying Rich has to do so himself, but the trusted maintainers would be 
able to do so if it helped with the workflow for work-in-progress patches.

 


 As for indentation of Java code, it is called Whitesmiths style: 
 https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style

 Clojure was the first project I came across using this indentation style, 
 but Rich isn't the only one to use it.  A few bits of code have crept in 
 over the years using other indentation styles, usually contributed by 
 others.

 Andy

 On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh ni...@niwi.nz 
 javascript: wrote:

 Hi!

 I have some, maybe controversial, questions...

 A little bit of context: 
 https://twitter.com/aphyr/status/621806683908542464 

 Why this is like a normal approach for managing third party contributions 
 to clojure core? This kind of things the only discourages the 
 contributions. Maybe I don't have more context about this concrete case, 
 but seems is not a unique.
 And in general, I have the perception that the clojure development 
 process is a little bit opaque... 

 An other question: Why the great amount of clojure compiler code has no 
 indentation style and bunch of commented code. 

 It is indented like a freshman. Sorry, I don't want offend any one, but 
 eyes hurt when reading the code compiler clojure (obviously I'm speaking 
 about the look and feel, and no the quality of the code).

 Some examples:

 Indentation (or maybe no indentation):

 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86

 Bunch of commented code and also no indentation:

 

Re: [ANN] Clojure.Joda-Time 0.6.0

[Mikera]

Looks really nice!

Has anyone given thought to a more general time library, that can also 
handle the new java.time instances? I expect that will become a standard 
across many Java libraries in the future so it would be helpful to have 
good interop capabilities.

On Wednesday, 15 July 2015 16:48:01 UTC+8, platon...@gmail.com wrote:

 Happy to announce a new release of Clojure.Joda-Time[0] for those of us 
 who have to operate on temporal entities in complicated ways.

 Notable changes: 

 * A brand new `joda-time.accessors` namespace which contains a bunch of 
 accessors generated for every Joda-Time date field type, e.g. 
 `day-of-month`, `max-day-of-month`, `with-day-of-month`, 
 `with-max-day-of-month`, etc. The accessors work on both partials (local 
 dates) and instants (date-time). There are also accessors for periods.
 * Multi-arity constructors for date-times and partial dates (local-date, 
 local-date-time, etc.)
 * Support for the latest Joda-Time 2.8.1

 Changelog: 
 https://github.com/dm3/clojure.joda-time/blob/master/CHANGELOG.md
 Codox: http://dm3.github.io/clojure.joda-time/

 [0] https://github.com/dm3/clojure.joda-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: [ANN] suchwow: a grab-bag library with some twists

[Mikera]

Can we get links? Initial design docs?

This is the first I heard of this, but sounds like something that could do 
with a decent amount of community discussion and feedback if we are going 
to establish a good standard.

Some properties of such library metadata I'd like to see:
1) Works equally well for 3rd party tools as for clojure.core
2) Docs can be either separate or packaged in the library .jar
3) Tool independent (i.e. works equally well with lein, maven, cursive, 
counterclockwise)
4) Plans to migrate other tools / documentation formats
5) Well suited to automatic generation of documentation sites
6) Well suited to git workflows / merging contributions etc.

On Tuesday, 14 July 2015 09:29:23 UTC+8, Alex Miller wrote:

 This is the ballpark of one of the Google summer of code projects - 
 defining library metadata via a data format and tools to allow it to be 
 combined, 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: (flatten non-sequential) has a surprising result

[Mikera]

On Wednesday, 1 July 2015 12:55:28 UTC+1, J. Pablo Fernández wrote:

 Hello Clojurists,

 Today I was surprised by the result of (flatten 1) which is '(). I was 
 expecting '(1) or an error. Talking in some other people in #clojure @ 
 clojurians.net, not everybody agrees that '(1) is a good result but that 
 '() is somewhat surprising. Would it be better if it raised an error when 
 the attribute is not sequential?


From an array programming / core.matrix perspective '(1) would be the most 
logical result.

Consider the logical sequence:
[[[1]]] = 3 dimensional array with elements '(1) 
[[1]] = 2 dimensional array with elements '(1) 
[1] =1 dimensional array with elements '(1) 
1 = 0 dimensional array (or scalar) with elements '(1) 

I am not saying that this is necessarily the best behaviour to follow for 
flatten, but it is an analogy worth considering.


-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Mikera]

Hi Dragan,

The situation as I see it:
- You've created a matrix library that performs well on one benchmark 
(dense matrix multiplication). 
- Neanderthal meets your own personal use cases. Great job!
- Neanderthal *doesn't* fit the use cases of many others (e.g. some need a 
portable pure JVM implementation, so Neanderthal is immediately out)
- Fortunately, in the Clojure world we have a unique way for such libraries 
to interoperate smoothly with a common API (core.matrix)
- Neanderthal could fit nicely in this ecosystem (possibly it could even 
replace Clatrix, which as you note hasn't really been maintained for a 
while...)
- For some strange reason, it *appears to me* that you don't want to 
collaborate. If I perceive wrongly, then I apologise.

If you want to work together with the rest of the community, that's great. 
I'm personally happy to help you make Neanderthal into a great matrix 
implementation that works well with core.matrix. I'm 100% sure that is an 
relatively simple and achievable goal, having done it already with 
vectorz-clj 

If on the other hand your intention is to go your own way and build 
something that is totally independent and incompatible, that is of course 
your right but I think that's a really bad idea and would be detrimental to 
the community as a whole. Fragmentation is a likely result. At worst, 
you'll be stuck maintaining a library with virtually no users (the Clojure 
community is fairly small anyway... and it is pretty lonely to be a 
minority within a minority)

I can see from your comments below that you still don't understand 
core.matrix. I'd be happy to help clarify if you are seriously interested 
in being part of the ecosystem. Ultimately I think you have some talent, 
you have obviously put in a decent amount of work and Neanderthal could be 
a great library *if and only if* it works well with the rest of the 
ecosystem and you are personally willing to collaborate. 

Your call.

On Monday, 22 June 2015 10:05:15 UTC+1, Dragan Djuric wrote:



 On Monday, June 22, 2015 at 2:02:19 AM UTC+2, Mikera wrote:


 There is nothing fundamentally wrong with BLAS/LAPACK, it just isn't 
 suitable as a general purpose array programming API. See my comments 
 further below.


 I was discussing it from the *matrix API* perspective. My comments follow:
  

 If you think the core.matrix API is unintuitive and complicated then 
 I'd love to hear specific examples. We're still open to changing things 
 before we hit 1.0


 I will only give a couple basic ones, but I think they draw a bigger 
 picture. Let's say I am a Clojure programmer with no huge experience in 
 numerical computing. I do have some knowledge about linear algebra and have 
 a textbook or a paper with an algorithm that I need, which is based on some 
 linear algebra operations. I'd say that this is the most common use case 
 for an API such as core.matrix, and I hope you agree. After trying to write 
 my own loops and recursion and fail to do it well, I shop around and find 
 core.matrix with its cool proposal: a lot of numerical stuff in Clojure, 
 with pluggable implementations. Yahooo! My problem is almost solved. Go to 
 the main work right away:

 1. I add it to my project and try the + example from the github page. It 
 works.
 2. Now I start implementing my algorithm. How to add-and-multiply a few 
 matrices? THERE IS NO API DOC. I have to google and find 
 https://github.com/mikera/core.matrix/wiki/Vectors-vs.-matrices so I 
 guess it's mmul, but there is a lot of talk of some loosely related 
 implementation details. Column matrixes, slices, ndarrays... What? A lot of 
 implementation dependent info, almost no info on what I need (API).
 3. I read the mailing list and the source code, and, if I manage to filter 
 API information from a lot of implementation discussion I manage to draw a 
 rough sketch of what I need (API).
 4. I implement my algorithm with the default implementation (vectorz) and 
 it works. I measure the performance, and as soon as the data size becomes a 
 little more serious, it's too slow. No problem - pluggable implementations 
 are here. Surely that Clatrix thing must be blazingly fast, it's native. I 
 switch the implementations in no time, and get even poorer performance. 
 WHAT?
 5. I try to find help on the mailing list. I was using the implementation 
 in a wrong way. WHY? It was all right with vectorz! Well, we didn't quite 
 implemented it fully. A lot of functions are fallback. The implementation 
 is not suitable for that particular call... Seriously? It's featured on the 
 front page!
 6. But, what is the right way to use it? I want to learn. THERE IS NO 
 INFO. But, look at this, you can treat a Clojure vector as a quaternion and 
 multiply it with a JSON hash-map, which is treated as a matrix of 
 characters (OK, I am exaggerating, but not that much :)
 etc, etc... 
  

But it certainly isn't arbitrarily invented. Please note that we have 
 collectively considered

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Mikera]

On Saturday, 20 June 2015 08:43:39 UTC+1, Dragan Djuric wrote:

 On Friday, June 19, 2015 at 11:17:02 PM UTC+2, Christopher Small wrote:

 I see now Dragan; you're concerned not about whether easily implementing 
 and swapping in/out implementations of core.matrix is possible, but whether 
 it can be done while maintaining the performance characteristics of 
 Neanderthal, yes? That did not come through in your earlier comments in 
 this thread.


 This, with the addition that for *any* library, not only Neanderthal, 
 there would be many leaking abstractions. It is easy to define common 
 function/method names and parameters, but there are many things that just 
 flow through the API regardless, and taming this is the hardest part of any 
 API.

 


 Certainly, performance is one of those things that can leak in an 
 abstraction. But I'd like to echo Matt's enquiry: If you think a unified 
 API might be possible but that core.matrix isn't it, I think we'd all love 
 to hear what you think it's missing and/or what would would need to be 
 rearchitected in order for it to fit the bill.


 For an unified API, if it is at all feasible, I think there is one place 
 it should be looked at first: BLAS 1, 2, 3 and LAPACK. This is THE de facto 
 standard for matrix computations for dense and banded matrices. Sparse APIs 
 are not that uniform, bat in that space, also, there is a lot of previous 
 work. So, what's wrong with BLAS/LAPACK that core.matrix choose not to 
 follow it and arbitrarily invent (in my opinion) unintuitive and 
 complicated API? I am genuinely interested, maybe I don't see something 
 that other people do. 


There is nothing fundamentally wrong with BLAS/LAPACK, it just isn't 
suitable as a general purpose array programming API. See my comments 
further below.

If you think the core.matrix API is unintuitive and complicated then I'd 
love to hear specific examples. We're still open to changing things before 
we hit 1.0

But it certainly isn't arbitrarily invented. Please note that we have 
collectively considered a *lot* of previous work in the development of 
core.matrix. People involved in the design have had experience with BLAS, 
Fortran, NumPy, R, APL, numerous Java libraries, GPU acceleration, low 
level assembly coding etc. We'd welcome your contributions too but I 
hope you will first take the time to read the mailing list history etc. and 
gain an appreciation for the design decisions.

 


 In my opinion, the best way to create a standard API is to grow it from 
 successful implementations, instead of writing it first, and then 
 shoehorning the implementations to fit it.


It is (comparatively) easy to write an API for a specific implementation 
that supports a few specific operations and/or meets a specific use case. 
The original Clatrix is an example of one such library.

But that soon falls apart when you realise that the API+implementation 
doesn't meet  broader requirements, so you quickly get fragmentation e.g.
- someone else creates a pure-JVM API for those who can't use native code 
(e.g. vectorz-clj)
- someone else produces a similar library with a new API that wins on some 
benchmarks (e.g. Neanderthal)
- someone else needs arrays that support non-numerical scalar types (e.g. 
core.matrix NDArray)
- a library becomes unmaintained and someone forks a replacement
- someone wants to integrate a Java matrix library for legacy reasons
- someone else has a bad case of NIH syndrome and creates a whole new 
library
- etc.

Before long you have a fragmented ecosystem with many libraries, many 
different APIs and many annoyed / confused users who can't easily get their 
tools to work together. Many of us have seen this happen before in other 
contexts, and we don't want to see the same thing to happen for Clojure.

core.matrix solves the problem of library fragmentation by providing a 
common abstract API, while allowing users choice over which underlying 
implementation suits their particular needs best. To my knowledge Clojure 
is the *only* language ecosystem that has developed such a capability, and 
it has already proved extremely useful for many users. 

So if you see people asking for Neanderthal to join the core.matrix 
ecosystem, hopefully this helps to explain why.
 

  


 As for any sort of responsibility to implement core.matrix, I don't 
 think anyone is arguing you have such a responsibility, and I hope our 
 _pleading_ hasn't come across as such. We are simply impressed with your 
 work, and would like to take advantage of it, but also see a drawback you 
 don't: at present Neanderthal is less interoperable with many existing 
 tools, and trying it out on an existing project would require a rewrite 
 (as would migrating away from it if we weren't happy).

 Certainly, a third party library implementing core.matrix with 
 Neanderthal is a possibility, but I'm a bit worried that a) it would add 
 extra burden keeping things in sync and feel a little second class; 

Re: Question regarding java array

[Mikera]

Consider using core.matrix with vectorz-clj for operations on large 
numerical arrays / vectors of doubles. It is a *lot* faster than using 
Clojure vectors for this kind of scenario, plus it has a lot of helpful 
array operations already defined.

(use 'clojure.core.matrix)
(def v (array :vectorz (range 128)))

(time (emax v))
= 127.0
Elapsed time: 1.179533 msecs


On Wednesday, 10 June 2015 21:07:09 UTC+1, Ritchie Cai wrote:

 I'm working on a java array of double with 128 elements. I need the 
 max and min values of the array. So I initially tried areduce and loop, 
 both gives runs around 20 seconds. But when try (apply max (vec array)) I 
 get result under 90 ms.
 Can anyone explain why there is such a big difference?
 Also if want to iterate large java array like this to do some other 
 operations, e.g. convolution, what's the best way to go? Is there another 
 fast way to iterate through array or do I need to convert array into vector?

 Thanks
 Ritchie



-- 
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: non-incanter statistical tests?

[Mikera]

I intended the core.matrix.stats to be used as a lightweight library as 
for statistical functions of this nature, while remaining compatible with 
Incanter and core.matrix. I agree something more lightweight than the whole 
of Incanter is often required.

https://github.com/clojure-numerics/core.matrix.stats

Contributions welcome, possibly some could just be copy/pasted out of 
Incanter.



On Monday, 1 June 2015 21:49:53 UTC+1, Lee wrote:


 Does anyone know of a simple/minimal Clojure library, or just a chunk of 
 Clojure source code that I could cut/paste, that implements basic 
 statistical tests like t-tests and chi-squared tests? I don't want to use 
 incanter but I'd also rather not write this stuff from scratch. 

 Thanks, 

  -Lee 

 PS I'm not really looking to engage in debate about the pros/cons of 
 incanter, but FWIW a couple of my reasons for not wanting to use it are: 1) 
 Requiring incanter seems to be making my program launch an additional java 
 process, which is mysterious and unwelcome, 2) I ran into division by zero 
 errors which might be completely reasonable -- I haven't yet tracked down 
 the arguments that produced the errors or figured out what should be done 
 about them -- and when I tried to look into the code I found a lot more 
 complexity than I was hoping to have to deal with, along with the comment 
 ;;FIXME: This should never be *2!  This is wrong..., which does not 
 inspire confidence. I see that incanter does lots of cool things, and I 
 don't want to put it down in any way, but for now I just want some 
 statistical test code and I'd like to deal with as little else as possible. 



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

Controlling growth rates of generators with test.check

[Mikera]

Hi all,

I am doing some generative testing with test.check and need a way to 
control the growth rate of data structures (the regular linear growth 
quickly makes the computations too large for meaningful testing usage). I 
came up with the following solution to do this:

(defn gen-resize 
  Creates a generator that pre-modifies the 'size' pramater with the 
function f. Use if you want to 
   have the size grow at a different rate from the normal linear scaling.
  ([f gen]
(let [gf (or (:gen gen) gen paramter must be a test.check generator)
  new-gf (fn [rnd size]
   (gf rnd (f size)))]
  (clojure.test.check.generators.Generator. new-gf

Normal O(n) growth:

(gen/sample gen/s-pos-int 30)
= (1 2 3 2 4 5 4 7 6 3 3 7 10 4 8 11 14 12 6 10 9 1 8 21 12 16 25 25 21 6)

Controlled O(sqrt(n)) growth:

(gen/sample (gen-resize sqrt gen/s-pos-int) 30)
= (1 2 2 2 2 4 3 3 3 3 4 3 5 1 2 3 2 4 4 2 2 3 6 6 2 5 5 4 6 3)

So it seems to work, but is this a sane / recommended approach? Am I 
relying too much on test.check internals?

  mikera

-- 
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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mikera]

I agree that the problem is immutable/functional constructs per se., but I 
don't think the problem is the lack of VM support either. It is possible to 
get *very* fast code on the JVM.

In Clojure the issue is more that the dynamic nature of many Clojure 
constructs and lack of static type inference make it impossible for some of 
the more advanced JVM optimisations to be applied. This isn't really a VM 
problem, it is more of a compiler problem.

When I optimise Clojure code, I always get the feeling that I am doing 
something that a sufficiently smart compiler should be able to do 
(forcing use of primitives rather than boxed numbers, adding type hints 
etc.)

On Friday, 15 May 2015 03:01:57 UTC+8, tbc++ wrote:

 I think it false view that immutable/functional constructs are slow by 
 default. Instead, a lot of it comes down to lack of support in the popular 
 VMs for these constructs. For example the following code: 

 (defn add-fn [ args]
   (reduce -add 0 args))

 (loop [x 0]
   (if (eq x 1)
 x
 (recur (add-fn x 1

 Is never going to be super fast in Clojure, but it compiles down to a loop 
 with 4 assembly operations in Pixie (https://github.com/pixie-lang/pixie) 
 all while remaining fully dynamic. But that's because the VM is tuned to 
 optimize things like varargs and reduce. You can't really tap into the VM 
 at that level on the CLR or the JVM.

 That's not to say that Pixie is always faster than these platforms, on the 
 contrary, it's often much slower on GC heavy operations. But hopefully 
 someday we'll reach the holy grail of a VM that aggressively optimizes 
 dynamic languages without requiring hinting or rewriting into less 
 idiomatic forms. 

 Timothy

 On Thu, May 14, 2015 at 12:36 PM, Raoul Duke rao...@gmail.com 
 javascript: wrote:

 Ditto F# vs. C#.

 One has to wonder when / where / if functional-pure-immutable
 approaches will ever under the covers get fast enough?

 --
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mikera]

My general rule of thumb is that idiomatic Clojure is about 10x slower 
than Java. So this result doesn't really surprise me.

If you want to get maximum performance, you will have to do some more 
advanced / non-idiomatic things like:
- Add type hints for classes and primitive values
- Use deftype for your data structures
- Use loop/recur rather than more functional looping constructs
- Avoid laziness
- Use Java arrays for accumulating / mutating values
- Use Java classes like java.util.HashMap, java.util.ArrayList as 
appropriate

On Thursday, 14 May 2015 16:02:42 UTC+8, Amith George wrote:

 I wrote the following code to solve this challenge - 
 https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
 .

 Code - 
 https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj

 I executed the -main function using `lein run 1`. 

 Output

 ;; lein run 1

 0 12605919
 1 3578145
 2 15356894
 3 19134293
 4 2394558
 5 15030409
 6 6424953
 7 14893444
 8 1592254
 9 1914025
 10 7075106
 Elapsed time: 501168.972435 msecs

 The code originally used an immutable hashmap, but I lost patience waiting 
 for the computation to end. With mutable hashmap, it still takes around 8 
 mins.

 I wrote a C# version of the above code - 
 https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
 under 40secs. The C# exe was built under Release mode and executed directly 
 from the commandline. I expected the Clojure version to perform similarly.

 Any tips on what I am doing wrong?

 -
 Explanation of the code - Create a vector of all paper sheets, such that 
 the sheet placed last is the first element of the vector and the last 
 element is the canvas. To compute the frequency of each visible color - for 
 each point in the canvas find the first sheet in the vector that covers the 
 point. Store/increment its count in the hashmap. I understand there might 
 be better more efficient ways to solve this, but currently I am interested 
 in why the Clojure versions is so slow vis-a-vis the C# version.



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

[Mikera]

This is a great initiative. Would love to see an official community 
organisation.

Some things I think are particularly important on the content side:
a) Maintain and improve the clojure.org website as the front page for the 
community
b) Produce official user guides and documentation for Clojure (and key 
contrib libraries, as appropriate)
c) Maintain a curated list of recommend tools / libraries / frameworks 
 (ideally with some expert commentary on when they should be used). should 
include stuff like Ring etc.
d) Maintain a directory of links to other useful content (videos, 
tutorials, tools like cross-clj etc.) 

All of these I feel are very important for continued Clojure adoption. 
There are a lot of good resources already, but they are quite fragmented 
and difficult for a beginner to navigate. From the point of view of 
engaging the community to held develop all this content, I strongly believe 
an official organisation would be much more likely to attract good 
content contributions.

On the administrative and operational side, I think the organisation could 
take over some key tasks (I'm assuming the people who currently do this 
would be willing to either hand these over or become part of the 
organisation team):
a) Maintaining CLAs
b) Development process and tools (Github org, clojure-dev, JIRA etc.)
c) Conference sponsorship
d) Programmes like GSoC etc.

Just some ideas, hope they are useful!

On Wednesday, 29 April 2015 06:02:50 UTC+8, Daniel Solano Gómez wrote:

 Hello, all, 

 I've brought up the idea of some sort of Clojure community organisation 
 a few times on this mailing list.  The ideas is to help grow the Clojure 
 community by doing things like supporting GSoC students, run 
 infrastructure like Clojars, help run conferences, etc.  I have decided 
 to start moving forward and apply for fiscal sponsorship from the 
 Software Freedom Conservancy and Software in the Public Interest.  Those 
 things take time to work themselves out.  In the meantime, I appreciate 
 any input/feedback about what this org should do or what it should look 
 like.  As such, I have posted a page on the community wiki to start 
 braainstorming and discussing ideas 
 http://dev.clojure.org/display/community/Clojure+Community+Organisation. 


 A big thank you to everyone.  Participating in this community has been a 
 very positive experience for me, and I would love to see it to continue 
 to flourish.  I appreciate any help or advice on how to make this 
 initiative succeed in supporting the community. 

 Sincerely, 

 Daniel 


-- 
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: Wrapping org.apache.commons.math3.complex

[Mikera]

You often have to do bit of manual coercion to make things work nicely with 
the whole set of possible Clojure numerical types. Fortunately there are 
plenty of built-in functions in clojure.core to help you do this.

In your specific case I would do:

(.add (Complex. 1.0 2.0) (double 2)) 

This performs the coercion to the double type that you need for the Java 
interop. But the nice thing about the (double ...) is that it will handle 
not just longs but all other Clojure numerical types (ratios, bigints etc.)


On Saturday, 2 May 2015 19:53:12 UTC+8, Alan Forrester wrote:

 Hello 

 I'm currently trying to wrap org.apache.commons.math3.complex 


 http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
  

 to make a complex number library and I have a problem. Many of the 
 methods won't work with all Clojure number types. For example, 

 (.add (Complex. 1.0 2.0) 2) 

 produces an IllegalArgumentException. The method only works if at 
 least one of the arguments is a complex number although the other can 
 be a double. 

 What would be the best way of handling this? Should I just wrap add 
 the way it is and explain what types are expected in the 
 documentation, or is there a better way of dealing with this issue 
 that would allow Clojure number types to be used seamlessly? 

 Alan 


-- 
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: complex numbers in clojure

[Mikera]

You can do virtually all of that already with the Apache commons Complex 
class. Any Java object can be just fine used with map / reduce / filter / 
seqs etc.

If you want to avoid Java interop and make things more Clojure-like then 
a lightweight wrapper library is all that is needed (my suggestion b) ). 
You could probably also support tagged reader literals for complex numbers 
pretty easily.

The only problem would be supporting complex types in numerical 
clojure.core/+. That is very unlikely to happen - I doubt Rich and co want 
to start adding complexity to the core functions which would hurt 
performance and break the assumptions that people have about the numerical 
functions in clojure.core. But that isn't ultimately a big problem, you can 
just use a specialised addition operator like clojure.complex/+ or 
clojure.core.matrix.operators/+ instead when you write complex-using code. 
That's part of my suggestions b) and c), basically to have separate APIs 
that understand complex types.



On Tuesday, 28 April 2015 19:42:23 UTC+8, Nik wrote:

 
 What I would like is a complex type that plays well with Clojure's generic 
 abstractions and functional style (much like Ratio), and is 
 indistinguishable from other types - for example, the ability to work with 
 (map/reduce/filter), the ability to be a part of seqs and use Clojure core 
 functions on it, and so on. It might not as efficient as the complex type 
 in, say C++, but depending on your definition of reasonable, it might be 
 acceptable. I am willing to explore this further. 
 .






 On Tuesday, April 28, 2015 at 12:22:08 AM UTC-4, Mikera wrote:

 Complex numbers are tricky because:
 - They need to be fast in order to be useful for numerical computing. The 
 obvious implementations that you might create with boxed values, 
 vectors/maps, multimethods and protocols are likely to be unacceptable for 
 many use cases
 - You still want to be able to use them in a generic way, with operations 
 that play nicely with other values (Doubles etc.)

 I have thought about this a lot w.r.t. core.matrix and have come to the 
 conclusion that there is no simple, elegant answer that meets all use cases.

 What I'd like to suggest is:
 a) The community converge on a single, minimal, lightweight 
 representation for a boxed complex scalar value. This is probably best as a 
 Java class (for easy interop with Java libraries). I think 
 http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
  
 is a good candidate
 b) A lightweight wrapper library that provides nice complex functions in 
 Clojure, using the above type. Nothing fancy. But can make extensive use of 
 type hints etc. for performance so should be pretty fast
 c) A library using core.matrix that implements complex vectors, complex 
 matrices etc but also uses a) for complex scalar values. This should use a 
 underlying double-array backed implementation for performance, probably 
 vectorz-clj would be best (though that could be hidden as an implementation 
 detail). This library would also implement all the core.matrix protocols 
 for the chosen complex number type, mostly just by calling b) directly


 On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:

 I have been thinking along the lines of mikera and Maik - and it seems 
 like there is no further progress here? I would like to take a crack at 
 creating a complex number type, but implemented as a library to Clojure. I 
 am not sure where to start, and if anyone here has suggestions, I'd be 
 happy to hear them. 

 A complex number could simply be a vector of two elements, or a map with 
 :real and :imag keys (or something lightweight) - and I am not sure what it 
 would require to make this type work happily with code arithmetic functions 
 in Clojure and Java Math. 

 It would also have to work with seq operations in Clojure - for 
 instance: 
 If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2 
 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2 
 5). 

 I am having trouble figuring out all the pieces that need to be 
 implemented. Is it even possible to implement this as a library, or does 
 this need to be a part of clojure.core?



-- 
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: complex numbers in clojure

[Mikera]

Complex numbers are tricky because:
- They need to be fast in order to be useful for numerical computing. The 
obvious implementations that you might create with boxed values, 
vectors/maps, multimethods and protocols are likely to be unacceptable for 
many use cases
- You still want to be able to use them in a generic way, with operations 
that play nicely with other values (Doubles etc.)

I have thought about this a lot w.r.t. core.matrix and have come to the 
conclusion that there is no simple, elegant answer that meets all use cases.

What I'd like to suggest is:
a) The community converge on a single, minimal, lightweight representation 
for a boxed complex scalar value. This is probably best as a Java class 
(for easy interop with Java libraries). I 
think 
http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
 
is a good candidate
b) A lightweight wrapper library that provides nice complex functions in 
Clojure, using the above type. Nothing fancy. But can make extensive use of 
type hints etc. for performance so should be pretty fast
c) A library using core.matrix that implements complex vectors, complex 
matrices etc but also uses a) for complex scalar values. This should use a 
underlying double-array backed implementation for performance, probably 
vectorz-clj would be best (though that could be hidden as an implementation 
detail). This library would also implement all the core.matrix protocols 
for the chosen complex number type, mostly just by calling b) directly


On Monday, 27 April 2015 23:39:34 UTC+8, Nik wrote:

 I have been thinking along the lines of mikera and Maik - and it seems 
 like there is no further progress here? I would like to take a crack at 
 creating a complex number type, but implemented as a library to Clojure. I 
 am not sure where to start, and if anyone here has suggestions, I'd be 
 happy to hear them. 

 A complex number could simply be a vector of two elements, or a map with 
 :real and :imag keys (or something lightweight) - and I am not sure what it 
 would require to make this type work happily with code arithmetic functions 
 in Clojure and Java Math. 

 It would also have to work with seq operations in Clojure - for instance: 
 If I have a complex number c = {:real 3 :imag 4}, and a vector v = [1 -2 
 c], it would be nice to have the call 'map #(Math/abs %) v' produce (1 2 
 5). 

 I am having trouble figuring out all the pieces that need to be 
 implemented. Is it even possible to implement this as a library, or does 
 this need to be a part of clojure.core?


-- 
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, not the go to for data science

[Mikera]

On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:




 Sayth Renshaw flebbe...@gmail.com javascript: writes: 
  I last learned clojure in 1.2. Just curious why Clojure hasn't 
  developed as a go to for data science? 
  
  It never seems to get a mention R,Python and now Julia get the 
  attention. By design it would appear that Clojure would be a good fit. 
  Is it a lack of libraries, ease of install, no good default 
  environment (R Rstudio, IPython ) where as you would need to use emacs 
  with clojure, or is there just a better default use of Clojure? 


 I would say, lack of numpy or equivalent. And nice tools to link between 
 Clojure and the many C/Fortran numeric libraries. Python and R do this 
 natively. 


core.matrix is effectively the equivalent of NumPy

In some ways it is much more versatile, because it works with a general 
array abstraction rather than a specific concrete array format. There are 
core.matrix implementations (e.g. Clatrix) that link to native numerical 
libraries. There are also core.matrix implementations that run in pure, 
portable JVM code (e.g. vectorz-clj). You can also use plain old Clojure 
persistent vectors as a (slow but convenient) core.matrix implementation. 
Having all these options usable via the *same API* is a big win.

core.matrix is certainly not yet as mature or fully featured as NumPy. But 
if it doesn't do what you need - please help improve it! PRs, bug reports 
and enhancement ideas all gratefully accepted. 

https://github.com/mikera/core.matrix

There is also a Google Group here specifically dedicated to numerical 
topics in Clojure:

https://groups.google.com/forum/#!forum/numerical-clojure
 


 Maybe if Clojure pulls itself away from the JVM this will change. One 
 big problem with both python and R for data science is that a lot of 
 interactive data visualisation happens on the web these days, and 
 neither python nor R support that so well. An ecosystem with a C hosted 
 clojure at the back end and Clojure script at the front end might work 
 well. 


I agree Clojure is a great back-end for data-driven web applications. 

I would argue however that you don't need a C-hosted Clojure to get 
native back end performance since you can use tools like Clatrix to access 
BLAS etc. And aside from that, the JVM gives you a lot of big advantages on 
the server side (sophisticated memory management, excellent JIT 
compilation, concurrency, portability, library ecosystem etc.). I never 
quite understand the motivation of people who seem to want to reinvent all 
of this (probably badly) in native code. The JVM is an amazing piece of 
engineering, and I believe that a lot of the sucess of Clojure comes from 
taking advantage of this.

I've personally had good experiences with Clojure on the back end and 
JavaScript/ClojureScript on the front end, and never once worried about 
performance.
 

-- 
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 Culture Question on TDD

[Mikera]

Guess this is somewhat a personal perspective, but here are some thoughts 
on testing in Clojure:

- People do a lot of automated testing in general and there are some great 
testing libraries available (e.g. test.check)
- People tend not to strictly follow Test Driven Development practices. 
e.g. in my experience, tests are usually added after the fact (I think 
Rich's guard rail analogy is more a criticism of TDD rather than testing in 
general)
- Writing in idiomatic Clojure in functional style is a big plus for 
testing (much easier to test pure functions and immutable data structures).
- Lack of static typing is a big minus (you often have to write tests to 
verify properties that even a fairly simple static type system would have 
caught for you). core.typed may alleviate this, though at the cost of extra 
code and build complexity.
- There is some very good integration with the CI tools (CircleCI etc.) 
that you can take advantage of
- If you are trying to test whole systems with state, rather than just just 
individual bits of code, then you should look at the mocking capabilities 
in stuartsierra/component
- A lot of testing during development is done informally at the REPL. There 
is a risk that people get a bit lazy about converting these into proper 
tests later, but on average the convenience and quick feedback of REPL 
usage is a big win.

On Wednesday, 25 March 2015 10:53:44 UTC+8, Daniel Hinojosa wrote:

 What is TDD culture in Clojure like? Is it strong in the community and 
 other projects?  I am aware of Rich Hickey's guard rail analogy. Did that 
 have an effect on how Clojurists view TDD or testing in general? Just 
 asking for my own personal research.


-- 
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: Extend java class to participate in sequence operations

[Mikera]

In that case, I would suggest writing a minimal wrapper, either in Java or 
Clojure.

To get the basic sequence operations, you can simply implement the 
interface clojure.lang.ISeq on the wrapper.

On Wednesday, 18 March 2015 09:17:09 UTC+8, juvenn wrote:

 Thanks Niels, but what if a java class is not available for rewrite? Say, 
 it is from an external library.
  
 —
 Sent from Mailbox https://www.dropbox.com/mailbox 


 On Tue, Mar 17, 2015 at 10:01 PM, Niels van Klaveren 
 niels.va...@gmail.com javascript: wrote:

 If a java class implements Iterable, it automatically supports seq.

 On Tuesday, March 17, 2015 at 11:34:17 AM UTC+1, juvenn wrote:

  Dear all,

 Given a node type from singly linked list:

 class Node {
 int val;
 Node next;
 }

 How do I extend it so `(seq node)` will return a sequence of values? And 
 generally first, rest, and next will work on node too.

 While in Java, we could define the class to implement Iterable to 
 achieve this. In Clojure we do have `extend-type`, but it seems not 
 accepting interfaces to extend, nor do I find protocol for seqable.

 So generally, given a class defined in Java, assuming it is not 
 available for rewrite, how shall we extend the class to participate in 
 sequence operations in Clojure?

 Thanks in advance!
  
 —
 Sent from Mailbox https://www.dropbox.com/mailbox 
  
  -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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: Core Matrix Dot Product

[Mikera]

I posted some answers on the GitHub issue:
https://github.com/mikera/core.matrix/issues/228

But in short, you should use one of the optimised implementations if you 
care about performance. Clojure vectors are very flexible, but aren't 
really designed for numerical performance. vectorz-clj for example should 
be pretty good for your needs:

(let [v (array :vectorz [5 5 5 5 5 5 5 5 5 5])]
 (time (dotimes [i 80] (dot v v))) )Elapsed time: 22.990836 msecs


On Saturday, 14 March 2015 19:10:58 UTC+8, Byan Jati wrote:

 hello there, i want to ask about core.matrix dot product performance, is 
 there a technique to optimize dot-product function ? 

 Because i found that in Java, C, or even in HipHipArray library, the dot 
 product performance is extremely faster than core matrix dot product. I 
 conduct a little benchmark by looping the dot product function until 80 
 steps, and i found in Java = 12 ms, C = 22 ms, and core.matrix = 1300 ms ( 
 if using core.matrix.dot ), if using hiphip array in clojure, i found its 
 resulting 300 ms for 80 iteration dot-product. 

 Actually i want to use hiphip array and core matrix when executing the 
 core.matrix.dot-product, but the function dot-product demanding 
 double-array format for the input, which is also bottleneck process for 
 core.matrix because the row of matrix should be cast into double-array form 
 before running dot-product. 


-- 
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] Pink 0.1.0, Score 0.2.0

[Mikera]

Looks cool, thanks for sharing!

Not sure how useful it is, but I wrote some code and a blog post a while 
back about doing spectrograms in Clojure:

https://clojurefun.wordpress.com/2013/12/22/spectrograms-with-overtone/

On Monday, 9 March 2015 02:36:27 UTC+8, Steven Yi wrote:

 Hi All, 

 I'd like to announce the release of Pink 0.1.0 and Score 0.2.0: 

 [kunstmusik/pink 0.1.0] 
 [kunstmusik/score 0.2.0] 

 Pink is an audio engine library, and Score is a library for 
 higher-level music representations (e.g. notes, phrases, parts, 
 scores). 

 For more information, please see the projects' docs at: 

 http://github.com/kunstmusik/pink 
 http://github.com/kunstmusik/score 

 and examples of using both at: 

 http://github.com/kunstmusik/music-examples 

 To note, this is the first stable version of Pink.  I got into a bit 
 of let me add just one more feature... but decided it was time 
 enough to issue a release. Score's changes since 0.1.0 are primarily a 
 better organization of files, as well as organizing music into 
 measured and/or timed scores.  See [1] for an example of measured 
 score use. 

 Next steps planned for Pink are some more unit generators (i.e. comb 
 filter, convolution) and effects (i.e. reverbs). Next steps planned 
 for Score are currently just adding Xenakis-style sieves.  I've also 
 been using plotting code enabled as a separate Leiningen profile in 
 Pink, which I am planning to move to an additional library 
 (tentatively called pink-viz).  The plans for pink-viz are to collect 
 useful functions for helping to write unit generators (i.e. 
 oscilloscope, bode plot, FFT spectrogram). 

 Thanks! 
 steven 

 [1] - 
 https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/track1.clj#L263
  


-- 
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]: Octet 0.1.0: A Clojure(Script) library for working with binary data.

[Mikera]

Thanks for sharing Andrey!

Could you comment on how this compares with: 
https://github.com/ztellman/byte-streams 

Are the two complementary? Replacements?

On Monday, 2 March 2015 03:58:57 UTC+8, Andrey Antukh wrote:

 Hi!

 I'm happy to announce the first version of Octet library.

 _octet_ library offers, not intrusive (without additional wrapping), 
 composable and host independent abstraction for working with binary data.

 It works out of the box with NIO ByteBuffer, Netty ByteBuf, and ES6 
 TypedArrays (clojurescript).

 Github: https://github.com/funcool/octet
 Documentation: http://funcool.github.io/octet/latest/

 Cheers.
 Andrey
 -- 
 Andrey Antukh - Андрей Антух - andrei@kaleidos.net javascript: / 
 ni...@niwi.be javascript:
 http://www.niwi.be http://www.niwi.be/page/about/
 https://github.com/niwibe
  

-- 
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: can binary arithmetic guru help improve these bitmasking ops?

[Mikera]

Bit operations is one area where I'd actually recommend writing in Java 
before wrapping in Clojure for several reasons:
1) You can port / compare directly with canonical C implementation
2) You can be pretty sure of avoiding boxing / other overheads by sticking 
to Java primitive maths
3) Clojure still doesn't quite have the full range of bitwise functionality 
as far as I'm aware

Feel free to use any of my Java bitwise code, if helpful:
https://github.com/mikera/mikera/blob/master/src/main/java/mikera/util/Bits.java

On Tuesday, 24 February 2015 02:59:32 UTC+8, danl...@gmail.com wrote:

 So, much of the pain involved in handling UUID's correctly on the JVM
 relates to the fact that there is no primitive unsigned numeric type
 that can represent the full range of possible values of the msb and lsb.
 Ie., we need to always deal with the unpleasant am I negative? approach 
 to
 reading (writing) that 64th bit.  To avoid the complexity of all the 
 edge cases, we encapsulate the basic primitives of working with
 unsigned numbers entirely within the abstraction of mask and
 mask offset.  Using these, we built the two fundamental bitwise 
 operations
 that are used for most of the UUID calculation: ldb (load-byte) and
 dpb (deposit-byte).

 This scrap of code from my clj-uuid.bitmop library is extremely useful for 
 working 
 with unsigned long/binary values (analogously to how one might using the 
 common-lisp
 functions by the same name).  And, it has been good enough to do pretty 
 well
 so far in terms of performance.  But I'm sure that there are gifted 
 binariticians
 in the audience that can improve this. (Note, the namespace uses 
 ztellman/primitive-math
 which changes the semantics of some arithmetic operations and some type 
 hinting.  Also
 some of the 'let's are there for that reason. It may be helpful to refer 
 to the link.

 ;;; 
 https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/bitmop.clj


 (defn ^long expt2 [^long pow]
   (bit-set 0 pow))

 (defn ^long mask [^long width ^long offset]
   (if ( (+ width offset) 64)
 (bit-shift-left (dec (bit-shift-left 1 width)) offset)
 (let [x (expt2 offset)]
   (bit-and-not -1 (dec ^long x)

 (declare ^long mask-offset ^long mask-width)

 (defn ^long mask-offset [^long m]
   (cond
 (zero? m) 0
 (neg?  m) (- 64 ^long (mask-width m))
 :else (loop [c 0]
 (if (pos? (bit-and 1 (bit-shift-right m c)))
   c
   (recur (inc c))

 (defn ^long mask-width [^long m]
   (if (neg? m)
 (let [x (mask-width (- (inc m)))]
   (- 64  ^long x))
 (loop [m (bit-shift-right m (mask-offset m)) c 0]
   (if (zero? (bit-and 1 (bit-shift-right m c)))
 c
 (recur m (inc c))

 (defn ^long ldb
   Load Byte
   [^long bitmask ^long num]
   (let [off (mask-offset bitmask)]
 (bit-and ( bitmask ^long off)
   (bit-shift-right num off

 (defn ^long dpb
   Deposit Byte
   [^long bitmask ^long num ^long value]
   (bit-or (bit-and-not num bitmask)
 (bit-and bitmask
   (bit-shift-left value (mask-offset bitmask)


-- 
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: Performant string concatenation (of many, large strings)

[Mikera]

If you really care about performance then I would use a macro for code 
generation and do something the following:

(defmacro appendfunc 
 ([m keys sb]
   `(do
  (.append ~sb (~m ~(first keys)))
  ~@(for [k (next keys)]
  `(do 
 (.append ~sb \,)
 (.append ~sb (~m ~k
  (.append ~sb \n

(let [sb (StringBuilder.)
 f (fn [^StringBuilder sb m] (appendfunc m [:one :two :three :four] 
sb))
 maps (repeat 25 {:one 1 :two 2 :three 3 :four 4})]
 (time (let [res (str (reduce f sb maps))] (count res

= Elapsed time: 118.105355 msecs

Could probably optimise a bit more but that's under 400ns per row... pretty 
decent I think.


On Thursday, 12 February 2015 09:25:12 UTC+8, Mark Watson wrote:

 I'm looking for the most performant way to transform a huge seq (size 
 25) of maps into a single CSV.

 The data structure looks something like:

 (def data-struct

   (repeat 25 {:one 1 :two 2 :three 3 :four 4}))


 A naive implementation would be:

 (let [f #(- % (map (comp str val)) (clojure.string/join ,))]

   (- data-struct

 (map f)

 (clojure.string/join \n)))


 However, this takes far too long for my application (an the order of 10s 
 of seconds).

 Another attempt using reducers:

 (require '[clojure.core.reducers :as r])

  

 (let [f #(- % (map (comp str val)) (clojure.string/join ,))

   r-join (fn

([] nil)

  ([x y]

   (if (and x y) (str x \n y)

 (if x (str x)

   (if y (str y))]

   (- data-struct

 (r/map f)

 (r/fold r-join)))


 Still not great.

 But, Looking at the sources of clojure.string/join and clojure.core/str, 
 it becomes apparent that the both implementations create an instance of 
 java.lang.StringBuilder 
 for each element in the sequence. (I have to imagine this is the main 
 issue, even though GC seems to only be ~5% of the runtime)

 Would it make sense to instantiate one java.lang.StringBuilder for all of 
 the concatenation (and call java.lang.StringBuilder append)?

 What's the best way to do this with idiomatic Clojure?

 Thanks a lot!


-- 
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: if-not implementation

[Mikera]

Interesting -  there seems to be a very slight performance advantage to 
your version on my machine (consistently about 25% faster for if-nots in a 
tight loop).

I think the problem is actually with not - which isn't getting inlined 
currently. If I patch not so that it is inlined, the difference disappears.

Worth a quick patch maybe?

On Thursday, 22 January 2015 03:51:37 UTC+8, Leon Grapenthin wrote:

 I am surprised to find the two branch implementation of if-not as follows:


 ([test then else]
`(if (not ~test) ~then ~else))


 What I expected was:


 ([test then else]
`(if ~test ~else ~then))



-- 
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 for Desktop UI Design Application

[Mikera]

I'd be pretty interested in this too. Though not quite enough to write it 
myself (I've made good enough interfaces with Swing interop).

The thought occurs that there may be quite a bit of common code that could 
be shared with respect to diffing / cursors etc. that would work equally 
well for Om, JavaFX2, maybe also some OpenGL rendering. This similarity 
might even be exploited to build re-targetable GUI code. OK I'll stop 
speculating now

On Wednesday, 14 January 2015 00:05:40 UTC+8, tbc++ wrote:

 I've long thought that the Clojure world needs a JavaFX/React hybrid. 
 JavaFX2's API is extremely consistent, making it quite easy to program 
 against, but yes it still requires bindings and in-place mutation. 

 However a React-like diff-ing engine on it would be quite impressive. But 
 now you're into the fun land of writing a library in order to write your 
 app. 

 On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates colin...@gmail.com 
 javascript: wrote:

 Wow, there is a lot to deal with :), so let me throw out some ideas:
  - have you considered building a web-app instead of a desktop app? If 
 so, have a look at one of the react based languages (om or reagent would be 
 my choice). Alternatively take a look at other 
 http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. 

 It is a different way of working, but its programming model restricts you 
 in a way that removes many problems (if you see what I mean).

 Also, I would be reaching for an in-memory database (assuming a server 
 isn't involved) about now, datatomic would be the obvious choice.

 I don't think what you are trying to do is stupid, I do think you might 
 want to do some thought experiments about different architectures and 
 paradigms (specifically FRP related paradigms).

 Oh, and have a quick scan through http://swannodette.github.io/, there 
 are a few mind-changing posts.

 On Monday, 12 January 2015 18:53:07 UTC, MS wrote:

 (Cross-posted on StackOverflow)

 I'm trying to design a desktop UI for schematics, layout, drawing 
 stuff.  Just looking for high level advice from actual software designers.

 Assuming an in-memory database, (clojure map of arbitrary depth for 
 all user data, and possibly another one for application preferences, etc.), 
 I'm examining how to do the model-view-controller thing on these, where the 
 data may be rendered *and modified by* any one or more of:

  1. A standalone text field that shows a single parameter, such as box 
 width.
  2. An inspector type of view that shows multiple parameters of a 
 selected object, such as box width, height, color, checkboxes, etc.
  3. A table/spreadsheet type of view that shows multiple parameters of 
 multiple objects, potentially the whole database
  4. A graphical rendering of the whole thing, such as both schematic and 
 layout view.

 Modifying any one of these should show up immediately in every other 
 active view, both text and graphical, not after clicking ok... so no 
 modal boxes allowed.  If for some reason the table view, an inspector view, 
 and a graphical rendering are all in view, dragging the corner of the box 
 graphically should immediately show up in the text, etc.

 The platform in question is JavaFX, but I'd like a clean separation 
 between UI and everything else, so I want to avoid `bind`ing in the JFX 
 sense, as that ties my design data very tightly to JFX Properties, 
 increases the graininess of the model, and forces me to work outside the 
 standard clojure functions for dealing with data, and/or deal heavily with 
 the whole `getValue`/`setValue` world.

 I'm still assuming at least *some* statefulness/mutability, and the use 
 of built-in Clojure functionality such as the ability to `add-watch` on an 
 atom/var/ref and let the runtime signal dependent functions.

 Platform-specific interaction will rest tightly with the actual UI, such 
 as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., 
 and will attempt to minimize the reliance on things like JavaFX `Property` 
 for actual application data.  I'm not entertaining FRP for this.  

 I don't mind too much extending JFX interfaces or making up my own 
 protocols to use application-specific `defrecord`s, but I'd prefer for the 
 application data to remain as straight Clojure data, unsullied by the 
 platform.

 The question is how to set this all up, with closest adherence to the 
 immutable model and minimal (or well-bounded) dependence on JFX.  I see a 
 few options:

  1. Fine-grain: Each parameter value/primitive (ie Long, Double, 
 Boolean, or String) is an atom, and each view which can modify the value 
 reaches in as far as it needs to in the database to change the value.  
 This could suck as there could potentially be thousands of individual 
 values (for example points on a hand-drawn curve), and will require lots of 
 `(deref...)` junk.  I believe this is how JFX would want to do this, with 
 giant arrays of Properties at the leaf 

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Mikera]

It works for the development branch of Incanter 2.0 - which is a pretty 
significant project with a lot of matrix code. You can switch between 
Clatrix (native BLAS via JBlas), persistent vectors (regular Clojure 
vectors) and vectorz-clj (pure JVM code) transparently. 

I think it would be the same for Neanderthal - I don't see anything that 
would be inconsistent with core.matrix from an API perspective.

On Wednesday, 14 January 2015 05:38:22 UTC+8, Dragan Djuric wrote:

 It would be nice if that would be that easy. However, I am sceptical...

 On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote:

 Awesome project!

 I'll echo the encouragement towards having Neanderthal implement the 
 core.matrix protocols. You'll have much higher adoption if folks know they 
 can just plug your tool in by changing a single line setting the underlying 
 implementation to Neanderthal. And as Mikera points out, it would be nice 
 if we kept the Clojure matrix API space cohesive.



-- 
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.7.0-alpha5 now available

[Mikera]

It seems a little odd that there is an ArrayList override but not List. 
Presumably that is there as an optimisation since ArrayList is such a 
common case?

It seems to have happened in this commit for CLJ-1546, which replaces the 
List override with ArrayList
https://github.com/clojure/clojure/commit/4afd4a7c14c48b5baf3c03196053066483cb4223

I'd probably recommend keeping the old List override around: it is more 
general, potentially useful for Interop and will help avoid breakage like 
this (even if it is just an implementation detail).

On Monday, 12 January 2015 17:43:09 UTC+8, Rangel Spasov wrote:

 Hey guys,

 I noticed that PersistentVector.create() is missing one arity that used to 
 exist before:

 PersistentVector.create(List items)

 ... which caused this library 
 https://github.com/ninjudd/clojure-protobuf/blob/develop/src/flatland/protobuf/PersistentProtocolBufferMap.java#L479
  
 to throw

 NoSuchMethodError 
 clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector;
  

 I can fix the library, I don't think it will be a big problem, just making 
 sure that's something you guys were OK with breaking - it's more like an 
 implementation detail as far as I can see. 

 Thanks,
 Rangel
 @raspasov

 On Sunday, January 11, 2015 at 6:34:07 AM UTC-8, Alex Miller wrote:

 I would greatly appreciate hearing any feedback about this (or any other) 
 alpha, even if it's just: everything looks ok. 

 We've had a couple of regressions reported and that is hugely helpful as 
 we can quickly turn around fixes for the next one.   

 Interested particularly in: regressions, performance +/-, and for this 
 alpha, AOT.



-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Mikera]

Looks cool Dragan, thanks for sharing!

I would strongly encourage you to wrap this up and make it work as a 
core.matrix implementation. That would considerably improve 
interoperability with other libraries / tools in the Clojure numerical 
space e.g. it could be used as a drop-in replacement for Clatrix in 
Incanter 2.0 for example.

The work to do this is fairly simple - you just need to implement a few 
mandatory protocols from clojure.core.matrix.protocols. Most of the 
protocols are optional: you only need to implement them if you want to 
provide a high performance override of the default behaviour.

I'm particularly keen that we avoid API fragmentation in the Clojure 
numerical space (this has plagued many other language communities, e.g. 
Java). If every such library comes with its own API, then we won't be able 
to build a strong ecosystem of composable tools (which is in my view pretty 
fundamental to the Clojure style of development)

Some quick thoughts on the benchmarks:
a) I'm quite pleased to see that my little pure-Java matrix multiplication 
implementation comes within an order of magnitude of BLAS/ATLAS :-) thanks 
for giving me some further improvements to target!
b) It looks like you are consistently about 2x faster than JBlas for large 
matrices - wondering what is causing the difference, is that because of 
copying?
c) Would be interesting to see a few other operations: I do a lot of work 
with stochastic gradient descent for example so addition and 
multiply-and-add can be even more important than matrix multiply.


On Tuesday, 13 January 2015 09:13:13 UTC+8, Dragan Djuric wrote:

 I am pleased to announce a first public release of new *very fast *native 
 matrix and linear algebra library for Clojure based on ATLAS BLAS.
 Extensive *documentation* is at http://neanderthal.uncomplicate.org
 See the benchmarks at 
 http://neanderthal.uncomplicate.org/articles/benchmarks.html.

 Neanderthal is a Clojure library that 

 Main project goals are:

- Be as fast as native ATLAS even for linear operations, with no 
copying overhead. It is roughly 2x faster than jBLAS for large matrices, 
and tens of times faster for small ones. Also faster than core.matrix for 
small and large matrices!
- Fit well into idiomatic Clojure - Clojure programmers should be able 
to use and understand Neanderthal like any regular Clojure library.
- Fit well into numerical computing literature - programmers should be 
able to reuse existing widespread BLAS and LAPACK programming know-how and 
easily translate it to Clojure code.

 Implemented features

- Data structures: double vector, double general dense matrix (GE);
- BLAS Level 1, 2, and 3 routines;
- Various Clojure vector and matrix functions (transpositions, 
submatrices etc.);
- Fast map, reduce and fold implementations for the provided 
structures.

 On the TODO list

- LAPACK routines;
- Banded, symmetric, triangular, and sparse matrices;
- Support for complex numbers;
- Support for single-precision floats.


 Call for help:
 Everything you need for Linux is in Clojars. If you know your way around 
 gcc on OS X, or around gcc and MinGW on Windows, and you are willing to 
 help providing the binary builds for those (or other) systems, please 
 contact me. There is an automatic build script, but gcc, atlas and other 
 build tools need to be properly set up on those systems.



-- 
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: maya - A DSL for math and numerical stuff

[Mikera]

Very nice!

People interested in this topic may also be interested in Expresso, which 
supports analysis / transformation of mathematically expressions in Clojure:
https://github.com/clojure-numerics/expresso

Extra features I would personally find interesting in this space:
- Ability to use array-values expressions (e.g. matrix maths) via 
core.matrix
- The ability to simplify / optimise expressions (expresso can do this)
- The ability to compile expressions for different targets (GPU, native, 
core.matrix implementation stc.)



On Thursday, 8 January 2015 02:29:10 UTC+8, Divyansh Prakash wrote:

 maya - A DSL for math and numerical stuff.

 https://gist.github.com/divs1210/b4fcbd48d7697dfd8850#file-maya


-- 
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: Clatrix Multiplication Matrix

[Mikera]

You have probably either hit a Clatrix bug or have some kind of version 
mismatch with core.matrix - could you file an issue with the exact version 
numbers you are using and code to 
reproduce: https://github.com/tel/clatrix/issues ?

Note that * in clojure.core.matrix.operators is for element-wise 
multiplication (multiply corresponding elements in an array), not 
inner-product (matrix multiplication). You want mmul or inner-product 
for traditional style matrix multiplication.

On Sunday, 4 January 2015 19:12:43 UTC+8, Byan Jati wrote:

 I have 2 matrix, matrix A = [[1 2 3][4 5 6]] and matrix B = [[10 20][20 
 30][30 40]], 2 x 3 and 3 x 2 matrix.

 The problem is, when i use core.matrix.operator to Multiply those matrix, 
 i got these result :

 (M/* A B)

 [[10 60 120] [120 100 240]]

 which the true result is [[140 200] [320 470]]

 and when using mmul, the clatrix matrix resulting an error. do anyone 
 know how to perform multiplication using clatrix matrix?


-- 
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: lazy-seq performance

[Mikera]

A few comments:

Your two pieces of code aren't really equivalent:
a) The Python code is just calculating a fibonacci number in a brute force 
iterative loop.
b) The Clojure code is creating a big (infinite, lazy) data structure of 
all fibonacci numbers, lazily realising the structure in memory and running 
along the list until it finds the one that you want. That is a lot more 
work

The equivalent in Clojure to the python code would use loop / recur and 
look something like:
(defn fib
  ([n] (fib 0 1 n))
  ([a b n]
(if (= n 0) a
  (recur b (+' a b) (dec n)

Note the +' (with the tick) for arbitrary precision addition.

But mostly, I think you aren't benchmarking lazy seq performance at all: 
the dominant runtime cost of this code is almost certainly the BigInt 
addition with large numbers, not the iteration / realisation of sequences.

On Thursday, 1 January 2015 04:03:03 UTC+8, Sakis K wrote:

 Hi,

 Clojure newbie here :) I'm reading Programming Clojure by Halloway and 
 Bedra. In the book there is a lazy-seq example of the Fibonacci sequence:

 (defn lazy-seq-fibo
   ([]
  (concat [0 1] (lazy-seq-fibo 0N 1N)))
   ([a b]
  (let [n (+ a b)]  
(lazy-seq   
 (cons n (lazy-seq-fibo b n))


 I like the flexibility of this implementation but I am a bit sceptical 
 about its performance:

 user= (time (rem (nth (lazy-seq-fibo) 100) 1000))
 Elapsed time: 53552.014713 msecs
 875N



 Here's a Python implementation taken from 
 http://en.literateprograms.org/Fibonacci_numbers_%28Python%29

 def fib(n):
 a, b = 0, 1
 for i in range(n):
 a, b = b, a + b
 return a

 if __name__ == '__main__':
 print(fib(100) % 1000)


 time python fib.py 
 875

 real0m16.609s
 user0m16.475s
 sys 0m0.115s


 53 vs 17 seconds is a big gap. Is there a way to achieve better 
 performance in Clojure? Maybe the fact that I executed the code in the REPL 
 or the Java version that I'm using matters:
 java -version
 java version 1.7.0_65
 OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu1)
 OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)



-- 
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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Mikera]

I'm trying to figure out how to get core.matrix to load much faster - I 
think it's actually some kind of Clojure issue with protocols but I'm not 
*exactly* sure what is causing

On Tuesday, 30 December 2014 05:13:24 UTC+8, Jony Hudson wrote:

 @Mike Thinking out loud here ... one option would be to put the 
 core.matrix dependent stuff in gg4clj in a separate ns, like 
 gg4clj.datasets or similar. This would then avoid the loading time for 
 users just wanting to use gg4clj.core. I'm not sure I think this as good a 
 solution, ultimately, as trying to make core.matrix load in a more 
 incremental fashion -  but I do appreciate that it's not so easy to change 
 core.matrix, and that there are good reasons not to. What do you think - 
 does this sound like a reasonable way forward to you? 


 Jony


-- 
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: how do you name your protocols?

[Mikera]

I tend to agree.

However it is worth noting that there are some libraries in the Clojure 
ecosystem e.g. Om and stuartsierra/component that do expect users to 
interact directly with protocols as part of the public API. So this doesn't 
seem to be yet adopted as a universal rule.

On Sunday, 28 December 2014 15:50:06 UTC+8, Jozef Wagner wrote:

 Protocols should never ever be part of public API. Protocols can be part 
 of the SPI, if custom extensions are to be supported. Otherwise they are an 
 implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968

 Jozef

 On Sun, Dec 28, 2014 at 8:11 AM, Mikera mike.r.an...@gmail.com 
 javascript: wrote:

 That depends if the protocols are part of your user-facing API or not - a 
 lot of the time I find that protocols are best hidden as implementation 
 details rather than exposed to users.

 In core.matrix, for example, users never see the protocols directly: only 
 implementers of new matrix libraries need to care

 On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:

 Changing old protocol names should trigger a major revision change in 
 the minimum because it breaks backwards compatibility. 

 --Ashton 

 Sent from my iPhone 

  On Dec 27, 2014, at 11:18 AM, Michael Klishin michael@gmail.com 
 wrote: 
  
  On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) 
 wrote: 
  clj-time seems to be naming protocols inconsistently. It uses   
  ISomething, Something and SomethingProtocol naming. 
  
  I suspect it is because it has 60 contributors and most users never 
 have to 
  extend the protocols. 
  
  Feel free to submit a PR that standardises all names on Something. 
  --   
  @michaelklishin, github.com/michaelklishin 
  
  -- 
  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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Mikera]

core.matrix isn't that big of a dependency itself - it only gets expensive 
in/when you load the implementations (NDArray, vectorz-clj, Clatrix etc.). 
Which should be a choice of the ultimate user.

It is possible to just depend on the protocols, but I think that risks 
breakage since protocols are really just an implementation detail. Best to 
depend on the API in clojure.core.matrix (which are mostly just simple 
functions that delegate to the right protocols)

On Sunday, 28 December 2014 23:42:18 UTC+8, Jony Hudson wrote:

 @Chris Thanks, hope it's useful for you. I might have a play with ggvis 
 and see how it works out.

 @Mike Yeah, it would definitely be good to support core.matrix datasets. 
 One thing that would be nice would be to avoid the overhead of loading all 
 of core.matrix for those that don't use it. Do you think it would work to 
 just have gg4clj depend on the 'protocols' ns in core.matrix? Would be very 
 happy to take a PR if you've got time to look at it :-)


 Jony

 On Friday, 26 December 2014 15:36:42 UTC, Jony Hudson wrote:

 Hi all,

  from the README:

 gg4clj is a lightweight wrapper to make it easy to use R's ggplot2 
 library from Clojure. It provides a straightforward way to express R code 
 in Clojure, including easy mapping between Clojure data and R's data.frame, 
 and some plumbing to send this code to R and recover the rendered graphics. 
 It also provides a Gorilla REPL renderer plugin to allow rendered plots to 
 be displayed inline in Gorilla worksheets. It is not a Clojure rewrite of 
 ggplot2 - it calls R, which must be installed on your system (see below), 
 to render the plots. You'll need to be familiar with R and ggplot2, or else 
 the commands will seem fairly cryptic.


 Demo worksheet, showing it in action here: 
 http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=gg4cljpath=ws/demo.clj
 Source here: https://github.com/JonyEpsilon/gg4clj

 Works better than I thought it would!


 Jony



-- 
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] gg4clj 0.1.0 - ggplot2 in Clojure and Gorilla REPL

[Mikera]

Very cool!

On the data representation front, would you be open to making it support 
the core.matrix Dataset protocols as well as regular Clojure maps? That 
would make it much easier to integrate with Incanter 2.0 etc., and 
potentially avoid some copying overhead.

It should be a simple change to the data-frame function, happy to send 
you a PR if that is a direction you want to go.

On Friday, 26 December 2014 23:36:42 UTC+8, Jony Hudson wrote:

 Hi all,

  from the README:

 gg4clj is a lightweight wrapper to make it easy to use R's ggplot2 library 
 from Clojure. It provides a straightforward way to express R code in 
 Clojure, including easy mapping between Clojure data and R's data.frame, 
 and some plumbing to send this code to R and recover the rendered graphics. 
 It also provides a Gorilla REPL renderer plugin to allow rendered plots to 
 be displayed inline in Gorilla worksheets. It is not a Clojure rewrite of 
 ggplot2 - it calls R, which must be installed on your system (see below), 
 to render the plots. You'll need to be familiar with R and ggplot2, or else 
 the commands will seem fairly cryptic.


 Demo worksheet, showing it in action here: 
 http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=gg4cljpath=ws/demo.clj
 Source here: https://github.com/JonyEpsilon/gg4clj

 Works better than I thought it would!


 Jony


-- 
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: how do you name your protocols?

[Mikera]

That depends if the protocols are part of your user-facing API or not - a 
lot of the time I find that protocols are best hidden as implementation 
details rather than exposed to users.

In core.matrix, for example, users never see the protocols directly: only 
implementers of new matrix libraries need to care

On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote:

 Changing old protocol names should trigger a major revision change in the 
 minimum because it breaks backwards compatibility. 

 --Ashton 

 Sent from my iPhone 

  On Dec 27, 2014, at 11:18 AM, Michael Klishin michael@gmail.com 
 javascript: wrote: 
  
  On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com 
 javascript:) wrote: 
  clj-time seems to be naming protocols inconsistently. It uses   
  ISomething, Something and SomethingProtocol naming. 
  
  I suspect it is because it has 60 contributors and most users never have 
 to 
  extend the protocols. 
  
  Feel free to submit a PR that standardises all names on Something. 
  --   
  @michaelklishin, github.com/michaelklishin 
  
  -- 
  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 
 javascript: 
  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 javascript: 
  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 javascript:. 
  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: gemacl: Scientific computing application written in Clojure

[Mikera]

For most array operations (e.g. dot products on vectors), I strongly 
recommend trying out the recent core.matrix implementations. We've put a 
lot of effort into fast implementations and a nice clean Clojure API so I'd 
love to see them used where it makes sense!

For example vectorz-clj can be over 100x faster than a naive map / reduce 
implementation:

(let [a (vec (range 1))
   b (vec (range 1))]
(time (dotimes [i 100] (reduce + (map * a b)
Elapsed time: 364.590211 msecs

(let [a (array :vectorz (range 1))
  b (array :vectorz (range 1))]
(time (dotimes [i 100] (dot a b
Elapsed time: 3.358484 msecs

On Monday, 22 December 2014 17:31:41 UTC+8, Henrik Eneroth wrote:

 Interesting read Jose, thanks!

 It might be interesting to try a transducer on 

 (defn dot-prod 
   Returns the dot product of two vectors
   [v1 v2]
   (reduce + (map * v1 v2)))

 if you can get your hands on the 1.7 alpha and the time and inclination to 
 do it. Transducers have shown to be faster than running functions in 
 sequence. Although I don't know how likely they are to beat native arrays, 
 probably not very much.


 On Sunday, December 21, 2014 7:10:41 PM UTC+1, Jose M. Perez Sanchez wrote:


 Regarding the speed optimizations, execution time for a given model was 
 reduced from 2735 seconds to 70 seconds, over several versions by doing 
 several optimizations.

 The same calculation implemented in C# takes 12 seconds using the same 
 computer and OS. Maybe the Clojure code can still be improved, but for the 
 time being I'm happy with the Clojure version being six times slower, since 
 the new software has many advantages.

 For these tests the model was the circle with radius 1 using the 
 diffmr1 tracker, the simulation was run using 1 particles and 1 
 total random walk steps.

 These modifications in the critical parts of the code accounted for most 
 of the improvement:

 - Avoid reflection by using type hints.
 - Use Java arrays.
 - In some cases call Java arithmetic functions directly instead of 
 Clojure ones.
 - Avoid using partial functions in the critical parts of the code.

 Avoiding lazyness did not help much. Regarding the use of Java arrays, 
 there are many small functions performing typical vector operations on 
 arrays, such as the following example:

 Using Clojure types:

 (defn dot-prod 
   Returns the dot product of two vectors
   [v1 v2]
   (reduce + (map * v1 v2)))

 Using Java arrays:

 (defn dot-prod-j
   Returns the dot product of two arrays of doubles
   [^doubles v1 ^doubles v2]
   (areduce v1 i ret 0.0
(+ ret (* (aget v1 i)
  (aget v2 i)


 This gives a general idea of which optimizations helped the most. These 
 changes are not in the public repository, since previous commits have been 
 omitted because the code code was not ready for publication (different 
 license disclaimer, contained email addresses, etc.). If anyone is 
 interested in the diffs and the execution times over several optimizations, 
 please contact me.

 Kind regards,

 Jose.


 On Sunday, December 21, 2014 3:38:35 AM UTC-5, Jose M. Perez Sanchez 
 wrote:


 Hi everyone:

 Sorry that it has taken so long. I've just released the software in 
 GitHub under the EPL. It can be found at:

 https://github.com/iosephus/gema


 Kind regards,

 Jose.



-- 
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: Charting Data Format Feedback Requested

[Mikera]

It seems to me that we will need a multi-stage pipeline with a few 
different transformations available. This will give many benefits:
a) People can mix and match the components they need for the particular 
project
b) We avoid unnecessary dependencies for people who don't want / can't 
support them
c) We can avoid duplicated effort on shared stages
d) Each step itself can be simpler and more maintainable (the non-visual 
steps at least should be very testable pure functions etc.)

I can see a few steps that we might want to support.

(CLJ) analytical tools = core.matrix dataset (this could cover all kinds 
of analytics, queries, machine learning outputs etc.)
(CLJ) core.matrix dataset = common chart format (roughly as Lucas suggests 
above)
(CLJ) common chart format = Java based charting (e.g. JFreechart, as in 
Incanter)
(CLJ/CLJS) common chart format = Vega format (for Gorilla REPL etc.)
(CLJ/CLJS) Vega format = SVG (Gorilla renderer already does this, right?)
(CLJS) common chart format = Om-wrapped Javascript charting component (D3, 
NVD3 etc.)

I'm sure there are other important transformations that I have missed, but 
I hope I have conveyed the broad idea?

Interactivity is, I think, a separate problem. We should keep that separate 
from the pure data definitions and transformations. There are many 
different possible interaction patterns and we shouldn't be prescriptive 
about this. People will also undoubtedly come up with clever ways to 
optimise interactivity e.g. with Om-like detection of deltas, so again we 
should avoid baking in too many assumptions in order to allow room for 
innovation.


On Monday, 15 December 2014 05:20:57 UTC+8, Jony Hudson wrote:

 Hi Lucas,

  I think, regarding integration with Gorilla, the real decision to be made 
 is around interactivity. For non-interactive charts, it would be ideal to 
 separate out the code that generates the chart from the code that messes 
 with the DOM. Gorilla would then just use the charting code, and do its own 
 DOM manipulation. It would probably also be ideal if the charting code ran 
 server-side (CLJ) for Gorilla's purposes.

 It sounds, though, that this is probably not the goal for your library. If 
 you are aiming to build something that can handle interactive 
 visualisations, and handle changing data, then I guess there's going to be 
 much more interaction between the charting code and the DOM manipulation 
 code. I'm not sure how that would fit in with Gorilla - but as a general 
 design point (which would also ease Gorilla integration) there might be 
 some value in making the interface between charting and DOM 
 manipulation explicit, so that it is possible to plug in different 
 approaches to DOM manipulation. That's not to say that this is 
 realistically possible, just that I'd put it on the wishlist :-)

 My current plan with Gorilla was to steer clear of interactivity, for two 
 reasons: one, that for the sort of stuff I do myself, it's not really that 
 useful (or, as I've said before: the interactivity you already get at the 
 REPL is plenty); and two, because it looks like it's really, _really_ hard 
 to get right! That said ... I recognise that people do do things that would 
 be improved by interactivity, so if it is possible to make it work cleanly, 
 then it is something I'd be keen to support in Gorilla :-)


 Jony

 On Sunday, 14 December 2014 12:26:17 UTC, Lucas Bradstreet wrote:

 Hi Jony, 

 I'm a fan of Gorilla REPL. I'd love to have this work supported with 
 it. Is it easy to support Clojurescript based renderers within 
 GorillaREPL? It would be nice to support interactive figures with this 
 kind of use case (in addition to SVG based plots, of course). 

 From the responses thus far, it appears that ggplot is the gold 
 standard for composable, customizable charts. Once we get the 
 dataframe format right, I'll invest some time into learning what I can 
 from it. We certainly want any implementation to be as data driven as 
 possible. 

 Thanks, 

 Lucas 


 On 13 December 2014 at 22:42, Jony Hudson jonye...@gmail.com wrote: 
  I think it would be great, and a very useful contribution to the 
 Clojure 
  world, to have a flexible plotting library. My perspective, at risk of 
 going 
  a bit off-topic, and from the biased position of a Gorilla REPL author 
 ... 
  
  
  When I think about the sort of programming I do as a scientist - data 
  analysis, modelling, numerics, statistics - I have a few requirements: 
  
  
  - For me, having a notebook interface is essential. It's how I think. 
 It's 
  the interactivity of the REPL, plus rich output, plus note-taking. 
  
  - I'd like to write my code in a civilised language. Ideally one that 
 puts 
  data first, because that's at the heart of the problems I solve. 
  
  - I want to be able to make things run fast when I need to. So I need 
 some 
  ability to write low-level code on occasion. 
  
  - I'd rather not re-write the whole world, so libraries 

Re: Status of lean runtime?

[Mikera]

There's also Kiss, which at least has the potential to run as a 
fast-loading statically-typed Clojure variant.

https://github.com/mikera/kiss

Currently I still load clojure.core for bootstrap reasons, but that's not 
going to be necessary in the future (once kiss.core is complete). I may 
take a crack at this over Christmas if I get a few days of free hacking 
time.

Like Oxcart and probably most other fast-loading solutions, Kiss would 
benefit from a lib-clojure solution (Clojure interfaces and core data 
structures etc. provided as a separate Java library dependency)

On Thursday, 11 December 2014 14:56:44 UTC+8, Ken Restivo wrote:

 Thanks. I wasn't expecting anything to be released soon. 

 Based on replies here and elsewhere, so far it seems there is: 

 1) The fastload branch of Clojure 
 https://github.com/clojure/clojure/tree/fastload  (status unknown) 
 2) Oxcart  https://github.com/oxlang/oxcart (looks abandoned?) 
 3) Android Clojure https://github.com/clojure-android/clojure (unclear if 
 it will or is intended to work on JVM or only on Android) 

 It seems as though release-track development on this would be blocked 
 waiting for multiple-build-profiles tooling first anyway. 

 Thanks again for your reply. 

 -ken 
 -- 
 --- 
 On Tue, Dec 09, 2014 at 07:33:05PM -0800, Alex Miller wrote: 
  We are still very interested in improving both Clojure load times and 
 pursuing multiple build profiles. That work will not be part of 1.7. 
  
  Alex 
  
  -- 
  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 
 javascript: 
  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 javascript: 
  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 javascript:. 
  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: One more for the crappy error messages file.

[Mikera]

How are you getting that error? Are you sure you aren't just passing a nil 
parameter by accident? For example, I get the same error when I pass nil to 
the clojure.java.io/reader function.

Clojure usually throws file not found exceptions where appropriate, e.g.

(use 'clojure.java.io)

(reader (file ugieceb.doc))
= FileNotFoundException ugieceb.doc (The system cannot find the file 
specified)  java.io.FileInputStream.open (FileInputStream.java:-2)

On Monday, 8 December 2014 13:44:46 UTC+8, Fluid Dynamics wrote:

 IllegalArgumentException No implementation of method: :make-reader of 
 protocol: #'clojure.java.io/IOFactory found for class: nil  
 clojure.core/-cache-protocol-fn (core_deftype.clj:541)

 This, apparently, is clojure.java.io's way of saying file not found. :)

 If there's a list somewhere of specific cases in which to improve the 
 clarity and conciseness of Clojure error reporting, I submit the above as a 
 shoo-in candidate for the new #1 spot and the gold medal in the most in 
 need of improvement Error Message Olympics. :)


-- 
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: Considering dropping Eclipse 3.x support for counterclockwise

[Mikera]

I would totally support this if it makes it easier to enhance 
Counterclockwise (which I love!)

Not personally aware of anyone still stuck on Eclipse 3.x

On Thursday, 4 December 2014 18:18:34 UTC+8, Laurent PETIT wrote:

 Hello,

 Eclipse 4.x has been around for many years now, and I'm considering 
 dropping definitely the support for Eclipse 3.x.

 This would simplify ccw internals (merge 2 plugins which are separate due 
 to this), and also allow ccw to embrace Eclipse 4.x APIs in more areas than 
 today (today only User Plugins use Eclipse 4.x APIs).

 Before committing to this choice, I'd like to hear from you if some think 
 it's still too early to do so.

 Cheers,

 -- 
 Laurent Petit
  

-- 
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.7.0-alpha4 now available

[Mikera]

This is a great release, thanks!

CLJ-1529 seems to have solved a major compilation-time issue with 
core.matrix

CLJ-1578 is a good start in that it stops some of the failures, but the 
warnings still aren't addressed... I will open a new ticket


On Saturday, 15 November 2014 03:34:55 UTC+8, Alex Miller wrote:

 Clojure 1.7.0-alpha4 is now available.

 Try it via
 - Download:
 http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha4/
 - Download securely:
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha4/
 - Leiningen: [org.clojure/clojure 1.7.0-alpha4]

 A few important changes to be aware of:

 1) CLJ-1330 (added in 1.7.0-alpha3) contained an enhancement to include
 local names in class names. This introduced some problems due to class
 name lengths. That aspect of CLJ-1330 has been retracted and this should
 no longer be an issue.

 2) CLJ-1578 highlighted an issue where new Clojure core functions 
 (update in this case) could cause errors to be thrown on reload with
 existing code bases that used that function name. This will now emit a
 warning instead of throwing an exception. This should make it safer to 
 upgrade to new Clojure versions without incurring errors.

 3) CLJ-1529 avoids unnecessary calls to Class.forName() and can
 significantly reduce compile time on some (not all) projects.

 For all changes new in alpha4, see the issues marked (alpha4) in the
 full changes below.

 
 Clojure 1.7.0-alpha4 has the changes below from 1.6.0:

 ## 1 New and Improved Features

 ### 1.1 Transducers

 Transducers is a new way to decouple algorithmic transformations from their
 application in different contexts. Transducers are functions that transform
 reducing functions to build up a recipe for transformation.

 Also see: http://clojure.org/transducers

 Many existing sequence functions now have a new arity (one fewer argument
 than before). This arity will return a transducer that represents the same
 logic but is independent of lazy sequence processing. Functions included 
 are:

 * conj (conjs to [])
 * map
 * mapcat
 * filter
 * remove
 * take
 * take-while
 * drop
 * drop-while
 * cycle
 * take-nth
 * replace
 * partition-by
 * partition-all
 * keep
 * keep-indexed

 Additionally some new transducer functions have been added:

 * cat - concatenates the contents of each input
 * de-dupe - removes consecutive duplicated values
 * random-sample - returns items from coll with random probability

 And this function can be used to make completing transforms:

 * completing

 There are also several new or modified functions that can be used to apply
 transducers in different ways:

 * sequence - takes a transformation and a coll and produces a lazy seq
 * transduce - reduce with a transformation (eager)
 * eduction - returns a reducible/seqable/iterable seq of applications of 
 the transducer to items in coll. Applications are re-performed with every 
 reduce/seq/iterator.
 * run! - run the transformation for side effects on the collection

 There have been a number of internal changes to support transducers:

 * volatiles - there are a new set of functions (volatile!, vswap!, 
 vreset!, volatile?) to create and use volatile boxes to hold state in 
 stateful transducers. Volatiles are faster than atoms but give up atomicity 
 guarantees so should only be used with thread isolation.
 * array iterators - added support for iterators over arrays

 Some related issues addressed during development:
 * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
 * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
 * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549)
 * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537)
 * [CLJ-1554](http://dev.clojure.org/jira/browse/CLJ-1554)   (alpha4)


 ### 1.2 Keyword and Symbol Construction

 In response to issues raised in [CLJ-1439](
 http://dev.clojure.org/jira/browse/CLJ-1439),
 several changes have been made in symbol and keyword construction:

 1) The main bottleneck in construction of symbols (which also occurs 
 inside keywords) was
 interning of the name and namespace strings. This interning has been 
 removed, resulting
 in a performance increase.

 2) Keywords are cached and keyword construction includes a cache check. A 
 change was made
 to only clear the cache reference queue when there is a cache miss.

 ### 1.3 Warn on Boxed Math

 One source of performance issues is the (unintended) use of arithmetic 
 operations on
 boxed numbers. To make detecting the presence of boxed math easier, a 
 warning will now
 be emitted about boxed math if \*unchecked-math* is set to :warn-on-boxed 
 (any truthy
 value will enable unchecked-math, only this specific value enables the 
 warning).

 Example use:

 user (defn plus-2 [x] (+ x 2))  ;; no warning, but boxed
 #'user/plus-2
 user (set! *unchecked-math* :warn-on-boxed)
 true
 user (defn plus-2 [x] (+ x 2)) ;; now 

Re: Deterministic Randomness in Functional Clojure

[Mikera]

You may find that wrapping a random number generator as a lazy sequence is 
a useful approach - it is functional and works nicely in an idiomatic 
clojure style where you can take as many random numbers as you need while 
treating the whole sequence as an immutable value.

I have an (experimental) implementation of this approach in 
core.matrix.stats, see:

https://github.com/clojure-numerics/core.matrix.stats/blob/develop/src/main/clojure/clojure/core/matrix/random.clj

On Wednesday, 29 October 2014 03:08:55 UTC+8, Isaac Karth wrote:

 I've been working on some projects (roguelikes, story-generators) that 
 often have a reason to have a random outcome for things like procedurally 
 generating a map. Ideally, they would be deterministically psuduorandom, so 
 that I can generate the same results from the same seed. The part I'm 
 having trouble with is figuring out what method to use to implement this in 
 a functional way.

 The naive approach that first occurred to me was to pass a PRNG and seed 
 value into each function. That would certainly keep the functions 
 referentially transparent. But it would also require either rewriting a 
 bunch of functions that don't directly use the randomness themselves or 
 adding the RNG as part of the map that's already being passed. 

 Plus, the seed should probably vary (deterministically) between calls to 
 the subfunctions. It's not too useful if all the rooms on a map have the 
 same type because they all pulled their die roll from the same-nth result 
 of the exact same seed. Maybe the seed could be created from the contents 
 of the vector or a UUID of a map object or something?

 The other suggestion I've run across is to rebind something like 
 clojure.data.generators/*rnd* for each high-level procedural generation 
 call. I think this requires the generation to be single threaded and 
 otherwise deterministic. At the moment I don't feel like I know enough 
 about how things work under the hood to say if this a good idea or not.

 I've poked around at the bigml.sampling and clojure.data.generators 
 libraries, which look useful for dealing with some of this, but I haven't 
 come across anything that directly addresses what kind of architecture to 
 use for deterministic randomness. This may be my inexperience. I feel like 
 I may be a bit too close to the problem, and I can't quite see what the 
 idiomatic answer is. Re-read SICP? Implement some kind of monad? Just bite 
 the bullet and pass the RNG+seed? Find the secret pure functional library 
 everyone is using for repeatable stochastic simulations?

 Does anyone have any advice on this? Or prior experience with approaches 
 that work? What are some best practices for approaching deterministic 
 simulations in an idiomatic, functional 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.

Re: Deployment choices WAR or lein or java -jar for web apps?

[Mikera]

To keep things simple I have found it easy to use lein uberjar and java 
-jar myapp.jar. This removes the need for a separate container / app 
server and it is probably the easiest choice when you are running an 
embedded server such as http-kit. Configuration is virtually zero, and this 
has the added advantage of working identically on Windows and Linux.

I've also found nginx-clojure to be a pretty solid choice if you need some 
of the extra stuff than nginx provides. 

On Tuesday, 28 October 2014 17:21:34 UTC+8, Colin Yates wrote:

 Hi all,

 How do you delight the world with your beautiful works of art once you 
 have finished lovingly crafting them from the joy that is Clojure?

 I have a legacy in J2EE so I use ring uberwar and deploy to a servlet 
 container (Tomcat as it is the most seamless on Windows), but I notice more 
 and more libraries are starting containers themselves (using 
 ring.middleware.jetty for example).

 For context, our internal stuff is run on Linux using the fantastic 
 puppet, but our clients all use Windows.

 Do you deploy using WAR or do you use 
 http://commons.apache.org/proper/commons-daemon/procrun.html and run lein 
 or something else?




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