Re: [ANN]: clambda 0.1.4 - reducible Java Streams
Yep, that helps. Thanks! On Fri, Aug 10, 2018 at 2:42 AM Dimitrios Jim Piliouras < jimpil1...@gmail.com> wrote: > Hi Andrew, > > Well, for the native java Stream case, your 'early-spliterator' has to be > able to split the Spliterator it's wrapping instead of always returning > nil. For the Stream around a seq case, you need to ditch 'iterator-seq', > and implement something splitable. See my SeqSpliterator deftype... > > Hope that helps đ > > Excuse my brevity - Sent from my phone > Dimitris > > > On Fri, 10 Aug 2018, 00:09 Andrew Oberstar, wrote: > >> Dimitris, always glad to see people improving Java interop! Nice work! >> >> I noticed your mention of my library (ike.cljj) in the readme and was >> curious about the parallel streams. I haven't had a use case for them in >> any of my stream work so far, so I didn't think to test it when I wrote >> ike.cljj. Is the missing piece to support parallel the combine function? >> >> Andrew Oberstar >> >> On Thu, Aug 9, 2018 at 11:05 AM dimitris wrote: >> >>> Damn! Here is the correct link: >>> >>> https://github.com/jimpil/clambda >>> >>> On 09/08/18 17:03, dimitris wrote: >>> >>> Hi folks, >>> >>> https://github.com/jimpil/clambda <https://github.com/jimpil/clamda> >>> >>> *clambda* is a little library for working with Java Streams from >>> Clojure, and to a lesser extend, for working with Clojure seqs from Java. >>> Parallel streams are fully supported, but there are some gotchas (described >>> in the README). Convenience helper for constructing Lambdas on-demand from >>> plain Clojure functions, exists as well. >>> >>> This library was motivated by the memory-mapped parallel stream returned >>> by `Files.lines()` in JDK9. We can now take *full* advantage of it (and >>> other Streams like it) from Clojure. >>> >>> Enjoy & feedback is always welcome ;) >>> >>> Kind regards, >>> >>> Dimitris >>> ps: I didn't even try to have the misspelled `clamda` removed from >>> clojars as my reason clearly didn't qualify. I did push a new version with >>> the "DEPRECATED" prefix, so hopefully there won't be any confusion. Again, >>> apologies... >>> >>> >>> <https://github.com/jimpil/clamda> >>> >>> >>> <https://github.com/jimpil/clamda> >>> >>> >>> <https://github.com/jimpil/clamda> >>> >>> >>> -- >>> 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. >>> >> -- >> 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. >> > -- > 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.
Re: [ANN]: clambda 0.1.4 - reducible Java Streams
Dimitris, always glad to see people improving Java interop! Nice work! I noticed your mention of my library (ike.cljj) in the readme and was curious about the parallel streams. I haven't had a use case for them in any of my stream work so far, so I didn't think to test it when I wrote ike.cljj. Is the missing piece to support parallel the combine function? Andrew Oberstar On Thu, Aug 9, 2018 at 11:05 AM dimitris wrote: > Damn! Here is the correct link: > > https://github.com/jimpil/clambda > > On 09/08/18 17:03, dimitris wrote: > > Hi folks, > > https://github.com/jimpil/clambda <https://github.com/jimpil/clamda> > > *clambda* is a little library for working with Java Streams from Clojure, > and to a lesser extend, for working with Clojure seqs from Java. Parallel > streams are fully supported, but there are some gotchas (described in the > README). Convenience helper for constructing Lambdas on-demand from plain > Clojure functions, exists as well. > > This library was motivated by the memory-mapped parallel stream returned > by `Files.lines()` in JDK9. We can now take *full* advantage of it (and > other Streams like it) from Clojure. > > Enjoy & feedback is always welcome ;) > > Kind regards, > > Dimitris > ps: I didn't even try to have the misspelled `clamda` removed from clojars > as my reason clearly didn't qualify. I did push a new version with the > "DEPRECATED" prefix, so hopefully there won't be any confusion. Again, > apologies... > > > <https://github.com/jimpil/clamda> > > > <https://github.com/jimpil/clamda> > > > <https://github.com/jimpil/clamda> > > > -- > 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. > -- 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] gradle-clojure 0.4.0 (adding ClojureScript support)
gradle-clojure <https://github.com/gradle-clojure/gradle-clojure> is a Gradle plugin supporting Clojure and (now) ClojureScript development. The 0.4.0 release adds support for ClojureScript compilation and Figwheel Main. For those not familiar with Gradle <https://gradle.org/>, it's a JVM-based build tool that supports many JVM (and not) languages. It has a large plugin ecosystem and is used by many companies with existing JVM codebases. The goals of gradle-clojure are to: - Allow existing users of Gradle to add Clojure into their environments without switching build tools. - Try to provide the creature comforts of Leiningen and Boot in Gradle. Current features include: - clojure.test execution (as part of Gradle's existing infrastructure) - Clojure AOT compilation - uberjar packaging - ClojureScript compilation - nREPL server (including Figwheel Main support) - project templates (leveraging clj-new) See our documentation <https://gradle-clojure.github.io/gradle-clojure/> (which is definitely in need of improvement) for details on how to use the plugin. If you have further questions, visit the ClojureVerse gradle-clojure category <https://clojureverse.org/c/projects/gradle-clojure> or the #gradle Clojurian's Slack channel <http://clojurians.net>. Thanks to Colin Fleming for the initial code and Piotrek Bzdyl for his contributions (most notably the first cut of this ClojureScript support)! Andrew Oberstar -- 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: 1.9 is close to 2.0...
I would expect 1.10 is next. Andrew Oberstar On Thu, Dec 28, 2017 at 4:58 PM Jacob Goodson wrote: > Now that clojure 1.9 is out, will future releases be 1.91, 1.92, etc? > > Or, are talks in place for a clojure 2.0? > > If there is discussion of clojure 2.0, what would that look like? > > Clojure running on graal, clojure (the people behind it) doing some other > fantastically amazing thing? > > Just curious... > > -- > 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. > -- 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] Lightmod, an all-in-one tool for full stack Clojure
This is really cool! Nice job! Andrew Oberstar On Sat, Nov 4, 2017 at 12:50 PM Zach Oakes wrote: > Today I'm releasing a new tool that lets you make full stack Clojure web > apps without any build tools or even any system-wide JDK install. It runs > everything internally and gives a very integrated experience that I think > is great for newcomers. You are limited to the libraries that I bundled > with the tool, so this is just meant to be a smoother stepping stone before > you take the red pill and become a full clojure acolyte. Anyway here's the > website: > > https://sekao.net/lightmod/ > > Check out the screencast on the website to see it in action. Please let me > know when you find bugs...my first releases are always pretty shaky. 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. > -- 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: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
What about a compromise where you could opt-in or opt-out of checking macro specs at compile time (via a compiler option)? It seems worth preserving the correctness of the spec, without forcing all of the breakage. Andrew Oberstar On Sat, Aug 20, 2016 at 9:13 PM Colin Fleming wrote: > With respect to preserving undocumented behaviour, while in general I'm in > favour of making compilers stricter, in this case it seems like the change > breaks a lot of existing code in ways that are impossible for library > consumers to fix themselves - they have to wait for an update to the > library, or fork it. Leaving the symbol option seems like a very low-impact > change, it's not going to be a massive amount of technical debt in Clojure > itself. There are many areas of unspecified behaviour in the reader (for > example, keywords starting with numbers, the keyword function allowing > creation of unreadable keywords etc) which have not been fixed because it > would break some existing code - I suspect the impact of fixing that would > be far less than the impact of this change. > > I don't understand why this particular change is so important that > significant breakage to real code is considered acceptable. I agree with > Brian that it doesn't seem very pragmatic. > > On 21 August 2016 at 13:22, Brian Marick wrote: > >> >> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge >> wrote: >> >> Brian, let's make it more concrete then...why should the Clojure compiler >> continue to support undocumented features that make code unportable? >> >> >> Because: >> >> 1. People who want to port to clojurescript will incur exactly the same >> cost as they do now. >> 2. People who donât want to port to clojurescript will incur no >> additional cost. >> 3. Clojurescript maintainers will incur no additional cost. >> 4. Clojure maintainers will incur the cost of adding âor symbolâ to >> current code. >> 5. No one writing documentation will incur any cost, as what was not >> mentioned before will continue to be unmentioned. >> >> 6. There will be a psychic cost because of an undocumented inconsistency >> between clojure and clojurescript. >> 7. If, at some point, clojure and clojurescript shared code for the >> implementation of `ns`, one or the other would have to change the pre >> 1.9-alpha11 behavior. >> >> Do I have this enumeration of costs wrong? >> >> Itâs a bit surprising to me that my explicit appeal to consider costs and >> benefits to real people is not being addressed. >> >> -- >> 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. >> > > -- > 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. > -- 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: Idea: standardised way of packaging docs inside jar
Not very familiar with it, but is the Grenada/datadoc project along the lines you were thinking? I think that was a Google Summer of Code project last year. Andrew Oberstar On Tue, May 31, 2016, 5:37 AM Arnout Roemers wrote: > Hi all, > > This is a copy from the question I posed at codox > <https://github.com/weavejester/codox/issues/126#issuecomment-218504883>: > > I was thinking that maybe a good addition to the Clojure documentation > ecosystem would be to have a standardised way of including project > documentation inside the project artefact (JAR). This documentation could > then be searched and read locally (and offline!), and could also be > aggregated on any of the community websites. So, in short, a kind of Ruby's > rdoc for Clojure. > > I think the input (and maybe also the output?) of Codox is great for this. > Maybe a good standard would be to put this in a META-INF/codox directory? > > How do others feel about this? Does something like this exist already, and > did I just miss it? I'd love to hear! > > > Cheers, > > > Arnout > > -- > 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. > -- 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: Add support for seq on Java streams?
If you want to use reduce or transducers on a stream, you could take a look at ike.cljj (shameless plug). Depending on your use case, it might not provide a lot of benefit over Gary's suggestion. https://github.com/ike-tools/ike.cljj Andrew Oberstar On Wed, Feb 24, 2016 at 7:07 AM <676c7...@gmail.com> wrote: > Thanks, Alex and Gary. > > I understand that Java 8 is not yet on the roadmap, so iterator-seq > seems like the best solution. > > -- > 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. > -- 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] Graclj 0.1.0 -- New Gradle Plugin for Clojure
Yeah, something closer to that picture is what I'd prefer for a logo. I ended up just grabbing the first public domain drawing I could find. On Mon, Feb 15, 2016 at 9:06 AM Michael Willis wrote: > In the event that you're looking for a logo, consider an artistic icon > based on this: https://en.wikipedia.org/wiki/Common_grackle > > > On Sunday, February 14, 2016 at 8:11:00 PM UTC-6, Andrew Oberstar wrote: >> >> I just released the first version of Graclj, which is a new Gradle plugin >> for Clojure. The goal is to make something that feels native to Gradle, >> while giving the creature comforts Clojurians are used to from lein or >> boot. For those familiar with Gradle, this targets their new (and still >> evolving) software model support. >> >> Current features include: >> >> - Packaging Clojure code into JARs >> - AOT compilation >> - clojure.test execution >> - Publishing to any repo supported by Gradle (including Clojars) >> >> I wouldn't suggest dropping your current build tool yet, but if you'd >> like to try it out, you can walk through the learning-graclj repo. I'd >> welcome any feedback on the plugin or documentation. >> >> Source: https://github.com/graclj/graclj >> Documentation: >> https://github.com/graclj/learning-graclj/tree/learning-0.1.0 >> >> Thanks, >> Andrew Oberstar >> >> -- > 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. > -- 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] Graclj 0.1.0 -- New Gradle Plugin for Clojure
I just released the first version of Graclj, which is a new Gradle plugin for Clojure. The goal is to make something that feels native to Gradle, while giving the creature comforts Clojurians are used to from lein or boot. For those familiar with Gradle, this targets their new (and still evolving) software model support. Current features include: - Packaging Clojure code into JARs - AOT compilation - clojure.test execution - Publishing to any repo supported by Gradle (including Clojars) I wouldn't suggest dropping your current build tool yet, but if you'd like to try it out, you can walk through the learning-graclj repo. I'd welcome any feedback on the plugin or documentation. Source: https://github.com/graclj/graclj Documentation: https://github.com/graclj/learning-graclj/tree/learning-0.1.0 Thanks, Andrew Oberstar -- 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?
That's great! Andrew Oberstar On Tue, Sep 1, 2015, 11:25 PM Patrick Gombert wrote: > There is an effort underway to port the stdlib to clojure named > clojure.core <https://github.com/mylesmegyesi/clojure.core>. The idea is > to eventually to move off of clojure and bootstrap it with the clojure in > clojure compiler, but that's a ways off. Here > <https://github.com/mylesmegyesi/clojure.core/milestones> is a list of > implement functions from core. > > > On Monday, August 24, 2015 at 10:03:00 AM UTC-5, 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 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. > -- 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] ike.cljj 0.2.2
After some lein mishaps, 0.2.2 (which is really 0.2.0) is now available through Clojars. ike.cljj is meant to support better interop with Java 7/8 APIs (such as Stream and Function). The sole addition in 0.2.2 is the ike.cljj.file namespace which provides wrappers for java.nio.file APIs. https://github.com/ike-tools/ike.cljj Andrew Oberstar -- 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] ike.cljj 0.1.0
Just released the first version of ike.cljj, which is a library of Clojure to Java interop APIs. https://github.com/ike-tools/ike.cljj Current Support: * Reducing over Streams. * Converting Clojure functions to any arbitrary Single Abstract Method (SAM) interface (e.g. any of the java.util.function ones). * Wrappers for java.lang.invoke (MethodHandles API) since it was used for the SAM conversion. Any feedback is welcome. Thanks! Andrew Oberstar -- 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 beyond Java 6 ?
I may end up in the same incomplete, unmaintained state as the other libraries you've seen, but I'm slowly starting on a Java interop library "cljj" (https://github.com/ike-tools/ike.cljj). - AutoCloseable - As James (Reeves) mentioned, clojure.core/with-open meets this need. - NIO2 - Standard Java interop is functional, but can be a pain due to the heavy use of varargs in NIO2 APIs. I'd like to wrap this in cljj. - Streams - Can add reduce/transduce support by implementing CollReduce protocol. There's not a clean way to support the clojure.core/seq function, that I've seen without wrapping the stream. I plan to support this in cljj. - Lambdas - I do find these to be a pain, and had a thread on this list a week or two ago. Right now I'm planning to just have functions/macros to wrap/define methods implementing java.util.function interfaces. Ideally, the compiler would support this better. This is the only one that really would require any change to Clojure itself for better Java 8 support IMO. I can understand James' (Elliott) desire to keep Java 6 compatibility for platforms that are slower to adopt newer JVMs, but I hope that doesn't become an excuse for Clojure to stay moored to the JVM's past for the long-term. Andrew Oberstar On Fri, Aug 7, 2015 at 7:12 AM Morten Christensen wrote: > I am new to Clojure which I am evaluating using Clojure for a Java 8 based > framework with code in clojure, java and possibly other jvm based languages > that all need to interoperate. > > Clojure has many smart features which I like but there is at least one > drawback. I could be wrong (?) but it appears to me that feature-wise it is > limited to a legacy version of java - Java version 6 from 2008. > > Happily Clojure tolerate running under Java 7/8 but I have found no > specific support for Java 7/8 features. In particular there is no support > for NIO 2.0 or interoperability support for @FunctionalInterface, > java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc. > > I could do my own Clojure wrapper for NIO 2 but it seems to be quite hard > for that particular tech (other people in the community have tried without > being 100% complete and could not find anything that is actively > maintained). All the other stuff seems like something that need in Clojure > itself along with invokedynamic and other optimizations. > > Is there any plans for actively supporting Java 7/8 ? > > /Morten > > -- > 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. > -- 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
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 &
Re: Java 8 Lambda Interop
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] (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 >>>
Re: Java 8 Lambda Interop
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] (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 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. > -- 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.
Java 8 Lambda Interop
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 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] Introducing Yagni, a Leiningen plugin for finding unused code
Haven't tried it yet, but looks good. Nice work! Andrew Oberstar On Tue, Jun 23, 2015 at 12:39 PM W. David Jarvis wrote: > Hello everyone. > > I'm happy to announce the initial release of Yagni, a Leiningen plugin for > finding unused code. > > At a high level, Yagni works by identifying all of the interned vars in > the namespaces findable within your :source-paths, and then walking the > forms of those vars. > > As it walks the forms, it builds a graph of references to other vars. It > then searches the graph from a set of entrypoints (by default your > project's :main method), and emits warnings for any vars that it couldn't > find in the graph's search. > > There's some other clever stuff going on there and some options for > additional customization as well. I've written up a blog post, located > here <http://blog.venanti.us/yagni/>, that goes into considerably more > detail on how the plugin works and what the project's roadmap looks like. > > For those of you who want to look at the repository, it's on GitHub here: > https://github.com/venantius/yagni > > And, of course, for those of you who just want to get started fiddling, > you can add the following to your project's plugins map `[venantius/yagni > "0.1.1"]` and type `lein yagni` to give it a whirl. > > Cheers! > > - V > > -- > 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. > -- 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] Demo of the Holy Grail workflow
Silly me, my computer was muted... I'll watch it again. On Sat, May 23, 2015 at 8:27 AM Andrew Oberstar wrote: > I can play the video, but there's no sound. Looks interesting though. > > > Andrew Oberstar > > On Fri, May 22, 2015 at 3:06 PM Daniel Szmulewicz < > daniel.szmulew...@gmail.com> wrote: > >> Sorry about that. Some countries are prevented from watching this video >> on Youtube. I've uploaded the video on Vimeo to offer an alternative. >> Please try it out. It seems that on Vimeo you need to turn HD on manually >> to benefit from the maximum resolution. >> >> https://vimeo.com/128624743 >> >> Best of luck. >> >> On Friday, May 22, 2015 at 9:53:24 PM UTC+3, albins wrote: >> >>> I can't play it in Sweden either. :( >>> >> On 22 May 2015 04:58, "Shaun Mahood" wrote: >>> >> Can't play it in Canada from my mobile. >>>> >>>> -- >>>> 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. >> > -- 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] Demo of the Holy Grail workflow
I can play the video, but there's no sound. Looks interesting though. Andrew Oberstar On Fri, May 22, 2015 at 3:06 PM Daniel Szmulewicz < daniel.szmulew...@gmail.com> wrote: > Sorry about that. Some countries are prevented from watching this video on > Youtube. I've uploaded the video on Vimeo to offer an alternative. Please > try it out. It seems that on Vimeo you need to turn HD on manually to > benefit from the maximum resolution. > > https://vimeo.com/128624743 > > Best of luck. > > On Friday, May 22, 2015 at 9:53:24 PM UTC+3, albins wrote: > >> I can't play it in Sweden either. :( >> > On 22 May 2015 04:58, "Shaun Mahood" wrote: >> > Can't play it in Canada from my mobile. >>> >>> -- >>> 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. > -- 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: Announcing oolong: a config-based glue for `component`
Just a quick look so far, but it looks pretty interesting. I'm working on a multi-module project and I'd like to have the flexibility to run those modules separately or together. Extracting the component structure out into a config file could be pretty helpful in that regard. Nice work! Andrew Oberstar On Tue, Mar 17, 2015 at 5:02 AM James Laver wrote: > I've been using stuartsierra's handy component library for a while now, > but I wanted an easier way of connecting components together. > > To that end, I wrote oolong. The main mode of operation is to take an edn > configuration file and connect the specified systems and components. > > https://github.com/jjl/oolong > > https://clojars.org/oolong > > Feedback welcome. I spent quite a while documenting it so hopefully it > should be fairly clear to understand. > > 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. > -- 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: "Easier" Idempotent Component Lifecycles?
I was able to do this without a macro. Here's what I have now:
(defprotocol IdempotentLifecycle
(-started? [this])
(-start [this])
(-stop [this]))
(defn extend-lifecycle [atype]
(extend atype
component/Lifecycle
{:start (fn [this]
(if (-started? this)
this
(-start this)))
:stop (fn [this]
(if (-started? this)
(-stop this)
this))}))
I had to use extend and not one of the extend-type or extend-protocol
macros. Haven't dug into why yet. The usage for this would now be:
(defrecord SillyExample [started]
IdempotentLifecycle
(-started? [this] (:started this))
(-start [this] (update this :started not))
(-stop [this] (update this :started not)))
(extend-lifecycle SillyExample)
So it seems like this approach results in implementation sharing without
implementation inheritance. Is that the more general Clojure approach to
reach for when an OO-programmer would usually reach for an abstract class?
Andrew Oberstar
On Sun, Mar 15, 2015 at 1:36 PM Andrew Oberstar
wrote:
> Sure, that makes sense. I'll give that a go along with a few other ideas,
> and see what works out best. Thanks for the help!
>
>
> Andrew Oberstar
>
> On Sun, Mar 15, 2015 at 1:22 PM Colin Yates wrote:
>
>> I don't have one at hand (as I literally wrote my first macro last
>> week ;)) but the way it could work is something like:
>>
>> (defmacro idempotent-component
>> [{:keys [name start started? stop]}]
>> `(defrecord (symbol name) [...]
>> component/Lifecycle
>> (start [this#]
>> (if (~'started? this#)
>> this#
>> (~' this)))
>> (stop [this#]
>> (if (~'started? this#)
>> (~`stop this#)
>> this)))
>>
>> and called like
>>
>> (idempotent-component {:name "SillyExample" start: println started?:
>> (constantly true) stop: println})
>>
>> There are probably a 100 things wrong with that macro and possiblly
>> even the idea of using a macro here, but hopefully it opens up the
>> possibilities.
>>
>> On 15 March 2015 at 17:40, Andrew Oberstar wrote:
>> > Thanks, Colin. Macros hadn't crossed my mind, so it's good to have them
>> > pointed out. Do you have a macro you could post that is a good example
>> of
>> > enforcing a pattern as an implementation detail? I think that's a good
>> > general consideration, but I don't believe it fits this use case.
>> Though an
>> > example may be more illuminating.
>> >
>> > In some ways, this use case seems akin to the implementation of nth in
>> > ClojureScript, where it's exact behavior can differ depending on the
>> > protocols satisfied by the passed collection.
>> >
>> > Looking back through the component docs, update-system and
>> > update-system-reverse may be the key piece for implementing something
>> like
>> > the LifecycleStatus solution in my original email without requiring any
>> > change to component itself. The big weakness is that it would require
>> using
>> > a custom start-system stop-system function rather than the standard one.
>> >
>> > Andrew Oberstar
>> >
>> > On Sun, Mar 15, 2015 at 11:32 AM Colin Yates
>> wrote:
>> >>
>> >> In OO we tend to solve the 'copy and paste' problem with abstract
>> >> classes. In Clojure we also have macros, easily overused, sure, but
>> >> worth knowing about. They turn the problem on its head and allow truly
>> >> composable functionality. I am not stating they _are_ appropriate
>> >> here, only that you might want to think about them; whenever I have a
>> >> 'I want this pattern enforced, but it is really just an implementation
>> >> detail', a macro is sometimes the answer.
>> >>
>> >> On 15 March 2015 at 15:58, Andrew Oberstar
>> wrote:
>> >> > I'm fairly new to Clojure, so I'm still struggling to unlearn the
>> habits
>> >> > of
>> >> > OO-programming. While using Stuart Sierra's component library, I've
>> >> > found
>> >> > the recommendation in the docs of using idempotent lifecycles very
>> >> > helpful.
>> >> > The unfortunate result is that every component then has the same
>> pattern
>> >> > in
>> >> > its start and stop methods:
>> >> >
>> >> > (defrecord SillyExample [
Re: "Easier" Idempotent Component Lifecycles?
Sure, that makes sense. I'll give that a go along with a few other ideas,
and see what works out best. Thanks for the help!
Andrew Oberstar
On Sun, Mar 15, 2015 at 1:22 PM Colin Yates wrote:
> I don't have one at hand (as I literally wrote my first macro last
> week ;)) but the way it could work is something like:
>
> (defmacro idempotent-component
> [{:keys [name start started? stop]}]
> `(defrecord (symbol name) [...]
> component/Lifecycle
> (start [this#]
> (if (~'started? this#)
> this#
> (~' this)))
> (stop [this#]
> (if (~'started? this#)
> (~`stop this#)
> this)))
>
> and called like
>
> (idempotent-component {:name "SillyExample" start: println started?:
> (constantly true) stop: println})
>
> There are probably a 100 things wrong with that macro and possiblly
> even the idea of using a macro here, but hopefully it opens up the
> possibilities.
>
> On 15 March 2015 at 17:40, Andrew Oberstar wrote:
> > Thanks, Colin. Macros hadn't crossed my mind, so it's good to have them
> > pointed out. Do you have a macro you could post that is a good example of
> > enforcing a pattern as an implementation detail? I think that's a good
> > general consideration, but I don't believe it fits this use case. Though
> an
> > example may be more illuminating.
> >
> > In some ways, this use case seems akin to the implementation of nth in
> > ClojureScript, where it's exact behavior can differ depending on the
> > protocols satisfied by the passed collection.
> >
> > Looking back through the component docs, update-system and
> > update-system-reverse may be the key piece for implementing something
> like
> > the LifecycleStatus solution in my original email without requiring any
> > change to component itself. The big weakness is that it would require
> using
> > a custom start-system stop-system function rather than the standard one.
> >
> > Andrew Oberstar
> >
> > On Sun, Mar 15, 2015 at 11:32 AM Colin Yates
> wrote:
> >>
> >> In OO we tend to solve the 'copy and paste' problem with abstract
> >> classes. In Clojure we also have macros, easily overused, sure, but
> >> worth knowing about. They turn the problem on its head and allow truly
> >> composable functionality. I am not stating they _are_ appropriate
> >> here, only that you might want to think about them; whenever I have a
> >> 'I want this pattern enforced, but it is really just an implementation
> >> detail', a macro is sometimes the answer.
> >>
> >> On 15 March 2015 at 15:58, Andrew Oberstar
> wrote:
> >> > I'm fairly new to Clojure, so I'm still struggling to unlearn the
> habits
> >> > of
> >> > OO-programming. While using Stuart Sierra's component library, I've
> >> > found
> >> > the recommendation in the docs of using idempotent lifecycles very
> >> > helpful.
> >> > The unfortunate result is that every component then has the same
> pattern
> >> > in
> >> > its start and stop methods:
> >> >
> >> > (defrecord SillyExample [...]
> >> > component/Lifecycle
> >> > (start [this]
> >> > (if (custom-started-check? this)
> >> > this
> >> > (custom-start-logic this)))
> >> > (stop [this]
> >> > (if (custom-started-check? this)
> >> > (custom-stop-logic this)
> >> > this)))
> >> >
> >> > It adds some extra nesting and, potentially, duplication of the
> started
> >> > check's logic. In hopes of making idempotent lifecycles easier to
> >> > implement,
> >> > I made the following protocol, which seems to violate the
> implementation
> >> > inheritance philosophy of Clojure.
> >> >
> >> > (defprotocol IdempotentLifecycle
> >> > (started? [this])
> >> > (safe-start [this])
> >> > (safe-stop [this]))
> >> >
> >> > (extend-protocol component/Lifecycle
> >> > my.ns.IdempotentLifecycle
> >> > (start [this]
> >> > (if (started? this)
> >> > this
> >> > (safe-start this)))
> >> > (stop [this]
> >> > (if (started? this)
> >> > (safe-stop this)
> >> > this)))
> >> >
> >> > So then a use case would like more like:
>
Re: "Easier" Idempotent Component Lifecycles?
Thanks, Colin. Macros hadn't crossed my mind, so it's good to have them pointed out. Do you have a macro you could post that is a good example of enforcing a pattern as an implementation detail? I think that's a good general consideration, but I don't believe it fits this use case. Though an example may be more illuminating. In some ways, this use case seems akin to the implementation of nth in ClojureScript, where it's exact behavior can differ depending on the protocols satisfied by the passed collection. Looking back through the component docs, update-system and update-system-reverse may be the key piece for implementing something like the LifecycleStatus solution in my original email without requiring any change to component itself. The big weakness is that it would require using a custom start-system stop-system function rather than the standard one. Andrew Oberstar On Sun, Mar 15, 2015 at 11:32 AM Colin Yates wrote: > In OO we tend to solve the 'copy and paste' problem with abstract > classes. In Clojure we also have macros, easily overused, sure, but > worth knowing about. They turn the problem on its head and allow truly > composable functionality. I am not stating they _are_ appropriate > here, only that you might want to think about them; whenever I have a > 'I want this pattern enforced, but it is really just an implementation > detail', a macro is sometimes the answer. > > On 15 March 2015 at 15:58, Andrew Oberstar wrote: > > I'm fairly new to Clojure, so I'm still struggling to unlearn the habits > of > > OO-programming. While using Stuart Sierra's component library, I've found > > the recommendation in the docs of using idempotent lifecycles very > helpful. > > The unfortunate result is that every component then has the same pattern > in > > its start and stop methods: > > > > (defrecord SillyExample [...] > > component/Lifecycle > > (start [this] > > (if (custom-started-check? this) > > this > > (custom-start-logic this))) > > (stop [this] > > (if (custom-started-check? this) > > (custom-stop-logic this) > > this))) > > > > It adds some extra nesting and, potentially, duplication of the started > > check's logic. In hopes of making idempotent lifecycles easier to > implement, > > I made the following protocol, which seems to violate the implementation > > inheritance philosophy of Clojure. > > > > (defprotocol IdempotentLifecycle > > (started? [this]) > > (safe-start [this]) > > (safe-stop [this])) > > > > (extend-protocol component/Lifecycle > > my.ns.IdempotentLifecycle > > (start [this] > > (if (started? this) > > this > > (safe-start this))) > > (stop [this] > > (if (started? this) > > (safe-stop this) > > this))) > > > > So then a use case would like more like: > > > > (defrecord SillyExample [...] > > IdempotentLifecycle > > (started? [this] > > (custom-started-check this)) > > (safe-start [this] > > (custom-start-logic this)) > > (safe-stop [this] > > (custom-stop-logic this))) > > > > This seems like an easier end-user experience, but it feels wrong to > > implement a protocol with another protocol. A more "Clojurey" feeling > option > > would require changes to the component library itself: > > > > (defprotocol LifecycleStatus > > (started? [this])) > > > > (extend-protocol LifecycleStatus > > java.lang.Object > > (started? [_] false)) > > > > ;; Lifecycle protocol stays as-is > > > > (defn safe-start [component] > > (if (started? component) > > this > > (start component))) > > > > (defn safe-stop [component] > > (if (started? component) > > (stop component) > > this)) > > > > Then component would need to use safe-start/safe-stop in place of regular > > start/stop in the start-system/stop-system functions. > > > > Maybe this is better suited to an issue/pr on his repository, but I > wanted > > to see if there were any comments from the community. Is there a better > way > > to do this? > > > > Andrew Oberstar > > > > -- > > 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 unsubs
"Easier" Idempotent Component Lifecycles?
I'm fairly new to Clojure, so I'm still struggling to unlearn the habits of OO-programming. While using Stuart Sierra's component library, I've found the recommendation in the docs of using idempotent lifecycles very helpful. The unfortunate result is that every component then has the same pattern in its start and stop methods: (defrecord SillyExample [...] component/Lifecycle (start [this] (if (custom-started-check? this) this (custom-start-logic this))) (stop [this] (if (custom-started-check? this) (custom-stop-logic this) this))) It adds some extra nesting and, potentially, duplication of the started check's logic. In hopes of making idempotent lifecycles easier to implement, I made the following protocol, which seems to violate the implementation inheritance philosophy of Clojure. (defprotocol IdempotentLifecycle (started? [this]) (safe-start [this]) (safe-stop [this])) (extend-protocol component/Lifecycle my.ns.IdempotentLifecycle (start [this] (if (started? this) this (safe-start this))) (stop [this] (if (started? this) (safe-stop this) this))) So then a use case would like more like: (defrecord SillyExample [...] IdempotentLifecycle (started? [this] (custom-started-check this)) (safe-start [this] (custom-start-logic this)) (safe-stop [this] (custom-stop-logic this))) This seems like an easier end-user experience, but it feels wrong to implement a protocol with another protocol. A more "Clojurey" feeling option would require changes to the component library itself: (defprotocol LifecycleStatus (started? [this])) (extend-protocol LifecycleStatus java.lang.Object (started? [_] false)) ;; Lifecycle protocol stays as-is (defn safe-start [component] (if (started? component) this (start component))) (defn safe-stop [component] (if (started? component) (stop component) this)) Then component would need to use safe-start/safe-stop in place of regular start/stop in the start-system/stop-system functions. Maybe this is better suited to an issue/pr on his repository, but I wanted to see if there were any comments from the community. Is there a better way to do this? Andrew Oberstar -- 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 nicer way to write 1 - 2 + 3 - 4 ... +/- n
How about this? (defn cyclefn [& fs] (let [fcycle (cycle fs) rem-fs (atom fcycle)] (fn [& args] (let [f (first @rem-fs)] (swap! rem-fs rest) (apply f args) (reduce (cyclefn + -) (range 1 100)) cyclefn could be used to cycle through any set of functions you want and the result used as if it was a normal function. Andy On Fri, Nov 14, 2014 at 7:16 AM, Henrik Lundahl wrote: > How about this? :-) > > (defn altsum [n] (/ (if (odd? n) (+ 1 n) (- n)) 2)) > > -- > Henrik > > > On Fri, Nov 14, 2014 at 1:48 PM, Gary Verhaegen > wrote: > >> What about cheating a bit? >> >> (interleave >> (iterate #(+ % 2) 1) >> (iterate #(- % 2) -2)) >> >> Then take n, reduce +, or whatever else you might want to do with the >> series. >> >> -- >> 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. >> > > -- > 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. > -- 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] ike.tk.httpkit 0.1.0 - Trapperkeeper service for http-kit
Just released v0.1.0 of ike.tk.http which provides a Trapperkeeper service that starts http-kit. The http-kit-service expects another service implementing the HandlerService protocol to provide the Ring handler. This is my very first Clojure experience, so any feedback is welcome. More details, including a sample app below: https://github.com/ike-tools/ike.tk.httpkit Andrew Oberstar -- 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.
