[ANN] Quil 2.2.6 Release

Happy to announce Quil 2.2.6 release. Quil is a Clojure/ClojureScript library for creating interactive drawings and animations. Github repo . The release available on clojars: https://clojars.org/quil. Changes: - Fix bug with hex colours. Issue #71

Re: (slurp nil)

Elric Erkose writes: Hi Elric, > Is it reasonable that ```(slurp nil)``` throws an Exception rather > than evaluates to nil? Yes, totally. The first argument is something from which a reader can be created, e.g., a java.io.File, a file name as String, an URL, an InputStream, etc. So to me (sl

Re: When should defrecord be slower than deftype?

Thanks Steven, Andy. I feel much better knowing now *why *deftype and defrecord have different performance. I felt that I should prefer defrecord because it's the default, and just in case I needed its extra features. Now I can feel good about using deftype as long as I'm clear about what the

Re: When should defrecord be slower than deftype?

Hi Marshall, Yes, that's the gist of it. If you look at the bytecode for the defrecord, you should see something like: // Method descriptor #287 ()I // Stack: 1, Locals: 1 public int hashCode(); 0 aload_0 [this] 1 checkcast clojure.lang.IPersistentMap [18] 4 invokestatic c

Re: When should defrecord be slower than deftype?

I am not sure if this is the root cause of the performance difference you are seeing, but Clojure records do not cache their hash values: http://dev.clojure.org/jira/browse/CLJ-1224 I don't know what the default .hashCode method is for deftypes that do not specify one -- perhaps it is very fast be

Re: complex number library

That sounds pretty solid imo. On Tue, Jun 2, 2015 at 5:53 PM, Mike Anderson wrote: > I agree that complex would be a better name. > > It would be also be nice if it the 1-arg version could be idempotent (i.e. > returns an existing complex number unchanged). The downside is that this > would mean

Re: When should defrecord be slower than deftype?

Steven--Oops, yeah, I am calling Java methods that are probably using hashCode(), and maybe equals(). Interesting. Is the idea that records are hashed on the values in their fields, while deftype object are just hashed a pointer (or whatever identical? uses)--something like that? So if you

Re: When should defrecord be slower than deftype?

Thanks Timothy. I had been testing the simple defrecord and deftype definitions in the repl, but tried it with 'java -server' and still got roughly equal times. I was testing the full program with 'lein run', but just to be sure tried making a jar and running it with 'java -server'. The deft

Re: Identifying objects that cannot be read

Am Mittwoch, 3. Juni 2015 11:05:03 UTC+9 schrieb Alex Miller: > > Try pr with 1.7.0-RC1 ... Awesome. -- 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

Identifying objects that cannot be read

Try pr with 1.7.0-RC1 ... -- 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

Identifying objects that cannot be read

How do I remove from a nested datastructure the objects whose (pr obj) representation doesn't comply with the EDN specification? Fx, {:a 1 :b (find-ns 'user)} → {:a 1} Or, easier, how do I just not print these objects? I want to extract the metadata maps from arbitrary Clojure objects and write

Re: When should defrecord be slower than deftype?

