Re: New ring middleware: browser-caching

[edbond]

Hello Stephen,

Couple of comments about code:
Instead of not nil? you can use some? since clojure 1.6:
user=> (doc some?)
-
clojure.core/some?
([x])
  Returns true if x is not nil, false otherwise.

str/split and get by 0 may result in error:
user=> (str/split ":" #":")
[]
user=> ((str/split ":" #":") 0)

clojure.core/eval  core.clj: 3081
  ...
   user/eval10817  form-init2396972653997124309.clj:1
  ...
java.lang.IndexOutOfBoundsException: 

Better use some-> and first:
user=> (doc some->)
-
clojure.core/some->
([expr & forms])
Macro
  When expr is not nil, threads it into the first form (via ->),
  and when that result is not nil, through the next etc

like
user=> (some-> ":" (str/split #":") first)
nil

Also It will be helpful to add pre condition or other validation to 
wrap-browser-caching fn
to check if filetypes is a map.


Best regards,
Eduard


On Monday, July 27, 2015 at 5:54:03 AM UTC+3, Stephen Lester wrote:
>
> Hello everyone, 
>
> I just wrote my first ring middleware (I'm pretty much a newbie to 
> functional programming and Clojure in general), and I'd appreciate if 
> someone wants to give me some tips or constructive criticism (and it can 
> be off-list as well). 
>
> The goal is to enable per-file-type browser caching hints. I had found 
> some other plugins that either set it to 0 (no-cache) or did it based on 
> server response code, but none that took into account filetype. I was 
> inspired by a similar thing Apache can do. 
>
> A big thank you to this community! #clojure on Freenode has been 
> amazing, and most of the time this list is a very interesting read. 
>
> https://github.com/slester/browser-caching 
>

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

[Colin Fleming]

>
> Which seems unlikely given the conservatism of Clojure development.


More than that, it would mean that Clojure required Java 8.

On 28 July 2015 at 05:23, Mikera  wrote:

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

> On Sunday, 26 July 2015, Andrew Oberstar  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

Re: a question about Chris Zheng's "Abstract Container Pattern"

[zcaudate]

Hey guys,

Thanks for the feedback and your very insightful comments.

Yep... this is OO alright =)

I realised only after I wrote the article that I was implementing a 
Lifecycle clone with IRunnable example. However, the concept I am 
mentioning is much more general than components in terms of its scope:

A similar `abstract class` for a reflective functional dispatch mechanism 
is defined here:
https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj

and extended by the `concrete classes' here:
https://github.com/zcaudate/iroh/tree/master/src/iroh/element

In the case of iroh... if I had used strictly multimethods, I would have 
been very confused. If I had used strictly protocols... well I couldn't for 
a number of reasons.. but if I did, I would have been even more confused 
because of the number of subconditions that I had to implement. iroh was 
the first library that I had built that used this pattern and it was so 
successful that I've been repeating the process over and over again since.

What I wanted to achieve was to have the equivalent of an `abstract class` 
- the concept of code with abstract functionality that provides a framework 
for the heavy lifting to be done. `Concrete classes` can just extend 
aforementioned `abstract class` with minimal code and get all of the 
benefits. 

I've used this pattern with great success in many, many times and it 
provides a counter balance to the functional paradigm in terms of packaging 
up functionality. Clojure doesn't force us into one paradigm or the other 
and sometimes it is just more stylish to use the OO paradigm. The whole 
point of OO, multimethods and protocols is to do polymorphic dispatch, 
which is just a way to break a large cond statement into pieces that can 
then also be further extended. 

Please also note that not all OO frameworks are equal. Java uses a class 
inheritence approach whereas javascript uses a prototype model. The 
`abstract container` pattern that I was describing is probably closer to 
the JS model but to be honest, I don't really know what it is. Ultimately, 
it adds a middle tier of functionality in systems that have a plugin type 
mechanism. I'm sure there are equivalent functional contructs... but that 
was not the point of the pattern. This pattern has been very useful for me; 
clojure's protocols and multimethods were not enough to do what I needed to 
do - but combination of the two works wonders =)

Since the article, the pattern has been codified here:
https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196

Hope that helps in clarifying the motivation behind the article and the 
pattern


Chris







On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote:
>
> I think his last sentence gives you the answer:
>
> "A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all the 
> guys at clj-melb that gave feedback and helped flesh out this rehash of *OO 
> design*.” (my emphasis)
>
> He wanted an OO approach and has implemented one; specifically behaviour 
> and state coupled together. I think neither Typed Clojure nor Contracts 
> would have achieved this guy’s goal as they are about enforcing a contract 
> (either the shape of data or effects of a fn) in the ‘functional’ paradigm; 
> this guy clearly wanted something in the OO paradigm. 
>
> Is there a ‘functional’ implementation which gives the same benefits; 
> sure, but that isn’t what he wanted. Are there a bunch of ‘upgrades’ that I 
> am sure we could all apply; sure, but again it seems like he was setting 
> out with a very specific goal in mind and has achieved that. 
>
> On 27 Jul 2015, at 18:37, Lawrence Krubner  > wrote:
>
> I have a question about this: 
>
> "Servers that are running on a particular port can be tracked and stopped. 
> I have to say, this was the feature that I wanted the most, which motivated 
> the framework's design. The annoying thing about development in emacs is 
> that I have to be careful of not losing the reference to the server. Since 
> there was no way of stopping it unless the repl is restarted. I wanted to 
> implement a registery for references to running servers to be saved."
>
> http://z.caudate.me/the-abstract-container-pattern/
>
> I have the impression that he's going over the same territory as that 
> covered by Stuart Sierra, though Zheng doesn't mention "Component" nor 
> "Sierra". But he offers this as an example of what he's after: 
>
> (defprotocol IRunnable (start! [system]) (stop! [system]) (restart! 
> [system]) (started? [system]) (stopped? [system]))
>
> That much seems similar to Sierra's system. Zheng seems to add an 
> additional layer by simulating an abstract class above his protocols. As he 
> says: 
>
>
>- A single deftype acts as the *abstract container*, extending one or 
>more protocols
>- A set of methods defined through defmulti that is used within the 
>deftype form act as *abstract methods*
>- The *abstrac

Re: Advice on introducing a Java dev to Clojure

[Lawrence Krubner]

 

I wrote this for a blog post, but I think it is relevant here. After a long 
comparison of a bit of code, first in Javascript and then in Clojure, I 
wrote: 


 At this point, a Javascript developer might say, “You've shown that the 
Functional style has some advantage, but why should I care? I can write in 
the Functional style using Javascript. I don't need Clojure.” That is 
absolutely true, and we all know that developers tend to be fiercely loyal 
to their languages, up 'til the moment they are not. I myself was fiercely 
loyal to Ruby, up 'til the moment when I wasn't. True moments of conversion 
are rare and always depend on a person reaching some point of pain with 
their current path. I myself suddenly realized that I was working with 
languages that would not carry me into a future full of multi-CPU computers 
and massive concurrency ... at which point I began to explore what the 
future might hold ... at which point I discovered Clojure. 


 I would, however, counter the Javascript developer with my own set of 
questions. If you have realized that the Functional style is best, do you 
want to work in a language that undercuts that style, or supports it? Do 
you want to burden yourself with the extra discipline needed to pull off 
the Functional style in a highly mutable language, or do you want to work 
with a language that was designed from conception to make your life easier 
? Do you want to “navigate disappointment” or travel directly in the 
direction of success?  


In his talk, “Why Clojure is my favorite Ruby,” Steven Deobald refers to 
dealing with pain points in a language as “Navigating disappointment.”





On Thursday, July 23, 2015 at 9:04:42 AM UTC-4, Paul deGrandis wrote:
>
> I have had success here with a few approaches.
>
> For every company I work with that is new to Clojure, I provide them with 
> a "Quick Learn" document.  The document is split into 5-7 days, and every 
> day they skim/read an article, poke around a resource (like ClojureDocs), 
> and watch a talk.  Sometimes that "resource" item is an exercise or 
> something interactive.
>
> Your goal should never be to convince someone of Clojure - Clojure itself 
> is convincing enough.  Instead motivate someone to want to learn more - get 
> them curious and self-driven to dive in wherever their interests lay.  Get 
> them well adapted to the Clojure culture and the radical approach to 
> simplicity.  Get them questioning their own practices and technologies.  
> Entice them with the functional approach to system creation.
>
> Leon mentioned my talk, which claims, "Clojure manages risk better than 
> any other technology" - 
> http://www.infoq.com/presentations/Clojure-powered-Startups
> For well-established enterprise shops, I think my most recent Conj talk is 
> more convincing - https://www.youtube.com/watch?v=BNkYYYyfF48
>
> Consider the following talks by Rich:
>  * Clojure, Made Simple - https://www.youtube.com/watch?v=VSdnJDO-xdg
>  * Are we there yet? - 
> http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
>  * Simple Made Easy - http://www.infoq.com/presentations/Simple-Made-Easy
>
> Nothing is more convincing than a working system.  If it's possible, 
> illustrate the virtues of Clojure and its approach to problem solving by 
> "walking the walk" on a small scale, where the stakes and risks are low.  
> Build a tool, prototype an idea in half the time it would normally take, 
> show the power of Protocols within your own existing system, etc.
>
> Regards,
> 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: [ANN] Clojure 1.8.0-alpha2

[Justin Smith]

I use agents instead of atoms when the function altering the value has side 
effects, or is especially expensive (and thus should not retry).

I haven't had to use refs yet, but my use case would be if the mutable data 
has enough parallel modification that splitting one atomic map into 
separate ref maps would be a performance boost.

On Monday, July 27, 2015 at 11:00:56 PM UTC-7, Daniel Compton wrote:
>
> I think this is pretty unlikely. While megarefs look very cool, I'm not 
> sure what the benefit to having these directly in Clojure would be over 
> having them in a library. 
>
> Anecdotally, everyone I have talked to about Clojure's reference types 
> have said that they have never needed to use ref's or agents in real world 
> code (I'm sure some people have to good effect though).
>
> That being said, you can always open a JIRA or design doc about this if 
> you feel strongly about it to start a discussion.
>
> --
> Daniel.
>
> On Tue, 28 Jul 2015 at 9:05 AM Lawrence Krubner  > wrote:
>
>> Off topic, but I wonder if there was ever any discussion of megarefs 
>> being added to Clojure?
>>
>> https://github.com/cgrand/megaref
>>
>>
>> On Tuesday, July 21, 2015 at 3:30:46 PM UTC-4, Rangel Spasov wrote:
>>>
>>> Ok, I think someone already mentioned this - sorry. Got it to compile by 
>>> bumping to [potemkin "0.4.1"] - thanks Zach + all : ) 
>>>
>>> On Tuesday, July 21, 2015 at 12:24:43 PM UTC-7, Rangel Spasov wrote:

 Hey guys,

 Getting this error with 1.8.0-alpha2, I think related to aleph (using 
 0.4.0, latest version at the moment).

 #error {

  :cause IllegalName: 
 compile__stub.aleph.http.core.aleph.http.core/HeaderMap

  :via

  [{:type clojure.lang.Compiler$CompilerException

:message java.lang.NoClassDefFoundError: IllegalName: 
 compile__stub.aleph.http.core.aleph.http.core/HeaderMap, 
 compiling:(aleph/http/core.clj:81:1)

:at [clojure.lang.Compiler analyzeSeq Compiler.java 6798]}

   {:type java.lang.NoClassDefFoundError

:message IllegalName: 
 compile__stub.aleph.http.core.aleph.http.core/HeaderMap

:at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]

  :trace

  [[java.lang.ClassLoader preDefineClass ClassLoader.java 654]

   [java.lang.ClassLoader defineClass ClassLoader.java 758]

   [java.lang.ClassLoader defineClass ClassLoader.java 642]

   [clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java 
 46]

   [clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7815]

   [clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7680]

   [clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse 
 Compiler.java 7590]

   [clojure.lang.Compiler analyzeSeq Compiler.java 6791]

   [clojure.lang.Compiler analyze Compiler.java 6592]

   [clojure.lang.Compiler analyze Compiler.java 6553]

   [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]

   [clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6247]

   [clojure.lang.Compiler analyzeSeq Compiler.java 6791]

   [clojure.lang.Compiler analyze Compiler.java 6592]

   [clojure.lang.Compiler analyze Compiler.java 6553]

   [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5929]

   [clojure.lang.Compiler$FnMethod parse Compiler.java 5359]

   [clojure.lang.Compiler$FnExpr parse Compiler.java 3959]

   [clojure.lang.Compiler analyzeSeq Compiler.java 6789]

   [clojure.lang.Compiler analyze Compiler.java 6592]

   [clojure.lang.Compiler eval Compiler.java 6847]

   [clojure.lang.Compiler eval Compiler.java 6839]

   [clojure.lang.Compiler load Compiler.java 7295]

   [clojure.lang.RT loadResourceScript RT.java 372]

   [clojure.lang.RT loadResourceScript RT.java 363]

   [clojure.lang.RT load RT.java 453]

   [clojure.lang.RT load RT.java 419]

   [clojure.core$load$fn__5448 invoke core.clj 5866]

   [clojure.core$load doInvoke core.clj 5865]

   [clojure.lang.RestFn invoke RestFn.java 408]

   [clojure.core$load_one invoke core.clj 5671]

   [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

   [clojure.core$load_lib doInvoke core.clj 5710]

   [clojure.lang.RestFn applyTo RestFn.java 142]

   [clojure.core$apply invoke core.clj 632]

   [clojure.core$load_libs doInvoke core.clj 5749]

   [clojure.lang.RestFn applyTo RestFn.java 137]

   [clojure.core$apply invoke core.clj 632]

   [clojure.core$require doInvoke core.clj 5832]

   [clojure.lang.RestFn invoke RestFn.java 551]

   [aleph.http.server$eval9251$loading__5340__auto9252 invoke 
 server.clj 1]

   [aleph.http.server$eval9251 invoke serv

Re: a question about Chris Zheng's "Abstract Container Pattern"

[James Reeves]

What are the benefits of designing an "abstract class" in this way,
compared to, say, using a protocol and normal functions? Could you provide
a small example?

- James

On 28 July 2015 at 10:09, zcaudate  wrote:

> Hey guys,
>
> Thanks for the feedback and your very insightful comments.
>
> Yep... this is OO alright =)
>
> I realised only after I wrote the article that I was implementing a
> Lifecycle clone with IRunnable example. However, the concept I am
> mentioning is much more general than components in terms of its scope:
>
> A similar `abstract class` for a reflective functional dispatch mechanism
> is defined here:
> https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj
>
> and extended by the `concrete classes' here:
> https://github.com/zcaudate/iroh/tree/master/src/iroh/element
>
> In the case of iroh... if I had used strictly multimethods, I would have
> been very confused. If I had used strictly protocols... well I couldn't for
> a number of reasons.. but if I did, I would have been even more confused
> because of the number of subconditions that I had to implement. iroh was
> the first library that I had built that used this pattern and it was so
> successful that I've been repeating the process over and over again since.
>
> What I wanted to achieve was to have the equivalent of an `abstract class`
> - the concept of code with abstract functionality that provides a framework
> for the heavy lifting to be done. `Concrete classes` can just extend
> aforementioned `abstract class` with minimal code and get all of the
> benefits.
>
> I've used this pattern with great success in many, many times and it
> provides a counter balance to the functional paradigm in terms of packaging
> up functionality. Clojure doesn't force us into one paradigm or the other
> and sometimes it is just more stylish to use the OO paradigm. The whole
> point of OO, multimethods and protocols is to do polymorphic dispatch,
> which is just a way to break a large cond statement into pieces that can
> then also be further extended.
>
> Please also note that not all OO frameworks are equal. Java uses a class
> inheritence approach whereas javascript uses a prototype model. The
> `abstract container` pattern that I was describing is probably closer to
> the JS model but to be honest, I don't really know what it is. Ultimately,
> it adds a middle tier of functionality in systems that have a plugin type
> mechanism. I'm sure there are equivalent functional contructs... but that
> was not the point of the pattern. This pattern has been very useful for me;
> clojure's protocols and multimethods were not enough to do what I needed to
> do - but combination of the two works wonders =)
>
> Since the article, the pattern has been codified here:
>
> https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196
>
> Hope that helps in clarifying the motivation behind the article and the
> pattern
>
>
> Chris
>
>
>
>
>
>
>
> On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote:
>>
>> I think his last sentence gives you the answer:
>>
>> "A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all the
>> guys at clj-melb that gave feedback and helped flesh out this rehash of *OO
>> design*.” (my emphasis)
>>
>> He wanted an OO approach and has implemented one; specifically behaviour
>> and state coupled together. I think neither Typed Clojure nor Contracts
>> would have achieved this guy’s goal as they are about enforcing a contract
>> (either the shape of data or effects of a fn) in the ‘functional’ paradigm;
>> this guy clearly wanted something in the OO paradigm.
>>
>> Is there a ‘functional’ implementation which gives the same benefits;
>> sure, but that isn’t what he wanted. Are there a bunch of ‘upgrades’ that I
>> am sure we could all apply; sure, but again it seems like he was setting
>> out with a very specific goal in mind and has achieved that.
>>
>> On 27 Jul 2015, at 18:37, Lawrence Krubner 
>> wrote:
>>
>> I have a question about this:
>>
>> "Servers that are running on a particular port can be tracked and
>> stopped. I have to say, this was the feature that I wanted the most, which
>> motivated the framework's design. The annoying thing about development in
>> emacs is that I have to be careful of not losing the reference to the
>> server. Since there was no way of stopping it unless the repl is restarted.
>> I wanted to implement a registery for references to running servers to be
>> saved."
>>
>> http://z.caudate.me/the-abstract-container-pattern/
>>
>> I have the impression that he's going over the same territory as that
>> covered by Stuart Sierra, though Zheng doesn't mention "Component" nor
>> "Sierra". But he offers this as an example of what he's after:
>>
>> (defprotocol IRunnable (start! [system]) (stop! [system]) (restart!
>> [system]) (started? [system]) (stopped? [system]))
>>
>> That much seems similar to Sierra's system. Zheng seems to add an
>> additi

Re: Tool authors: ClojureScript support in tools.namespace?

[W. David Jarvis]

Yagni uses dir/scan-all and tracker. Would love to have ClojureScript 
support.

On Saturday, July 25, 2015 at 7:29:24 PM UTC-4, Brian Marick wrote:
>
> Midje 
>
> Stuart Sierra wrote: 
> > 1. Do you need/want ClojureScript support? 
>
> Eventually, but not soon. 
>
> > 
> > 2. What namespaces (repl, find, dir, file, parse) do you call in 
> > tools.namespace? 
>
> repl, dir, track, reload 
>
> > 
> > 3. How would you like to distinguish between "get me Clojure 
> > sources" and "get me ClojureScript sources"? 
>
> I don't have an opinion. 
>

-- 
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.2.0, Score 0.3.0

[W. David Jarvis]

This might be a naive question, but for someone who's only tangentially 
familiar with the space, where does this fit in to the overall Clojure 
music/sound ecosystem (re: overtone et al)?

On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote:
>
> Thanks Ruslan and best of luck in your musical work! 
>
> On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk  > wrote: 
> > Steven, thank you for continuing to develop Pink & Score! I have some 
> music 
> > projects as my slowly-moving-forward-hobbies, and having pure java, no 
> deps 
> > like Supercollider, engine for one of them is very precious! 
> > 
> > пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi написал: 
> >> 
> >> Hi All, 
> >> 
> >> I'd like to announce the release of Pink 0.2.0 and Score 0.3.0: 
> >> 
> >> [kunstmusik/pink "0.2.0"] 
> >> [kunstmusik/score "0.3.0"] 
> >> 
> >> Pink is an audio engine library, and Score is a library for 
> >> higher-level music representations (e.g. notes, phrases, parts, 
> >> scores). 
> >> 
> >> ChangeLogs are available at: 
> >> 
> >> https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md 
> >> https://github.com/kunstmusik/score/blob/master/CHANGELOG.md 
> >> 
> >> The quick version is Pink now has some new effects (ringmod, freeverb, 
> >> chorus) as well as some new filters and delay-based audio functions. 
> >> Score has a new sieves namespace for Xenakis-style sieves. (An example 
> >> of sieves and freeverb is available in the music-examples project 
> >> [1]). 
> >> 
> >> For any questions, please feel free to email me or post on the 
> >> pink-users list.  For issues and PR's, please use the facilities on 
> >> Github for each of the projects. 
> >> 
> >> Thanks! 
> >> steven 
> >> 
> >> 
> >> [1] - 
> >> 
> https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/sieves.clj
>  
>

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

[JOB] Clojure/Clojurescript Software Engineer - Startup - SF or remote

[Stephen Brady]

 Hi all,

We're looking for Clojure/Clojurescript engineers (details below). 

Please email me directly at step...@fac.tt 
if you're interested in learning more. 


Stephen 

--- 

Fact Labs 
is a San Francisco-based startup that is building a quick and easy way for 
users to create and discover structured and semi-structured data on the Web. 


About the environment: 
We are a small team of experienced Clojure software engineers looking to 
add another engineer to the team. We 
are looking for candidates who are capable of self direction and making sound 
technology and design decisions quickly. This is a great opportunity to really 
flex and 
stretch your Clojure/Clojurescript skills while building a new product in a 
startup environment. 


Our core stack is Clojure, Clojurescript, and Datomic running on AWS. 

About the role: 
This is a generalist role across front end and back end, however an interest 
and/or strengths in the following are particularly relevant: 

- Web application / system design 
- data visualization 
- API design 
- data modeling 

Required: 
- 1+ year of Clojure experience 
- 4+ years of production software development experience 
- strong understanding of core computer science concepts 

This is a full-time position. Remote candidates working in a US timezone are 
welcome. 


Please email step...@fac.tt for details. 

-- 
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: Tool authors: ClojureScript support in tools.namespace?

[Stuart Sierra]

Thanks for the responses everyone.

So far, my general plan is starting to look like this:

c.t.n.*dependency* and c.t.n.*track* are platform agnostic.

c.t.n.*file* and c.t.n.*parse* can be extended to support Clojure & 
ClojureScript by adding an optional argument read-opts passed through to 
tools.reader/read.

c.t.n.*find* can be extended with optional arguments to select a 
"platform," either Clojure or ClojureScript, which will encapsulate both 
valid file extensions and reader options.

Reload/refresh functionality will remain Clojure(JVM) only for now: c.t.n.
*dir*, c.t.n.*reload*, and c.t.n.*repl*.

More notes and work-in-progress are visible on TNS-35 


I'm not saying there will *never* be any ClojureScript support for 
refresh/reload, just that I have no idea how to do it right now and I want 
to deal with the easier problems first.

–S

-- 
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: ring.middleware.reload and figwheel

[Leon Talbot]

+1

Le mercredi 13 mai 2015 09:06:05 UTC-4, Paco Viramontes a écrit :
>
> Any luck with this? I want to do the same :P
>
> On Thursday, April 30, 2015 at 3:06:13 AM UTC-7, Dan Kersten wrote:
>>
>> Hi,
>>
>> I've got a clojure(script) project where I use figwheel to live-reload 
>> cljs and this works great, but I'm now trying to set up live reloading of 
>> the server-side clojure too.
>> Since I don't want to run multiple jvm/lein instances, I'm using 
>> figwheels :ring-handler feature to add my server ring handler into 
>> figwheels embedded webserver.
>> In the past, I've live-reloaded my server code using the reloaded 
>> workflow, but since figwheel gives me a cljs repl and not a clj repl, I 
>> don't know how to do that without running the server independently.
>>
>> So, instead I'm just trying to get ring.middleware.reload working, but 
>> its not picking up file changes. 
>>
>> Has anyone got this working? Alternatively, does anyone have any tips on 
>> getting a nice workflow without running multiple jvm/lein instances?
>>
>> 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: [ANN] Pink 0.2.0, Score 0.3.0

[Justin Smith]

Overtone has its own composition logic, but for synthesis it is a client 
for the open source Supercollider audio synthesis server (which is a cross 
platform C++ program that can be controlled via the network). Pink and 
Score are built in Clojure and Java without using an external server.

On Tuesday, July 28, 2015 at 9:54:14 AM UTC-7, W. David Jarvis wrote:
>
> This might be a naive question, but for someone who's only tangentially 
> familiar with the space, where does this fit in to the overall Clojure 
> music/sound ecosystem (re: overtone et al)?
>
> On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote:
>>
>> Thanks Ruslan and best of luck in your musical work! 
>>
>> On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk  
>> wrote: 
>> > Steven, thank you for continuing to develop Pink & Score! I have some 
>> music 
>> > projects as my slowly-moving-forward-hobbies, and having pure java, no 
>> deps 
>> > like Supercollider, engine for one of them is very precious! 
>> > 
>> > пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi 
>> написал: 
>> >> 
>> >> Hi All, 
>> >> 
>> >> I'd like to announce the release of Pink 0.2.0 and Score 0.3.0: 
>> >> 
>> >> [kunstmusik/pink "0.2.0"] 
>> >> [kunstmusik/score "0.3.0"] 
>> >> 
>> >> Pink is an audio engine library, and Score is a library for 
>> >> higher-level music representations (e.g. notes, phrases, parts, 
>> >> scores). 
>> >> 
>> >> ChangeLogs are available at: 
>> >> 
>> >> https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md 
>> >> https://github.com/kunstmusik/score/blob/master/CHANGELOG.md 
>> >> 
>> >> The quick version is Pink now has some new effects (ringmod, freeverb, 
>> >> chorus) as well as some new filters and delay-based audio functions. 
>> >> Score has a new sieves namespace for Xenakis-style sieves. (An example 
>> >> of sieves and freeverb is available in the music-examples project 
>> >> [1]). 
>> >> 
>> >> For any questions, please feel free to email me or post on the 
>> >> pink-users list.  For issues and PR's, please use the facilities on 
>> >> Github for each of the projects. 
>> >> 
>> >> Thanks! 
>> >> steven 
>> >> 
>> >> 
>> >> [1] - 
>> >> 
>> https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/sieves.clj
>>  
>>
>

-- 
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: ring.middleware.reload and figwheel

[Francis Avila]

I've never used ring.middleware.reload, but I do run client figwheel and 
server in the same jvm.

In your project.clj, make figwheel listen on an nrepl port:

:figwheel
{:nrepl-port   7888
 :server-port  3000 ; http
 :repl false ; Optional: keep this off and bootstrap to cljs 
repl: see below. 
 :ring-handler your-ring-handler}


Connect to that port with an nrepl client: this will be a clj repl for the 
server.

To get the cljs repl, you can either leave :repl true and use it from 
stdin/stdout, or you can piggieback to a cljs repl like so:

(do (use 'figwheel-sidecar.repl-api) (cljs-repl))

Since you can connect multiple nrepl clients to the same nrepl server, you 
can easily have one client for the server clj and another for the client 
cljs/figwheel.

On Thursday, April 30, 2015 at 5:06:13 AM UTC-5, Dan Kersten wrote:
>
> Hi,
>
> I've got a clojure(script) project where I use figwheel to live-reload 
> cljs and this works great, but I'm now trying to set up live reloading of 
> the server-side clojure too.
> Since I don't want to run multiple jvm/lein instances, I'm using figwheels 
> :ring-handler feature to add my server ring handler into figwheels embedded 
> webserver.
> In the past, I've live-reloaded my server code using the reloaded 
> workflow, but since figwheel gives me a cljs repl and not a clj repl, I 
> don't know how to do that without running the server independently.
>
> So, instead I'm just trying to get ring.middleware.reload working, but its 
> not picking up file changes. 
>
> Has anyone got this working? Alternatively, does anyone have any tips on 
> getting a nice workflow without running multiple jvm/lein instances?
>
> 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: [ANN] Pink 0.2.0, Score 0.3.0

[Steven Yi]

I'd add a few other notes:

* Overtone uses Supercollider 3 (SC3) for its audio processing.  Pink
relates more to SC3 than to Overtone, as Pink is an audio engine
library, but there's some overlap.
* You wouldn't likely use Overtone and Pink together. Score however is
a generic library and could be used with Overtone.
* Pink uses 64-bit (doubles) for its audio processing,
Overtone--because it uses SC3--uses 32-bit (floats) for its signal
processing chain
* Overtone and SC3 are much more mature systems with a pretty deep set
of signal processing and control signal generators. Pink has a lot
less functions at this time.
* Pink uses Clojure code for its signal processing, so one can write
unit generators in Clojure code, as well as study the existing unit
generator code as Clojure. You'd have to switch to C++ to read the
unit generator code in SC3 (though, I'd say the codebase for SC3 is
quite clean and easy to read, IMO)
* Pink has a slightly more functional approach to audio and events.
Overtone inherits SC3's approach, which ends up using busses for
transferring audio between Synths.  This then ends up requiring a
little more management of ordering of nodes and processing order.
* For events, because Pink's "synths" are just plain Clojure
functions, it means you can write events where the arguments to the
synths can be other audio functions. This means you could do things
like reuse a synth-patch and give a fixed value for a frequency cutoff
of a filter, but you could also pass in an LFO summed with an Envelope
and a frequency value as the value for cutoff to get a dubsteb wobble,
for just that note instance. (You could do something close in SC3 by
using synth params but you'd have to schedule a separate synth to
modify values I think.)
* Pink's event system is processed synchronously with the audio
engine. Pink also allows adding control functions to run synchronously
with the engine. This allows one to do things like temporal recursion
with events and have it done without jitter.  As far as I understand,
Overtone uses at-at, which uses a separate clock source from the SC3
engine.  That would mean there'd be possible jitter between the event
thread and the audio engine thread when firing events.
* Overtone and SC3 will likely run faster as the audio processing is
done natively. Pink is optimized pretty well for Clojure/Java, but I
don't think it will ever get as fast as SC3.  If you're expecting to
do a large amount of processing in realtime, Overtone may be the
better choice.
* Pink, however, may be a bit easier to use for non-realtime
processing. Since you can do anything synchronously with the engine,
you can run control functions and do temporal recursion even if you're
running faster than non-realtime, and you'd get the same exact results
as in realtime.

Just to note, I'm probably more familiar with SC3 than I am with
Overtone, so if I've misunderstood anything, I'm happy to be
corrected.  Also, I'd say that Overtone will probably cover more
musical use cases at this time, due to the depth of unit generators,
but Pink's design covers some use cases that Overtone can not, and
allows expressing musical ideas in a unique way.


On Tue, Jul 28, 2015 at 2:13 PM, Justin Smith  wrote:
> Overtone has its own composition logic, but for synthesis it is a client for
> the open source Supercollider audio synthesis server (which is a cross
> platform C++ program that can be controlled via the network). Pink and Score
> are built in Clojure and Java without using an external server.
>
>
> On Tuesday, July 28, 2015 at 9:54:14 AM UTC-7, W. David Jarvis wrote:
>>
>> This might be a naive question, but for someone who's only tangentially
>> familiar with the space, where does this fit in to the overall Clojure
>> music/sound ecosystem (re: overtone et al)?
>>
>> On Saturday, July 25, 2015 at 1:03:44 PM UTC-4, Steven Yi wrote:
>>>
>>> Thanks Ruslan and best of luck in your musical work!
>>>
>>> On Sat, Jul 25, 2015 at 12:24 AM, Ruslan Prokopchuk 
>>> wrote:
>>> > Steven, thank you for continuing to develop Pink & Score! I have some
>>> > music
>>> > projects as my slowly-moving-forward-hobbies, and having pure java, no
>>> > deps
>>> > like Supercollider, engine for one of them is very precious!
>>> >
>>> > пятница, 24 июля 2015 г., 23:47:30 UTC+3 пользователь Steven Yi
>>> > написал:
>>> >>
>>> >> Hi All,
>>> >>
>>> >> I'd like to announce the release of Pink 0.2.0 and Score 0.3.0:
>>> >>
>>> >> [kunstmusik/pink "0.2.0"]
>>> >> [kunstmusik/score "0.3.0"]
>>> >>
>>> >> Pink is an audio engine library, and Score is a library for
>>> >> higher-level music representations (e.g. notes, phrases, parts,
>>> >> scores).
>>> >>
>>> >> ChangeLogs are available at:
>>> >>
>>> >> https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md
>>> >> https://github.com/kunstmusik/score/blob/master/CHANGELOG.md
>>> >>
>>> >> The quick version is Pink now has some new effects (ringmod, freeverb,
>>> >> chorus) as well as some new filte

[ANN] clojure.tools.cli 0.3.2 (was: Next release for clojure.tools.cli? Is it dead?

[Sean Corfield]

clojure.tools.cli — tools for working with command line arguments

https://github.com/clojure/tools.cli

I’m pleased to announce that Sung Pae has passed the torch on to me and I have 
released version 0.3.2 to Maven Central today. Thank you Sung for all your work 
on tools.cli so far!

This release includes all of Sung’s work to date, including TCLI-9 which Keith 
Irwin asked about last week:

• Release 0.3.2 on 2015-07-28
• Add :no-defaults to parse-opts:
  Returns sequence of options that excludes defaulted ones.
  This helps support constructing options from multiple sources 
(command line, config file).
• Add get-default-options:
  Returns sequence of options that have defaults specified.
• Support multiple validations TCLI-9
• Support in-order arguments TCLI-5:
  :in-order processes arguments up to the first unknown option;
  A warning is displayed when unknown options are encountered.

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

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)




> On Jul 23, 2015, at 9:33 PM, Keith Irwin  wrote:
> 
> There are some handy additions committed to the tools.cli project at:
> 
>https://github.com/clojure/tools.cli
> 
> but there hasn’t been a release in ~1.5 years (not even a snapshot release).
> 
> In fact, these commits have been sitting there for over a year.
> 
> I’m especially interested in this one:
> 
>http://dev.clojure.org/jira/browse/TCLI-9
> 
> Any chance of a new release?

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

Small parsing bug in data.json - advice sought

[Matthew Gilliard]

Hello.  I'm interested in fixing this bug:
http://dev.clojure.org/jira/browse/DJSON-21

data.json/read currently reads from the start of a java.io.Reader and as
soon as it has a read and parsed a complete form it returns it.  This is
good and logical but it leads to input like "123abc" being parsed
successfully as 123, which is confusing enough that the bug has been raised.

Whitespace after a form like that would be fine, (ie (read-str "   123   ")
=> 123).  So my questions:

- Is it a sensible idea to consume the Reader until EOF checking that
there's only whitespace remaining?
- Can we just live with this bug as-is?
- Is there a middle ground?  (eg checking the next n bytes for
non-whitespace then stopping)
- Would it make sense if we treat 'read-str differently from 'read in this
case?

  Thanks.

Matthew

-- 
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 question about Chris Zheng's "Abstract Container Pattern"

[zcaudate]

The example in the article is probably the smallest example I can come up 
with.

http://z.caudate.me/the-abstract-container-pattern

The code for the concrete implementations speaks for itself I think, it is 
about 10 lines to hook in jetty and http-kit to the framework.

if we think about how much code an interface/abstract/concrete design 
pattern can potentially reduce over a strict interface/concrete design 
pattern in the java, then it's exactly the same with clojure.

One particular benefit of this particular pattern that I am exploiting is 
the fact that you can then specify exactly what you want in the config. I'm 
a big fan of making everything explicitly clear within the config itself so 
if we have a system with some a component-style dependency injection model 
(see http://docs.caudate.me/hara/hara-component.html), you can easily do 
something like this to get a jetty server up:

{:server {:type :jetty
   :port 8080}

and if you want a :http-kit server, you just change the config as such:

{:server {:type :http-kit
   :port 8080}

I've done this quite a bit with mocking... for example, here - 
https://github.com/MyPost/cassius/blob/master/src/cassius/component.clj

changing

{:db {:type :database}}

to

{:db {:type :mock}}

will work exactly the same way, irrespective of dependency injection 
framework - in this case, I'm using the stuartsierra/component framework.





On Tuesday, July 28, 2015 at 9:34:46 PM UTC+5:30, James Reeves wrote:
>
> What are the benefits of designing an "abstract class" in this way, 
> compared to, say, using a protocol and normal functions? Could you provide 
> a small example?
>
> - James
>
> On 28 July 2015 at 10:09, zcaudate > wrote:
>
>> Hey guys,
>>
>> Thanks for the feedback and your very insightful comments.
>>
>> Yep... this is OO alright =)
>>
>> I realised only after I wrote the article that I was implementing a 
>> Lifecycle clone with IRunnable example. However, the concept I am 
>> mentioning is much more general than components in terms of its scope:
>>
>> A similar `abstract class` for a reflective functional dispatch mechanism 
>> is defined here:
>> https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj
>>
>> and extended by the `concrete classes' here:
>> https://github.com/zcaudate/iroh/tree/master/src/iroh/element
>>
>> In the case of iroh... if I had used strictly multimethods, I would have 
>> been very confused. If I had used strictly protocols... well I couldn't for 
>> a number of reasons.. but if I did, I would have been even more confused 
>> because of the number of subconditions that I had to implement. iroh was 
>> the first library that I had built that used this pattern and it was so 
>> successful that I've been repeating the process over and over again since.
>>
>> What I wanted to achieve was to have the equivalent of an `abstract 
>> class` - the concept of code with abstract functionality that provides a 
>> framework for the heavy lifting to be done. `Concrete classes` can just 
>> extend aforementioned `abstract class` with minimal code and get all of the 
>> benefits. 
>>
>> I've used this pattern with great success in many, many times and it 
>> provides a counter balance to the functional paradigm in terms of packaging 
>> up functionality. Clojure doesn't force us into one paradigm or the other 
>> and sometimes it is just more stylish to use the OO paradigm. The whole 
>> point of OO, multimethods and protocols is to do polymorphic dispatch, 
>> which is just a way to break a large cond statement into pieces that can 
>> then also be further extended. 
>>
>> Please also note that not all OO frameworks are equal. Java uses a class 
>> inheritence approach whereas javascript uses a prototype model. The 
>> `abstract container` pattern that I was describing is probably closer to 
>> the JS model but to be honest, I don't really know what it is. Ultimately, 
>> it adds a middle tier of functionality in systems that have a plugin type 
>> mechanism. I'm sure there are equivalent functional contructs... but that 
>> was not the point of the pattern. This pattern has been very useful for me; 
>> clojure's protocols and multimethods were not enough to do what I needed to 
>> do - but combination of the two works wonders =)
>>
>> Since the article, the pattern has been codified here:
>>
>> https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196
>>
>> Hope that helps in clarifying the motivation behind the article and the 
>> pattern
>>
>>
>> Chris
>>
>>
>>
>>
>>
>>
>>
>> On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote:
>>>
>>> I think his last sentence gives you the answer:
>>>
>>> "A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all 
>>> the guys at clj-melb that gave feedback and helped flesh out this rehash of 
>>> *OO 
>>> design*.” (my emphasis)
>>>
>>> He wanted an OO approach and has implemented one; specifically behaviour

Re: [ANN] Pink 0.2.0, Score 0.3.0

[zcaudate]

This is so cool =)

Can you put up a video?

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

[Andrew Oberstar]

My use case isn't a particularly great one at that minute. It mainly just
seemed like an unfortunate extra step to interacting with Java APIs.

Essentially, I was trying to leverage APIs that return a Java Stream, but
wanted to interact with them with Clojure goodness, like
map/reduce/transduce. I ended up extending CollReduce to support
BaseStream. The lambda interaction is a pretty minimal portion of that
code, being a little more heavy in the supporting tests.

Most of my interest is projecting into the future and presuming that more
Java APIs will expect SAM arguments. If that is the case, it seems like a
beneficial thing to support in Clojure. Though it depends on the impact to
the compiler. I can see the argument either way.

Andrew Oberstar

On Mon, Jul 27, 2015 at 9:49 PM Sean Corfield  wrote:

> I think Mike was suggesting something like this:
>
> (-> (IntStream/range 0 100) (.filter ^Predicate odd?) (.limit 5) (.collect
> Collectors/toList))
>
> and having the Clojure compiler figure out that you’re trying to cast an
> IFn to a functional interface and therefore "do the magic" for you. I don’t
> know whether this is even feasible (FWIW, I certainly don’t think it is
> desirable).
>
> The compiler would have to know about all the possible functional
> interfaces in order to reify them behind the scenes for you (since each one
> has a different method name, so something needs to know how to get from the
> Java interface type to the method name behind it).
>
> I’m not sure I "get" your use case — if you’re dealing with that much Java
> interop it seems like it might be a good idea to create a DSL (functions,
> maybe macros) that make the code cleaner and "hide" the low-level details
> of Java interop anyway. Besides, your example sounds like something Clojure
> can already do natively and much more cleanly. Can you perhaps give us more
> detailed motivation for what you’re trying to achieve? Perhaps there’s a
> cleaner way altogether…?
>
> Sean
>
> On Jul 27, 2015, at 6:53 PM, 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 
> 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 
>>> wrote:
>>>
 On Sunday, 26 July 2015, Andrew Oberstar  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 transparent

Re: a question about Chris Zheng's "Abstract Container Pattern"

[James Reeves]

On 29 July 2015 at 01:07, zcaudate  wrote:

> The example in the article is probably the smallest example I can come up
> with.
>
> http://z.caudate.me/the-abstract-container-pattern
>
> The code for the concrete implementations speaks for itself I think, it is
> about 10 lines to hook in jetty and http-kit to the framework.
>

I'm afraid I don't see the benefit of having two tiers of abstraction in
your example. I think you could achieve the same result with a simpler
architecture.

For example, consider a protocol:

  (defprotocol Lifecycle
(-start [service])
(-stop [service]))

We can add additional functionality around this simply by wrapping the
protocol methods with functions:

  (defn start [service]
(if (:started? service)
  service
  (-> service -start (assoc :started? true

  (defn stop [service]
(if-not (:started? service)
  service
  (-> service -stop (dissoc :started?

So in this case we're adding idempotence and a key to determine whether or
not the service has been started. We assume that a service is a record that
implements Lifecycle.

We could also conceive of a function that globally registers services for
convenience:

  (def running-services (atom #{}))

  (defn register! [service]
(swap! running-services conj service))

  (defn deregister! [service]
(swap! running-services disj service))

Then work that into the start and stop functions:

  (defn start [service]
(if (:started? service)
  service
  (-> service -start (assoc :started? true) (doto register!

  (defn stop [service]
(if-not (:started? service)
  service
  (-> service (doto deregister!) -stop (dissoc :started?

Now, if we actually want to create a service for an adapter like Jetty:

  (defrecord JettyService [handler options]
Lifecycle
(-start [service]
  (assoc service :instance (run-jetty handler (assoc options :join?
false)))
(-stop [service]
  (.stop (:instance service))
  (dissoc service :instance)))

Unless I've missed something, that seems like broadly equivalent
functionality, but with arguably less complexity. We stick with functions
for the most part, and only use polymorphism where it's necessary.

- James

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