I'm not aware of anything that would lead to significant differences in regards to the function call. As a test, I defined an interface and used deftype and defrecord, then used no.disassemble[1] to inspect the results, using the following commands: user=> (use 'no.disassemble) user=> (defint

Re: complex number library

I agree that complex would be a better name. It would be also be nice if it the 1-arg version could be idempotent (i.e. returns an existing complex number unchanged). The downside is that this would mean a slight performance hit because it would prevent the use of primitive arguments. Maybe we

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

Am Donnerstag, 28. Mai 2015 07:57:37 UTC+9 schrieb Colin Fleming: > > […] > > Much of this is specific to editing environments, and more concretely > specific to Cursive. It's also mostly necessary because I'm working from > unexpanded source rather than introspecting a REPL. > I see. I think

Re: complex number library

How about changing the name of the complex-number function to, ideally, complex? complex-number seems irritating to (have to) read. Further, calling this function is a form of type coercion. (float ...), (int ...), etc., are idiomatic Clojure, whereas (float-number ...), (int-number ...), et

Re: (slurp nil)

On Jun 2, 2015, at 2:13 PM, Elric Erkose wrote: > Is it reasonable that ```(slurp nil)``` throws an Exception rather than > evaluates to nil? IMO, yes, throwing an exception is the right thing here, otherwise you’d have nil instead of a string and you’d likely be doing string operations on it,

Handling exceptions with Reader Conditionals

On the Reader Conditionals dev discussion page at one part it talks about exception handling: "Exception handling, catching "all" - see issue below on why this is not a complete solution in either case." I looked further down the page an

(slurp nil)

Is it reasonable that ```(slurp nil)``` throws an Exception rather than evaluates to nil? ``` user=> (slurp nil) 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:5

Re: Opinion on core.async vs callbacks in abstract APIs?

Is there a detail of core.async that is needed in a third party usage? If not, you should't have to require core.async. Be liberal in what you accept and conservative in what you produce - Art of Unix Programming paraprhased. On Monday, June 1, 2015 at 3:18:19 PM UTC-4, Christopher Small wrote

Re: Opinion on core.async vs callbacks in abstract APIs?

The problem with using bare callbacks is that there's no way for the invoked callback to exert backpressure, except by blocking or passing in a CPS-style callback to the callback, neither of which is ideal. If you're looking for a "neutral" choice, I'd suggest an infinite lazy-seq over callbac

Re: Opinion on core.async vs callbacks in abstract APIs?

On Mon, Jun 1, 2015 at 11:12 PM, Gary Trakhman wrote: > I think this is one of those cases where the rules are different for > libraries than applications. > > Does your lib need to pull in core.async, and does it need to be coupled > to a specific version? If it's a building block sort of lib t

Re: Opinion on core.async vs callbacks in abstract APIs?

On Tue, Jun 2, 2015 at 7:18 AM, Leonardo Borges wrote: > For people interested in using the 'futures' approach, this might be of > interest: https://github.com/leonardoborges/imminent > > > It's a library that implements composable futures for Clojure on top of > JVM's ForkJoin framework. It allo

Re: Clojure for Desktop UI Design Application

I'm a newbie in the JVM/Clojure world, and a past user of C#/WPF. I had similar questions for a JVM desktop application, and came upon this interesting project: http://open-dolphin.org/dolphin_website/Home.html. The notion here is that you mutate very simple, generic presentation models at th

Re: complex number library

You sir, rock. On Tue, Jun 2, 2015 at 10:41 AM, Mike Anderson wrote: > OK, here's a basic version that I think has most of the key elements in > place. > > A lot more protocols still need implementing, but it should be a > reasonable basis to build upon: > > https://github.com/mikera/core.matrix

Re: When is [] a vector?

On Tuesday, June 2, 2015 at 2:00:17 PM UTC-4, piast...@gmail.com wrote: > > I don't know how to read this: > > > http://www.leonardoborges.com/writings/2012/12/02/monads-in-small-bites-part-ii-applicative-functors/ > > (defmulti pure (fn [f _] f))(defmethod pure List [_ v]"Wraps value v in a

When is [] a vector?

I don't know how to read this: http://www.leonardoborges.com/writings/2012/12/02/monads-in-small-bites-part-ii-applicative-functors/ (defmulti pure (fn [f _] f))(defmethod pure List [_ v]"Wraps value v in a list"(List. [v])) Is this a List followed by a vector of 2 elements, or this a

Re: complex number library

OK, here's a basic version that I think has most of the key elements in place. A lot more protocols still need implementing, but it should be a reasonable basis to build upon: https://github.com/mikera/core.matrix.complex On Tuesday, 2 June 2015 16:35:25 UTC+1, Christopher Small wrote: > > >

Re: When should defrecord be slower than deftype?

Are you testing this inside of a lein repl (or any repl for that matter)? If so, compile it to a jar and run the jar directly via java -server -jar jarfile.jar. This could change your numbers a bit. Timothy On Tue, Jun 2, 2015 at 11:08 AM, Mars0i wrote: > I have an application using Java intero

When should defrecord be slower than deftype?

I have an application using Java interop, in which I can define a class using either deftype or defrecord. It has one field, containing an atom containing a double, and a few methods. One of the methods is specified by an interface defined in Java, and that method is called from Java. This m

Re: Opinion on core.async vs callbacks in abstract APIs?

That makes sense. Thanks for the explanation. On Tuesday, 2 June 2015, Timothy Baldridge wrote: > I think the problem is more centered around push vs pull based APIs. > Callbacks, and core.async work quite well for push based apis (e.g. event > streams). Lazy seqs work on a pull basis. ZeroMQ ha

Re: Opinion on core.async vs callbacks in abstract APIs?

I think the problem is more centered around push vs pull based APIs. Callbacks, and core.async work quite well for push based apis (e.g. event streams). Lazy seqs work on a pull basis. ZeroMQ has a pull API, so lazy seqs work quite well there. Also lazy-seqs aren't async. If you call (next ..) and

Re: Opinion on core.async vs callbacks in abstract APIs?

I'm not sure I follow why lazyness cannot be asynchronous, as long as reads are blocking (which they are by default in core.async, I believe). Your description of the problem made me think of this blog post I read some years ago: http://oobaloo.co.uk/clojure-abstraction-and-zeromq which explains

Re: Opinion on core.async vs callbacks in abstract APIs?

Yes, potentially. And their temporal distribution could be any imaginable. The idea is that we're dealing with things like button presses, which could happen as frequently or infrequently as a physical device might need, and for which an application would have to be prepared for the duration of th

Re: complex number library

> The array representation could simply be a deftype which uses two underlying arrays for the real and complex parts of the array respectively. Oh man; that is flipping brilliant. And simple... > The implementation should be fairly straightforward, but if anyone wants I can create a repo and bang

Re: non-incanter statistical tests?

It may require conversion to/from Java arrays to use them, but there are Apache Commons Math implementations of the computations you mention, and many others: http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/stat/inference/ChiSquareTest.html http://commons.apache.org/

Re: Opinion on core.async vs callbacks in abstract APIs?

Oh, so the events are for all intents and purposes infinite? On Tue, Jun 2, 2015 at 11:10 AM, Christopher Small wrote: > @Erik: I should clarify in this situation, the _user_ of the API would > decide whether they want to stop listening to events. So there's not so > much that _they_ would have

Re: complex number library

I think the right strategy is to make a separate complex array implementation library ("core.matrix.complex"?). In terms of dependencies, it would only need to depend depend upon "core.matrix" and "complex". The array representation could simply be a deftype which uses two underlying arrays for

Re: non-incanter statistical tests?

Thanks Mike, This looks very much like what I want, in principle, although in practice I'm interested in functions like t-test and chisq-test, which haven't yet made it into core.matrix.stats as far as I can see. FWIW I'd be wary about just copying those things from Incanter, at least because

Re: Opinion on core.async vs callbacks in abstract APIs?

@Erik: I should clarify in this situation, the _user_ of the API would decide whether they want to stop listening to events. So there's not so much that _they_ would have to specify in terms of shutdown routines. I'm more concerned about how API implementations get notified that they don't need to

Re: Opinion on core.async vs callbacks in abstract APIs?

Lazy seqs by themselves wouldn't work, since it needs to be asynchronous, and it's always possible that when you ask for the next element, that there won't have been any new events yet. I suppose that you could return a lazy sequence of futures, which is interesting, but not particularly idiomatic.

Re: non-incanter statistical tests?

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

Re: Opinion on core.async vs callbacks in abstract APIs?

On Tue, Jun 2, 2015 at 3:17 AM, Christopher Small wrote: Additionally, I feel it worth responding to some of Timothy's comments > about the difficulty of getting a core.async centric API "right". While I > agree that in general (and particular with more complicated APIs) getting > things right ca

Re: ANN: Hildebrand 0.2.2

Thanks! There was a high effort/clause also. I'm working on a couple more Clojure posts today. Take care, Moe On Tue, Jun 2, 2015 at 9:37 AM, Tj Gabbour wrote: > Slightly OT, but wow, slowly reading your blogpost because it's terribly > pleasant to read! :) Like, a high amusement-to-clause ra

Re: ANN: Hildebrand 0.2.2

Slightly OT, but wow, slowly reading your blogpost because it's terribly pleasant to read! :) Like, a high amusement-to-clause ratio. (I think this should influence my own tech writing.) On Tuesday, June 2, 2015 at 2:20:59 AM UTC+2, Moe Aboulkheir wrote: > > First time caller. > > Hildebrand is

Re: Opinion on core.async vs callbacks in abstract APIs?

Have you considered returning a lazy seq of events? On Tuesday, 2 June 2015, Christopher Small wrote: > > Lots of great thoughts here; thanks so much for the feedback! > > It seems the general opinion so far leans towards keeping things simple. I > definitely resonate with this statement: "havin

Re: Opinion on core.async vs callbacks in abstract APIs?

Lots of great thoughts here; thanks so much for the feedback! It seems the general opinion so far leans towards keeping things simple. I definitely resonate with this statement: "having to write some glue code feels less frustrating than when libs make assumptions that I don't like." Unfortuna