Clojure In: An interview with Sean Corfield
Hi everyone :) I recently interviewed Sean Corfield about his work with Clojure at World Singles Networks. Firstly, I'd like to say a big thank-you to Sean for taking time out on his trip to the UK to have lunch with me and for kindly letting me interview him. His real life personality is as friendly as his online persona. It was a really enjoyable interview so I hope that anyone who reads it will enjoy it as much as I have writing it up. https://juxt.pro/blog/posts/clojure-in-seattle-world-singles-networks.html Best wishes, Andrew P.S. If you have a twitter account, please RT the Clojure love :) https://twitter.com/juxtpro/status/1049957394489462784 tps://twitter.com/juxtpro/status/1049957394489462784 -- 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]: 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.com > For more options, visit this group at
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: numeric-tower versus clojure 1.9
OK, it seems to have been an emacs issue rather than a cider one, at least after tweaking a few emacs configs related to help-mode I'm no longer having the problem. Thanks for your patience. -- 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: numeric-tower versus clojure 1.9
On Friday, January 19, 2018 at 5:05:50 PM UTC-5, puzzler wrote: > > You seem to be requiring the numeric-tower functions into the foobar.core > namespace, and then "use"ing the foobar.core namespace from the user > namespace and expecting the numeric-tower functions to show up in the user > namespace. However, namespaces aren't transitive like that. You need to > require math.numeric-tower from user if you intend to use it from user, or > change your namespace to foobar.core in the REPL. > Ah, OK, then I'm back to thinking it is just a cider issue, if the lein repl (which I seldom use) is working correctly. > > A further problem (based on your github issue) may be that your > foobar.core namespace is in a file called src.clj (and you don't say what > directory that file is in). Usually, the system will expect foobar.core > namespace to be in a file called core.clj in a directory called foobar. > Yes, that's it was set up (using lein). > > > On Fri, Jan 19, 2018 at 1:55 PM, Andrew Dabrowski <unhan...@gmail.com > > wrote: > >> Maybe it isn't a cider problem, I'm having a similar issue with lein. >> Working in the project directory created by lein: >> >> $ lein repl >> nREPL server started on port 42585 on host 127.0.0.1 - nrepl:// >> 127.0.0.1:42585 >> REPL-y 0.3.7, nREPL 0.2.12 >> Clojure 1.9.0 >> OpenJDK 64-Bit Server VM 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12 >> Docs: (doc function-name-here) >> (find-doc "part-of-name-here") >> Source: (source function-name-here) >> Javadoc: (javadoc java-object-or-class-here) >> Exit: Control+D or (exit) or (quit) >> Results: Stored in vars *1, *2, *3, an exception in *e >> >> user=> (use 'foobar.core) >> nil >> user=> (math/expt 2 3) >> >> CompilerException java.lang.RuntimeException: No such namespace: math, >> compiling:(/tmp/form-init2355284152590406554.clj:1:1) >> user=> >> >> >> It seems that the lein repl also is not processing the >> >> (:require [clojure.math.numeric-tower :as math]) >> >> line in project.clj. >> >> On the other hand: >> >> user=> (require 'clojure.math.numeric-tower) >> nil >> user=> (clojure.math.numeric-tower/expt 2 3) >> 8 >> >> >> On Friday, January 19, 2018 at 12:10:59 PM UTC-5, Sean Corfield wrote: >>> >>> Can’t reproduce in Boot either. Based on that CIDER ticket, it may be >>> something specific to Andrew’s project.clj file… >>> >>> >>> >>> (! 910)-> boot -d org.clojure/math.numeric-tower repl >>> >>> Retrieving maven-metadata.xml from https://repo1.maven.org/maven2/ (1k) >>> >>> Retrieving math.numeric-tower-0.0.4.pom from >>> https://repo1.maven.org/maven2/ (1k) >>> >>> Retrieving math.numeric-tower-0.0.4.jar from >>> https://repo1.maven.org/maven2/ (5k) >>> >>> … >>> >>> boot.user=> (clojure-version) >>> >>> "1.9.0" >>> >>> boot.user=> (require '[clojure.math.numeric-tower :as math]) >>> >>> nil >>> >>> boot.user=> >>> >>> >>> >>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN >>> An Architect's View -- http://corfield.org/ >>> >>> "If you're not annoying somebody, you're not really alive." >>> -- Margaret Atwood >>> >>> >>> -- >>> *From:* clo...@googlegroups.com <clo...@googlegroups.com> on behalf of >>> Alex Miller <al...@puredanger.com> >>> *Sent:* Friday, January 19, 2018 6:04:42 AM >>> *To:* Clojure >>> *Subject:* Re: numeric-tower versus clojure 1.9 >>> >>> I can't reproduce this problem in either a lein repl or clj repl using >>> math.numeric-tower + clojure 1.9. Looking at the code, I don't see anything >>> that should be different with Clojure 1.9. >>> >>> On Friday, January 19, 2018 at 7:38:57 AM UTC-6, Bozhidar Batsov wrote: >>>> >>>> I also got a CIDER ticket about pretty much the same problem >>>> https://github.com/clojure-emacs/cider/issues/2169 >>>> >>>> I guess there's some problem with Clojure 1.9 and the tower, but I'm >>>> not sure about its exact extent. >>>> >>>> On 18 January 2018 at 02:41, Alex Miller <al...@puredanger.com> wrote: >>>> >>>>> I can't reproduce that local
Re: numeric-tower versus clojure 1.9
Maybe it isn't a cider problem, I'm having a similar issue with lein.
Working in the project directory created by lein:
$ lein repl
nREPL server started on port 42585 on host 127.0.0.1 -
nrepl://127.0.0.1:42585
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0
OpenJDK 64-Bit Server VM 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user=> (use 'foobar.core)
nil
user=> (math/expt 2 3)
CompilerException java.lang.RuntimeException: No such namespace: math,
compiling:(/tmp/form-init2355284152590406554.clj:1:1)
user=>
It seems that the lein repl also is not processing the
(:require [clojure.math.numeric-tower :as math])
line in project.clj.
On the other hand:
user=> (require 'clojure.math.numeric-tower)
nil
user=> (clojure.math.numeric-tower/expt 2 3)
8
On Friday, January 19, 2018 at 12:10:59 PM UTC-5, Sean Corfield wrote:
>
> Can’t reproduce in Boot either. Based on that CIDER ticket, it may be
> something specific to Andrew’s project.clj file…
>
>
>
> (! 910)-> boot -d org.clojure/math.numeric-tower repl
>
> Retrieving maven-metadata.xml from https://repo1.maven.org/maven2/ (1k)
>
> Retrieving math.numeric-tower-0.0.4.pom from
> https://repo1.maven.org/maven2/ (1k)
>
> Retrieving math.numeric-tower-0.0.4.jar from
> https://repo1.maven.org/maven2/ (5k)
>
> …
>
> boot.user=> (clojure-version)
>
> "1.9.0"
>
> boot.user=> (require '[clojure.math.numeric-tower :as math])
>
> nil
>
> boot.user=>
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> --
> *From:* clo...@googlegroups.com <clo...@googlegroups.com
> > on behalf of Alex Miller <al...@puredanger.com
> >
> *Sent:* Friday, January 19, 2018 6:04:42 AM
> *To:* Clojure
> *Subject:* Re: numeric-tower versus clojure 1.9
>
> I can't reproduce this problem in either a lein repl or clj repl using
> math.numeric-tower + clojure 1.9. Looking at the code, I don't see anything
> that should be different with Clojure 1.9.
>
> On Friday, January 19, 2018 at 7:38:57 AM UTC-6, Bozhidar Batsov wrote:
>>
>> I also got a CIDER ticket about pretty much the same problem
>> https://github.com/clojure-emacs/cider/issues/2169
>>
>> I guess there's some problem with Clojure 1.9 and the tower, but I'm not
>> sure about its exact extent.
>>
>> On 18 January 2018 at 02:41, Alex Miller <al...@puredanger.com
>> > wrote:
>>
>>> I can't reproduce that locally. Checking with the new clojure 1.9 clj
>>> tool:
>>>
>>> $ echo '{:deps {org.clojure/math.numeric-tower {:mvn/version "0.0.4"}}}'
>>> > deps.edn
>>> $ clj
>>> Clojure 1.9.0
>>> user=> (require '[clojure.math.numeric-tower :as n])
>>> nil
>>> user=> (dir n)
>>> MathFunctions
>>> abs
>>> ceil
>>> ...
>>>
>>>
>>> On Wednesday, January 17, 2018 at 4:26:44 PM UTC-6, Andrew Dabrowski
>>> wrote:
>>>>
>>>> Is clojure.math.numeric-tower incompatible with clojure 1.9? The
>>>> numeric tower is still at version 0.0.4, 4 years old. WHen I try to use I
>>>> get the error
>>>>
>>>> 1. Caused by java.io.FileNotFoundException
>>>>Could not locate clojure/math/numeric_tower__init.class or
>>>>clojure/math/numeric_tower.clj on classpath. Please check that
>>>>namespaces with dashes use underscores in the Clojure file name.
>>>>
>>>> In particular math.numeric-tower does not seem to obey the
>>>> dash->underscore convention, nor does the installation seem to include
>>>> init.class or .clj files.
>>>>
>>> --
>>> 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
>>
Re: numeric-tower versus clojure 1.9
Yes. On Wednesday, January 17, 2018 at 5:44:18 PM UTC-5, puzzler wrote: > > Did you put > > [org.clojure/math.numeric-tower "0.0.4"] > > in your leiningen project.clj file? > > > On Wed, Jan 17, 2018 at 2:26 PM, Andrew Dabrowski <unhan...@gmail.com > > wrote: > >> Is clojure.math.numeric-tower incompatible with clojure 1.9? The numeric >> tower is still at version 0.0.4, 4 years old. WHen I try to use I get the >> error >> >> 1. Caused by java.io.FileNotFoundException >>Could not locate clojure/math/numeric_tower__init.class or >>clojure/math/numeric_tower.clj on classpath. Please check that >>namespaces with dashes use underscores in the Clojure file name. >> >> In particular math.numeric-tower does not seem to obey the >> dash->underscore convention, nor does the installation seem to include >> init.class or .clj files. >> >> -- >> 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.
numeric-tower versus clojure 1.9
Is clojure.math.numeric-tower incompatible with clojure 1.9? The numeric tower is still at version 0.0.4, 4 years old. WHen I try to use I get the error 1. Caused by java.io.FileNotFoundException Could not locate clojure/math/numeric_tower__init.class or clojure/math/numeric_tower.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name. In particular math.numeric-tower does not seem to obey the dash->underscore convention, nor does the installation seem to include init.class or .clj files. -- 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: lein repl broken under 1.9?
You were right: it was spyscope. I forgot I had it in .lein/profiles.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: lein repl broken under 1.9?
Here's the minimal profile.clj
(defproject foobar "0.1.0-SNAPSHOT"
:description "foobar explorer"
:url ""
:license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
:dependencies [[org.clojure/clojure "1.9.0"]]
:main ^:skip-aot foobar.core
:target-path "target/%s"
:profiles {:uberjar {:aot :all}}
)
and core.clj
(ns foobar.core
(:gen-class)
)
(defn -main
"I don't do a whole lot ... yet."
[& args]
(println "Hello, World!"))
which produces
$ lein repl
Exception in thread "main" clojure.lang.ExceptionInfo: Call to
clojure.core/ns did not conform to spec:
On Saturday, January 13, 2018 at 4:14:32 PM UTC-5, Andy Fingerhut wrote:
>
> Given the warning about seesaw.util, I would guess that your project.clj
> file has seesaw as a dependency? Or maybe you have seesaw in your
> ~/.lein/profiles.clj file as a dependency?
>
> If so, either seesaw, or some other dependency being loaded, likely has an
> erroneous ns form somewhere. Perhaps where that erroneous ns form is can
> be determined from some of the error messages you have not shown. Clojure
> 1.9.0 checks the syntax of ns forms more strictly, and issues error
> messages about them, more strictly than previous versions of Clojure.
>
> Andy
>
> On Sat, Jan 13, 2018 at 1:07 PM, Andrew Dabrowski <unhan...@gmail.com
> > wrote:
>
>> I can't start a lein repl under 1.9 ( clojure 1.8 still works fine).
>>
>> $ lein repl
>> WARNING: boolean? already refers to: #'clojure.core/boolean? in
>> namespace: seesaw.util, being replaced by: #'seesaw.util/boolean?
>> Exception in thread "main" clojure.lang.ExceptionInfo: Call to
>> clojure.core/ns did not conform to spec:
>>
>> and then follows pages more error messages. Is there really a problem
>> with clojure.core/ns?
>>
>> I haven't even written any code yet, this is right after creating a new
>> project with lein.
>>
>> I'm on ubuntu 16 LTS, 64bit.
>>
>> openjdk version "1.8.0_151"
>>
>> Leiningen 2.8.1 on Java 1.8.0_151 OpenJDK 64-Bit Server VM
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: lein repl broken under 1.9?
I think that's just a warning. When I remove seesaw from the project I get pretty much the same problem. $ lein repl Exception in thread "main" clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec: On Saturday, January 13, 2018 at 4:14:32 PM UTC-5, Andy Fingerhut wrote: > > Given the warning about seesaw.util, I would guess that your project.clj > file has seesaw as a dependency? Or maybe you have seesaw in your > ~/.lein/profiles.clj file as a dependency? > > If so, either seesaw, or some other dependency being loaded, likely has an > erroneous ns form somewhere. Perhaps where that erroneous ns form is can > be determined from some of the error messages you have not shown. Clojure > 1.9.0 checks the syntax of ns forms more strictly, and issues error > messages about them, more strictly than previous versions of Clojure. > > Andy > > On Sat, Jan 13, 2018 at 1:07 PM, Andrew Dabrowski <unhan...@gmail.com > > wrote: > >> I can't start a lein repl under 1.9 ( clojure 1.8 still works fine). >> >> $ lein repl >> WARNING: boolean? already refers to: #'clojure.core/boolean? in >> namespace: seesaw.util, being replaced by: #'seesaw.util/boolean? >> Exception in thread "main" clojure.lang.ExceptionInfo: Call to >> clojure.core/ns did not conform to spec: >> >> and then follows pages more error messages. Is there really a problem >> with clojure.core/ns? >> >> I haven't even written any code yet, this is right after creating a new >> project with lein. >> >> I'm on ubuntu 16 LTS, 64bit. >> >> openjdk version "1.8.0_151" >> >> Leiningen 2.8.1 on Java 1.8.0_151 OpenJDK 64-Bit Server VM >> >> >> >> >> -- >> 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.
lein repl broken under 1.9?
I can't start a lein repl under 1.9 ( clojure 1.8 still works fine). $ lein repl WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: seesaw.util, being replaced by: #'seesaw.util/boolean? Exception in thread "main" clojure.lang.ExceptionInfo: Call to clojure.core/ns did not conform to spec: and then follows pages more error messages. Is there really a problem with clojure.core/ns? I haven't even written any code yet, this is right after creating a new project with lein. I'm on ubuntu 16 LTS, 64bit. openjdk version "1.8.0_151" Leiningen 2.8.1 on Java 1.8.0_151 OpenJDK 64-Bit Server VM -- 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 <submissionfight...@gmx.com> 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 <zsoa...@gmail.com> 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 <colin.mailingl...@gmail.com> 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 <mar...@roundingpegs.com> wrote: > >> >> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge <tbaldri...@gmail.com> >> 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: Using a function to def other functions?
I don't understand -- How am I using 'def' in a non-top-level-form? I thought I was calling 'bar', getting the result which is a function, and binding that function to a name 'foo', where the binding is 'def' at the top level. Is that not what I'm doing? I'm trying to avoid the use of unnecessary macros. Is this a situation that requires macros? Eventually this might be in ClojureScript which requires macros to be handled differently... -- 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: cautious wrapper for letfn that does macroexpansion on fnspecs first
In case anyone's curious, It was a bad idea :) It compiled and seemed to work fine until it tried to return a result and instead evaluated (result). There was a way to fix it where my letfn' macro dealt with the name and body separately. But I ended up defining functions on their own and using declare so they knew about each other instead of in a giant letfn, because - this resulted in smaller, easier to test things - and I figured calling a fn that contained a giant letfn would do all the work of defining those local fns as brand new for every call. -- 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.
cautious wrapper for letfn that does macroexpansion on fnspecs first
letfn assumes fnspecs are all already properly shaped, like: (fn-name
[args] body)
But it is possible that a macroexpansion is needed to get them in the right
shape before letfn does its work, especially if the user found all his
fnspecs were of similar shape and used a macro to eliminate boilerplate
repetition. His fnspecs would be (name-of-macro macro-args) and would
expand to (fn-name [args] body)
Original:
(defmacro letfn
"fnspec ==> (fname [params*] exprs) or (fname ([params*] exprs)+)
Takes a vector of function specs and a body, and generates a set of
bindings of functions to their names. All of the names are available
in all of the definitions of the functions, as well as the body."
{:added "1.0", :forms '[(letfn [fnspecs*] exprs*)],
:special-form true, :url nil}
[fnspecs & body]
`(letfn* ~(vec (interleave (map first fnspecs)
(map #(cons `fn %) fnspecs)))
~@body))
Macro-friendly wrapper:
(defmacro letfn'
[fnspecs & body]
`(letfn ~(vec (map macroexpand fnspecs)) ~body))
1. What do you think?
2. Is the user I mentioned above using macros wisely (use case is to
eliminate boilerplate code)?
--
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.
Automat - order of reducing functions?
How come the order of the reducing operations in the resulting diagrams below is different? Basically I want to call the first reducing operation after the first 1 and then the second operation when it accepts. This is with [org.clojars.semperos/automat "0.2.0-alpha3"] (ns p.core (:require [automat.core :as a]) (:require [automat.viz :refer (save)])) (def foo [1 (a/$ :start) (a/* 1) (a/$ :end)]) (def bar [1 (a/$ :i1)(a/* 1) (a/$ :i2) ]) (save (a/compile foo) "foo.png") (save (a/compile bar) "bar.png") -- 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 <goo...@company.romeinszoon.nl> 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 <willismich...@gmail.com> 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 <patrickgomb...@gmail.com> 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.
Re: Clojure Truck Factor
From my outside observation you would need to hit Rich Hickey, Timothy Baldridge, David Nolen, Stuart Halloway + other cognitect staff all at once. This wouldn't exactly kill clojure. But may put it into maintenance only mode for a while. On Saturday, August 8, 2015 at 4:21:40 AM UTC+12, Guilherme Avelino wrote: As part of my PhD research on code authorship, we calculated the Truck Factor (TF) of some popular GitHub repositories. As you probably know, the Truck (or Bus) Factor designates the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. In our work, we consider that a system is in trouble if more than 50% of its files become orphan (i.e., without a main author). More details on our work in this preprint: https://peerj.com/preprints/1233 We calculated the TF for *Clojure* and obtained a value of *2*. The developers responsible for this TF are: Rich Hickey - author of 58% of the files Stuart Halloway - author of 27% of the files To validate our results, we would like to ask *Clojure* developers the following three brief questions: (a) Do you agree that the listed developers are the main developers of *Clojure*? (b) Do you agree that *Clojure* will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)? (c) Does *Clojure* have some characteristics that would attenuate the loss of the listed developers (e.g., detailed documentation)? Thanks in advance for your collaboration, Guilherme Avelino PhD Student Applied Software Engineering Group (ASERG) UFMG, Brazil http://aserg.labsoft.dcc.ufmg.br/ -- 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: Durable atom
Datomic is basically what you want. when you get a db instance from the connection it is equivalent to dereffing an atom - You get an immutable reference to the data at that point in time. On Monday, August 17, 2015 at 2:59:09 AM UTC+12, Jeremy Vuillermet wrote: Hello, With the rise of Om, Reagent or re-frame for that matter, I'm using more a more the single state atom pattern in my clojurescript app. So much so that for my current application, I've been using atoms server side because my apps are split in really small app that only need to store few data - things like mini multiplayer game or polls. At the very least, it's useful while developing so I don't have to think too much about the storage layer. While looking for ways to keep my atom like interface while persisting my data, I found http://avout.io/ Distributed state for clojure which would be perfect for my use case. I also found things like https://github.com/alandipert/enduro : durable atom in clojure or https://github.com/torsten/zookeeper-atom All of them does not seem active anymore and I wonder why and what's the current status for those kind of thing. Are those solution not ready for production ? Do you eventually end up with a traditional database so nobody need that ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Durable atom
Imo datomic really is ahead of other databases. It is worth using the pro starter edition despite being closed source, one day it might become open source, who knows. On Monday, August 17, 2015 at 12:59:24 PM UTC+12, Fluid Dynamics wrote: On Sunday, August 16, 2015 at 7:27:11 PM UTC-4, Andrew Chambers wrote: Datomic is basically what you want. What if he wants open source? -- 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: Decomplecting Clojure
Hi Sebastian, Thanks for sharing! I'm enjoying read this document, and I plan to share it with a few teammates. I do have a question about one section however: Near the end, under Principles and Community you list three questions, and then state that if the answer to any of the questions is No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: Hi everybody! I've written a short post on my interpretation of Clojure. It is meant for people that are curious about the language and want to understand what the language is about. http://bensu.github.io/decomplecting_clojure/ Any feedback is welcome. Thanks to the folks at Slack that read the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 m...@41concepts.com 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 s...@corfield.org 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 ajobers...@gmail.com wrote: Mikera, I think you're addressing a different interop concern. I'm particularly interested in something like this: (- (IntStream/range 0 100) (.filter odd?) (.limit 5) (.collect Collectors/toList)) Where odd? is a normal Clojure IFn that I want to use when calling a Java API that expects something implementing a single-method-interface (Predicate in this case). Right now I need to do something like this: (defn lambda [f] (reify Predicate (test [x] (f x (- (IntStream/range 0 100) (.filter (lambda odd?)) (.limit 5) (.collect Collectors/toList)) Andrew Oberstar On Mon, Jul 27, 2015 at 8:16 PM Mikera mike.r.anderson...@gmail.com wrote: It could certainly be achieved in the Clojure compiler, by allowing (some-functional-interface .) to compile to the appropriate function call even if it doesn't implement IFn It would be quite a big change though and would probably have some limitations, e.g.: a) It probably wouldn't work with regular vars since it wouldn't be able to handle re-binding b) You would probably have to type hint the some-functional-interface object in some way so that the compiler knows to do this at compile time A less invasive option would be to just have some code to wrap functional interfaces in an appropriate IFn. Worth a JIRA ticket for consideration at least? On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote: Thanks for the reply Gary. Sounds like I'm on as good a track as I can be with current Clojure. I am curious though why you say that it is unrealistic for IFn to support arbitrary @FunctionalInterface. It certainly seems like it would require compiler changes, but I would think that either through emitting bytecode closer to Java 8 lambdas or through some form of type coercion it would possible. For example, Groovy just coerces their Closures to any Single Abstract Method type. I'm not sure how java.util.function.* as protocols would work, but still would require implementing for each SAM you come across. IFn as a protocol seems to address a different interop use case. Maybe for receiving a Java lambda you want to use as if it's a Clojure function. Most of the Java interop from Clojure is slick (sometimes more clear than in Java itself), it would be unfortunate to leave functions as second-class citizens for interop. Granted, there may be a simplicity argument against this (maybe that's why Java varargs require an explicit array?). Andrew Oberstar On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com wrote: On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com wrote: Hi, I'm wondering if anyone has a good approach for making calls from Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. Ideally, IFn would transparently work, but I'm guessing that requires some compiler changes. Right now, the best I can think of is a function
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 gary.verhae...@gmail.com wrote: On Sunday, 26 July 2015, Andrew Oberstar ajobers...@gmail.com wrote: Hi, I'm wondering if anyone has a good approach for making calls from Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. Ideally, IFn would transparently work, but I'm guessing that requires some compiler changes. Right now, the best I can think of is a function or macro to reify a wrapper around a Clojure function to implement all of the usual interfaces from java.util.function. Anyone have any better ideas? Andrew Oberstar You're probably aware of this, but @FunctionalInterface is not a type, it's an annotation. All it does is ensure, at compile time, that the annotated element is an interface with a single non-default and non-static method. At the type-system level, it's just an interface like any other, and the lambda syntax is just a shorthand for an anonymous instance of a well-defined type. Since the lambda syntax is java-compiler magic, you can't access it from Clojure, and the most straightforward option right now is to actually know which type is expected, e.g.: user= (- (doto (java.util.ArrayList.) (.add 1) (.add 2)) (.stream) (.map (reify java.util.function.Function (apply [_ arg] (inc arg (.collect (java.util.stream.Collectors/toList))) [2 3] user= As neither IFn nor Function are Clojure protocols, I do indeed think you're best bet is a macro to essentially generate the above reify. You can of course do a single macro that reifies to all of the protocols that you need. I don't think it's realistic to hope that IFn will cover any arbitrary @FunctionalInterface, as that is Java compiler magic. It may, in the future, be extended to cover 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.
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 mike.r.anderson...@gmail.com wrote: It could certainly be achieved in the Clojure compiler, by allowing (some-functional-interface .) to compile to the appropriate function call even if it doesn't implement IFn It would be quite a big change though and would probably have some limitations, e.g.: a) It probably wouldn't work with regular vars since it wouldn't be able to handle re-binding b) You would probably have to type hint the some-functional-interface object in some way so that the compiler knows to do this at compile time A less invasive option would be to just have some code to wrap functional interfaces in an appropriate IFn. Worth a JIRA ticket for consideration at least? On Tuesday, 28 July 2015 08:52:47 UTC+8, Andrew Oberstar wrote: Thanks for the reply Gary. Sounds like I'm on as good a track as I can be with current Clojure. I am curious though why you say that it is unrealistic for IFn to support arbitrary @FunctionalInterface. It certainly seems like it would require compiler changes, but I would think that either through emitting bytecode closer to Java 8 lambdas or through some form of type coercion it would possible. For example, Groovy just coerces their Closures to any Single Abstract Method type. I'm not sure how java.util.function.* as protocols would work, but still would require implementing for each SAM you come across. IFn as a protocol seems to address a different interop use case. Maybe for receiving a Java lambda you want to use as if it's a Clojure function. Most of the Java interop from Clojure is slick (sometimes more clear than in Java itself), it would be unfortunate to leave functions as second-class citizens for interop. Granted, there may be a simplicity argument against this (maybe that's why Java varargs require an explicit array?). Andrew Oberstar On Mon, Jul 27, 2015 at 4:16 AM Gary Verhaegen gary.ve...@gmail.com wrote: On Sunday, 26 July 2015, Andrew Oberstar ajobe...@gmail.com wrote: Hi, I'm wondering if anyone has a good approach for making calls from Clojure to Java APIs (e.g. Stream API) that expect a @FunctionalInterface type. Ideally, IFn would transparently work, but I'm guessing that requires some compiler changes. Right now, the best I can think of is a function or macro to reify a wrapper around a Clojure function to implement all of the usual interfaces from java.util.function. Anyone have any better ideas? Andrew Oberstar You're probably aware of this, but @FunctionalInterface is not a type, it's an annotation. All it does is ensure, at compile time, that the annotated element is an interface with a single non-default and non-static method. At the type-system level, it's just an interface like any other, and the lambda syntax is just a shorthand for an anonymous instance of a well-defined type. Since the lambda syntax is java-compiler magic, you can't access it from Clojure, and the most straightforward option right now is to actually know which type is expected, e.g.: user= (- (doto (java.util.ArrayList.) (.add 1) (.add 2)) (.stream) (.map (reify java.util.function.Function (apply [_ arg] (inc arg (.collect (java.util.stream.Collectors/toList))) [2 3] user= As neither IFn nor Function are Clojure protocols, I do indeed think you're best bet is a macro to essentially generate the above reify. You can of course do a single macro that reifies to all of the protocols that you need. I don't think it's realistic to hope that IFn will cover any arbitrary @FunctionalInterface, as that is Java compiler magic. It may, in the future, be extended to cover all of the standard ones in java.util.function, or even all the ones in the standard library, but it's not going to happen until Java 7 support is dropped. I guess the best you could hope for in the short term would be to have IFn changed to a protocol. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com 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
Re: [ANN] Replete ClojureScript REPL iOS app available
Brilliant Mike. Well done with this. Very impressive. On Monday, 20 July 2015 21:28:51 UTC, Mike Fikes wrote: Replete 1.0 is now in the App Store http://blog.fikesfarm.com/posts/2015-07-20-ios-clojurescript-repl-available-in-app-store.html -- 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 s.ma...@gmail.com 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
Silly me, my computer was muted... I'll watch it again. On Sat, May 23, 2015 at 8:27 AM Andrew Oberstar ajobers...@gmail.com 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 s.ma...@gmail.com 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] Clojure 1.7.0-beta3
Looks good for current project. Project compiles and runs with clojure 1.7.0-beta3, clojurescript 0.0-3269, figwheel 0.3.1 + core.async core.match + om + ... Figwheel repl still works from within Cursive. Thanks, Andrew -- 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 needs a web framework with more momentum
Extending a little more on Herwig's previous idea, a good Clojure framework could be a collection of schemas, protocols and interfaces. A ring for the whole stack. Creating our stack will be a matter of composing our web pipeline with our desired libraries. Even templates could become unnecessary, despite being very helpful to lower the entry point for new developers. IMHO *that* is the power of data driven architectures that we like to sell, isn't? []'s Andrew On Sunday, May 3, 2015 at 11:51:36 AM UTC-3, Plinio Balduino wrote: Mr Herwig That said: I'd love to see a set of well-maintained, well-documented project templates to emerge from a common brand, for the benefit of beginners and 10h website creators. THIS is exactly what I was discussing right now with a friend. I think you nailed it. On Sun, May 3, 2015 at 11:47 AM, Herwig Hochleitner hhochl...@gmail.com javascript: wrote: 2015-05-03 16:27 GMT+02:00 Fluid Dynamics a209...@trbvm.com javascript:: So, basically, Clojure *is* the framework? :) Exactly! As is any language that you choose to work in. That means that buying into at least one framework is nessecary to get started with programming anyway. With clojure, the predominant attitude seems to be: If I can buy into one framework, that gives me a skinnable, turing-complete language and focuses on composition, why should I buy into further frameworks, that can only distance me from my peers that use something else? That said: I'd love to see a set of well-maintained, well-documented project templates to emerge from a common brand, for the benefit of beginners and 10h website creators. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: test.check :autotest ?
Hey boz, You probably found your post, but just in case someone lands here from a search there are a few options, but take a look at lein-autotest https://github.com/dakrone/lein-autotest Here's the stackoverflow page, which might have more (or better) answers too http://stackoverflow.com/questions/8406984/what-autotest-tools-exist-for-clojure On Monday, 5 May 2014 11:34:48 UTC-4, boz wrote: Is there an :autotest for test.check with Leiningen? Something like midje, where you can do: lein midje :autotest Many thanks, boz -- 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 james.la...@gmail.com 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.
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: 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 ajobers...@gmail.com
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 colin.ya...@gmail.com 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 ajobers...@gmail.com 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 colin.ya...@gmail.com
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 ajobers...@gmail.com
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
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 colin.ya...@gmail.com 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 ajobers...@gmail.com 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 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
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 colin.ya...@gmail.com 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 ajobers...@gmail.com 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 colin.ya...@gmail.com
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 ajobers...@gmail.com
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
Re: Browserless ClojureScript
Never looked at Node before. I've followed the instructions, but I get this
error when running: node run.js
(I'm using nixos with node v0.11.13. Anyone got any clues?)
[keeds@pixie:~/workspace/hello-world]$ node run.js
/home/keeds/workspace/hello-world/out/goog/bootstrap/nodejs.js:69
process.binding('evals').NodeScript.runInThisContext.call(
^
Error: No such module
at Error (native)
at nodeGlobalRequire
(/home/keeds/workspace/hello-world/out/goog/bootstrap/nodejs.js:69:11)
at Object.anonymous
(/home/keeds/workspace/hello-world/out/goog/bootstrap/nodejs.js:77:1)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:349:32)
at Function.Module._load (module.js:305:12)
at Module.require (module.js:357:17)
at require (module.js:373:17)
at Object.anonymous (/home/keeds/workspace/hello-world/run.js:5:1)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Aaron, Still need to study the more detailed docs, but from what I read from UI-SPEC the only thing I get confused about was the event/lifecycle. Just a suggestion about the name, if there is time for that: despite of the chosen one, IMO will be a good thing unify all (potential) libraries under single name. So you'll end up with lib.core, lib.dom, lib.fx, lib.wpf. This way will be much more easy to follow the related libraries - after all, even with diferencies they will be tied by major common idioms. Just my 2c -- 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 henrik.lund...@gmail.com 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 gary.verhae...@gmail.com 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.
Re: On Testing
+1 to something like humane-test-output being part of core library. There is value for the community to have some foundation library share across our test frameworks? Something like `test.runners`, to encapsulate error reporting and organization? Bit crazy, I know, but the idea come after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do Haskell, but I kind of like the way of composing a single integrated suite of different flavors of test. Andrew On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote: Would be great if humane-test-output was part of clojure.test. Would make it easier for beginners to find it. On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote: On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling ashtonk...@gmail.com wrote: It's my opinion that these two libraries are largely complete aside from some human interface improvements (quality of output for example), but clearly not everyone agrees with me. Hi Ashton, Check out https://github.com/pjstadig/humane-test-output if you haven't already seen it, it's a nice improvement over the default output--in particular seeing the specific diffs between expected and actual values is really useful when you are dealing with collections. -Eli -- 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] fast-zip 0.5.0 now with ClojureScript support
I think this will be awesome. If the data structures made a no-op, at least the testing code should help. Nice work Alexander! On Thursday, October 23, 2014 10:50:51 PM UTC-2, Alexander Hudek wrote: The implementation is API compatible but not compatible in terms of data structures. I suppose it could still be integrated on a major version change. In any case, I'm happy to donate the code if the core group wants. Would have to get sign off from the other authors too. On Tuesday, October 21, 2014 5:59:20 PM UTC-4, Robin Heggelund Hansen wrote: Any reason this isn't a patch to clojure proper? kl. 05:09:04 UTC+2 lørdag 4. oktober 2014 skrev Alexander Hudek følgende: Thanks to the wonderful work of Joel Holdbrooks, fast-zip now has ClojureScript support. See the benchmarks below. The ClojureScript benchmark only uses simple compiler optimizations. Git: https://github.com/akhudek/fast-zip Clojars: [fast-zip 0.5.0] CLJS has ~ 1.7x speedup: :clojure.zip x 116 ops/sec ±0.65% (83 runs sampled) :fast-zip x 194 ops/sec ±0.85% (92 runs sampled) Fastest is :fast-zip CLJ has ~ 5.2x speedup. == WARNING: Final GC required 1.467359386689346 % of runtime Goal: Benchmark vector zip. - Case: :clojure.zip Evaluation count : 60480 in 60 samples of 1008 calls. Execution time mean : 1.002237 ms Execution time std-deviation : 7.317531 µs Execution time lower quantile : 990.607677 µs ( 2.5%) Execution time upper quantile : 1.015757 ms (97.5%) Overhead used : 2.442790 ns Case: :fast-zip Evaluation count : 316140 in 60 samples of 5269 calls. Execution time mean : 191.258856 µs Execution time std-deviation : 2.819942 µs Execution time lower quantile : 188.802833 µs ( 2.5%) Execution time upper quantile : 198.838310 µs (97.5%) Overhead used : 2.442790 ns Found 8 outliers in 60 samples (13. %) low-severe 4 (6.6667 %) low-mild 4 (6.6667 %) Variance from outliers : 1.6389 % Variance is slightly inflated by outliers -- 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.
Re: com.stuartsierra/component ring/compojure example
This is not a full example, but I ran into the same issue when building an app for the Clojure Cup not too long ago. The general approach I used is this: - create the Compojure routes in a function with the components I need as parameters - declare the web server itself (I used httpkit) as a component with the dependencies needed for the routes - build a handler from the routes within the web server component's start function, passing the dependencies into the route-generating function I'm no Clojure expert, and this was my first project using Stuart Sierra's Component library, so I would be interested to hear some feedback from the more seasoned Clojure folks here. Here is the relevant file from my project if you are interested: https://github.com/kendru/tourbillon/blob/master/src/tourbillon/www/core.clj#L67 On Tuesday, October 7, 2014 11:33:33 AM UTC, JPatrick Davenport wrote: Hello, I'm trying to create a web app. I'm having the damnest time trying to figure out how to layer my application. I want to pass protocol implementations to the routes. The protocols define interacting with various data sources that I need down the way. I saw Stuart Sierra's talk about Component. It looks to satisfy my needs. What I can't find is an example project for component and compojure. Unfortunately the project com.stuartsierra/component is poorly named. Googling for component + compojure brings back mostly false positives. Does anyone have a gist or blog post about how to do this? Thanks, JPD -- 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: twitter-api and streaming calls
I had someone email me today asking for a code snippet of using the java twitter api, so I'll repost it here. I'm fairly new to clojure so forgive me for the ugliness/lack of idiomatic code. It's a port of the java example code at https://github.com/twitter/hbc/blob/master/hbc-example/src/main/java/com/twitter/hbc/example/FilterStreamExample.java with some additional logic to dump messages onto rabbitmq. Clojure code here https://www.refheap.com/85199 Cheers, Andrew Fitzgerald On Friday, May 2, 2014 3:40:06 AM UTC-4, Simon Katz wrote: Thanks Andrew and Gary. You've saved me a lot of time! On Friday, 2 May 2014 02:43:51 UTC+1, Gary Trakhman wrote: Oh, nice, I was concerned about reconnections and backfill issues, if I have to change anything substantial again I'll reimplement on top of the java api that provides this out of the box. On Thu, May 1, 2014 at 9:13 PM, Andrew Fitzgerald andrewcf...@gmail.comwrote: I had the same (very frustrating issue) recently. I ended up just using the official twitter API which is written in Java https://github.com/twitter/hbc On Thursday, May 1, 2014 6:59:04 PM UTC-4, Simon Katz wrote: Hi, I'm playing with twitter-api (https://github.com/adamwynne/twitter-api) and streaming calls. I've also tried twitter-streaming-client ( https://github.com/mccraigmccraig/twitter-streaming-client). With the examples each of those provide, I'm getting *EOFException: JSON error (end-of-file)* errors. I can of course post more details, but I'm hoping someone else might have come across this and be able to give me a pointer as to what's happening. I wonder if perhaps something's changed in the Twitter API recently to break things. __ Simon -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Functional programming and security
I would say the transaction model of datomic would have saved Mt Gox from its problems dealing with atomic transactions, however that's more due to datomic's design and poor design of the Mt Gox system than a clojure specific thing. On Monday, May 5, 2014 6:21:47 PM UTC+12, Magnus Therning wrote: On Mon, May 5, 2014 at 12:13 AM, Evan Rowley rowle...@gmail.comjavascript: wrote: The question we have to ask is: Would use of a (specific?) functional language prevented these? My opinion: Probably not in the case of Mt. Gox because their problems had more to do with their application design. There is no language that will prevent logical errors, that is true. There's that old saying that a good programmer can write Fortran in any language ;) However, choosing language wisely will allow you to concentrate on solving the 'real' problem at hand, and relieve you from solving unrelated problems (memory management, dealing with pointers, etc). It will also simplify reasoning about your code. I haven't found enough information about the Mt Gox bug to judge whether their demise could have been avoided using a better language. It sure sounds like they were doomed no matter what. As for Apple, I think the 'goto' feature is missing from at least Clojure. Both Haskell and Erlang have 'goto', but it's use isn't encouraged. I'm thinking that because these languages are functional, the goto feature works in a safer manner that wouldn't have allowed Apple's code to work with the failed certificate check. But that's just a guess. I'm pretty sure there is no 'goto' in Haskell, it's not a keyword in the language. There are ways of using continuations to implement goto in monadic code, but I'm pretty sure that would be possible in Scheme/Clojure too then. 'Goto' isn't a keyword in Erlang either! For OpenSSL's Heartbleed, I'm going to say that this wouldn't have been prevented even with functional programming. The problem lies in the design of the heartbeat code. One thing I do have to wonder about is whether or not this heartbeat code would have been designed differently if it were done in a functional programming language. It's worth keeping in mind that the higher level of abstraction most functional programming languages have would have contributed to a different design. I think the base cause of OpenSSL Heartbleed is the presence of pointers in the language used. In fact, I am convinced that if the developer community would move en masse to language that don't have pointers we'd see a huge fall in reported security vulnerabilities. FreeBSD's TCP bug *might* have been prevented if the functional programming language's runtime did effective memory management. I'm going to assume that everyone here agrees that functional programming languages have well-designed memory management. Hear, hear! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org javascript: jabber: mag...@therning.orgjavascript: twitter: magthe http://therning.org/magnus -- 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.
Clojure compiled without Eval
I'm wondering if there is a way to generate Clojure executables/jars without the embedded Clojure compiler/interpreter. In older lisps there is usually the option to generate an executable with unused bits of the language expunged for performance reasons. Clojurescript already sort of works this way so I can't think why this would be impossible with Clojure specifically. -- 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.
Idiomatic tokenizing and performance
I've been trying to make a tokenizer/lexer for a project of mine and came up with the following code, I've modelled the stream of characters as seq/lazy of chars which is then converted to a lazy-seq of token objects. I'm relatively happy with how idiomatic and functional the code seems, however when benchmarked, the code takes about 30 seconds on clojure (after i increase the heap to 1 gig) to process a 30 meg file, and over 1 minute 30 seconds with clojurescript. This is in contrast to about of 0.1 to 0.5 seconds or less in C. Is there any idiomatic way to process the file without being a factor of 100 times slower than C? Also, is there a tool for clojure similar to gprof for C? Each function takes in a char seq and returns both a token and the seq after its been advanced. (defn match-ident [cs] (let [start (first cs)] (if (ident-first-char? start) (let [ identseq (cons start (take-while ident-tail-char? (rest cs))) ^String ident (apply str identseq)] [(drop (.length ident) cs) [:ident ident]] (defn match-num [cs] (if (digit? (first cs)) (let [ numseq (take-while digit? cs) ^String numstr (apply str numseq) retseq (drop (.length numstr) cs)] (if (= (first retseq) \.) nil [retseq [:number numstr]] (defn match-ws [cs] (if (whitespace-char? (first cs)) (let [ wsseq (take-while whitespace-char? cs) ^String wsstr (apply str wsseq) retseq (drop (.length wsstr) cs)] [retseq [:ws wsstr]]))) ... (defn next-token [cs] (or (match-ident cs) (match-ws cs) (match-punct cs) (match-num cs) (match-eof cs) (match-unknown cs))) ;; Here I build the lazy seq of tokens. (defn token-seq [cs] (let [[newcs tok] (next-token cs)] (lazy-seq (cons tok (token-seq newcs) Cheers, Andrew Chambers -- 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: Idiomatic tokenizing and performance
Thanks, I should have done that tbh. my code is on github https://github.com/andrewchambers/ccc/blob/master/src/ccc/lex.clj . Don't think it compiles or runs on master currently though. If anyone is interested im trying to test the feasibility/size/maintainability of a clojure (or clojurescript) version of this guys tiny C compiler https://github.com/rui314/8cc. Basically to compare functional programming with what i consider excellent C code. Cheers, On Monday, May 5, 2014 4:43:27 PM UTC+12, Atamert Ölçgen wrote: I created a gist of your code for better readability, I hope you don't mind. https://gist.github.com/muhuk/7c4a2b8db63886e2a9cd On Mon, May 5, 2014 at 12:36 PM, Andrew Chambers andrewc...@gmail.comjavascript: wrote: I've been trying to make a tokenizer/lexer for a project of mine and came up with the following code, I've modelled the stream of characters as seq/lazy of chars which is then converted to a lazy-seq of token objects. I'm relatively happy with how idiomatic and functional the code seems, however when benchmarked, the code takes about 30 seconds on clojure (after i increase the heap to 1 gig) to process a 30 meg file, and over 1 minute 30 seconds with clojurescript. This is in contrast to about of 0.1 to 0.5 seconds or less in C. Is there any idiomatic way to process the file without being a factor of 100 times slower than C? Also, is there a tool for clojure similar to gprof for C? Each function takes in a char seq and returns both a token and the seq after its been advanced. (defn match-ident [cs] (let [start (first cs)] (if (ident-first-char? start) (let [ identseq (cons start (take-while ident-tail-char? (rest cs))) ^String ident (apply str identseq)] [(drop (.length ident) cs) [:ident ident]] (defn match-num [cs] (if (digit? (first cs)) (let [ numseq (take-while digit? cs) ^String numstr (apply str numseq) retseq (drop (.length numstr) cs)] (if (= (first retseq) \.) nil [retseq [:number numstr]] (defn match-ws [cs] (if (whitespace-char? (first cs)) (let [ wsseq (take-while whitespace-char? cs) ^String wsstr (apply str wsseq) retseq (drop (.length wsstr) cs)] [retseq [:ws wsstr]]))) ... (defn next-token [cs] (or (match-ident cs) (match-ws cs) (match-punct cs) (match-num cs) (match-eof cs) (match-unknown cs))) ;; Here I build the lazy seq of tokens. (defn token-seq [cs] (let [[newcs tok] (next-token cs)] (lazy-seq (cons tok (token-seq newcs) Cheers, Andrew Chambers -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: twitter-api and streaming calls
I had the same (very frustrating issue) recently. I ended up just using the official twitter API which is written in Java https://github.com/twitter/hbc On Thursday, May 1, 2014 6:59:04 PM UTC-4, Simon Katz wrote: Hi, I'm playing with twitter-api (https://github.com/adamwynne/twitter-api) and streaming calls. I've also tried twitter-streaming-client ( https://github.com/mccraigmccraig/twitter-streaming-client). With the examples each of those provide, I'm getting *EOFException: JSON error (end-of-file)* errors. I can of course post more details, but I'm hoping someone else might have come across this and be able to give me a pointer as to what's happening. I wonder if perhaps something's changed in the Twitter API recently to break things. __ Simon -- 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: testing clojure.core/group-by with clojure.test.check
One approach you can use is write the generators in such a way that they generate the final answer group-by should return, then you write code which does the inverse to group by and then you check the group by answer is equal to the originally generated solution. On Wednesday, April 30, 2014 11:38:19 PM UTC+12, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. 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: Update
Well, why write it in primitives when there is a perfectly good compiler from java to primitives? I dont quite understand why you think there would be benefit from manually writing everything with java bytecode. The JVM works with classes, thats how its designed, Clojure itself is just a java library. On Tuesday, April 29, 2014 8:25:01 PM UTC+12, Divyansh Prakash wrote: Why are Clojure features defined in terms of Java classes, instead of as bytecode primitives? For eg: Cons is a class containing two objects: first and rest. Is this only to achieve Java interoperability, or is there more to it? -- 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: Update
For the llvm based approach you can look at vmkit. On Wednesday, April 30, 2014 3:39:21 AM UTC+12, Divyansh Prakash wrote: Check out my previous reply. The parrot vm provides gc and everything, But still the author defines lambda primitives in c, and then builds over it. -- 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: cursive plugin question
To do this i created a new run configuration with and in the run config dialog set it to local clojure repl, then you need to go to preferences and create keybindings for send current form to repl (I just used shift + enter). Then it should work no problem. On Tuesday, April 29, 2014 11:04:24 PM UTC+12, Roelof Wobben wrote: Hello, I installed intelij with the cursive plugin. Now I wonder if this can be done in some way. Suppose I have a file with 3 functions. Can I send one to REPL so I can test if it works as I expected. Roelof -- 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: Which linux distro has intelij ?
Don't install intellij from and package manager (it will probably be out of date/not there), just install java then download it from the intellij/cursive website. Its self updating anyway and should work on any distro and on windows that way. On Wednesday, April 23, 2014 5:11:54 AM UTC+12, Roelof Wobben wrote: Hello, Does anyone know a Linux distro which I can use to learn clojure and which has inteljij aviable. I really like to test the cursive plugin Roelof -- 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.
ring streaming efficiency
When you set the body of a ring response to a java input stream and return it, is this still a thread per stream? or does it use some sort of java event loop for efficiency? I'm worried that a traffic download/upload server in ring wouldn't handle many concurrent large file uploads and downloads as efficiently as something like google go or nodejs would. I would like to use ring because I want Datomic to manage the access permissions. -- 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: Which linux distro has intelij ?
Just for reference, i use xubuntu (with the apt-get java jdk) and windows with cursive no problem. I love cursive compared to other clojure dev tools I've tried. On Wednesday, April 23, 2014 11:37:12 AM UTC+12, Andrew Chambers wrote: Don't install intellij from and package manager (it will probably be out of date/not there), just install java then download it from the intellij/cursive website. Its self updating anyway and should work on any distro and on windows that way. On Wednesday, April 23, 2014 5:11:54 AM UTC+12, Roelof Wobben wrote: Hello, Does anyone know a Linux distro which I can use to learn clojure and which has inteljij aviable. I really like to test the cursive plugin Roelof -- 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 streaming efficiency
I need access control for the static files. The alternative is signed s3 urls which expire. Uploads still require streaming through ring however as i cant generate signed upload urls with the parameters that I need. On Wednesday, April 23, 2014 3:27:09 PM UTC+12, James Reeves wrote: Java input streams are blocking, rather than asynchronous, so yes it would use a thread per stream. In theory an asynchronous solution would be more efficient, and there are adapters, like http-kit, that support this optimisation. However, in practice, Java can handle many threads in a single process, so it's unlikely you'll run into difficulties until you have to support 1000s of concurrent downloads. It's often a good idea to avoid premature optimisations, particularly if you lack concrete benchmarks. It also depends a lot on how you're generating the downloads. If you're generating the files dynamically, you may find that your bottleneck is CPU-bound, rather than I/O-bound; in which case, there would be little benefit to going async. If you're just serving static files, then it might be useful hosting your files on a service like S3, and redirecting your users instead. - James On 23 April 2014 04:03, Andrew Chambers andrewc...@gmail.comjavascript: wrote: When you set the body of a ring response to a java input stream and return it, is this still a thread per stream? or does it use some sort of java event loop for efficiency? I'm worried that a traffic download/upload server in ring wouldn't handle many concurrent large file uploads and downloads as efficiently as something like google go or nodejs would. I would like to use ring because I want Datomic to manage the access permissions. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure compiletime vs runtime
Why are the toplevel forms which arent macros executed at compile time? For example Lua can be compiled to bytecode without executing its top level calls. On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts lprefonta...@softaddicts.cawrote: Ahem :) a) The fn x does not exist in the universe until you call foo, hence you cannot expect the compiler to known anything about it if it's not called before making any reference to x. b) If you refer to x at the top level (the universe above :) before defining it, obviously it does not exist. You might use (declare x) before referring to it. This allows you to define it later at your convenience. c) In general, you should avoid using def/defn within a function. Macros may do that but this is a different story. d) Yes code at the top level is executed, how can you expect the REPL to work interactively if forms are not evaluated first ? A defn expands to a function call, a special form in fact but it still behaves like a function. Any function call at top level will get executed after being compiled to byte code. Now about the compilation step... Traditionally, most Lisps allow you to refer to stuff in interpreted mode not defined yet hoping that it will get defined by the time you run the code that refers to these undefined things. It can even be something transient on the stack... oups... You can still compile in other Lisps but this is a special case where you have to make sure that stuff is defined in some way. You need to add directives to tell the compiler that this stuff will exist later and that it can safely refer to it. On the JVM, some underlying byte code has to be generated for any forms typed in the REPL at the top level any reference has to be defined before hand. There's no other way to generate byte code... there cannot be black holes waiting to get filled later. Hence the compilation phase and the restriction that stuff you refer to are to be defined either directly or using declare. Hope it explains the compromise. Luc P. Is there an explanation of how clojure deals with scoping and its static checking. It seems to be a hybrid of a static language and a dynamic language when it comes to compilation. I'll elaborate. The following code wont compile: (defn x [] nil) (defn y[]) ((x)) however this code will compile: (defn foo[] (defn x[] nil)) (defn y[]) ((x)) but calling y before foo fails with a runtime exception. Also, the following code: (println hello) (defn -main [args] (println world)) prints hello at compile time and also hello world at runtime. My conclusions from this is that the static symbol checker is actually fairly stupid and is just there to provide some simple sanity, and that all toplevel code in a namespace is executed at compile time AND at runtime. Is this correct? -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VUWTAwOEHS0/unsubscribe. To unsubscribe from this group and all its topics, 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
Re: Clojure compiletime vs runtime
I only noticed it because I was trying to write a macro which expands to multiple def calls. This requires the def's to be inside a do block, which made me question a whole lot about how the AOT compiler works. On Tue, Apr 15, 2014 at 11:05 PM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: You need to distinguish between compiled and aot compiled to byte code. As far as I know, all forms are compiled before they are executed. So, if you type: (+ 1 1) it is first compiled to bytecode, and then run. It's not executed at compile time at all; rather when it is evaluated, it is compiled and then run. If you aot compile, then you are do the same thing, but dump the bytecode to file. So, you still evaluate the entire top level. So, when you say compile, I presume you you mean aot compiled. Macros have to be run, so the question is should they be expanded but not evaluated? And what about macros with side-effects? And if top level forms are NOT evaluated when loaded what would this do: (ns user) (def x 1) (load user_y) === in user_y.clj (def y 1) Now the AOT would only load the first file in the namespace because (load user_y) would not be evaluated. Why are you worried about this? Most of the time compilation in Clojure is an implementation detail, as it is in python. It just happens when it needs to, and away you go. Phil Andrew Chambers andrewchambe...@gmail.com writes: Why are the toplevel forms which arent macros executed at compile time? For example Lua can be compiled to bytecode without executing its top level calls. On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts lprefonta...@softaddicts.cawrote: Ahem :) a) The fn x does not exist in the universe until you call foo, hence you cannot expect the compiler to known anything about it if it's not called before making any reference to x. b) If you refer to x at the top level (the universe above :) before defining it, obviously it does not exist. You might use (declare x) before referring to it. This allows you to define it later at your convenience. c) In general, you should avoid using def/defn within a function. Macros may do that but this is a different story. d) Yes code at the top level is executed, how can you expect the REPL to work interactively if forms are not evaluated first ? A defn expands to a function call, a special form in fact but it still behaves like a function. Any function call at top level will get executed after being compiled to byte code. Now about the compilation step... Traditionally, most Lisps allow you to refer to stuff in interpreted mode not defined yet hoping that it will get defined by the time you run the code that refers to these undefined things. It can even be something transient on the stack... oups... You can still compile in other Lisps but this is a special case where you have to make sure that stuff is defined in some way. You need to add directives to tell the compiler that this stuff will exist later and that it can safely refer to it. On the JVM, some underlying byte code has to be generated for any forms typed in the REPL at the top level any reference has to be defined before hand. There's no other way to generate byte code... there cannot be black holes waiting to get filled later. Hence the compilation phase and the restriction that stuff you refer to are to be defined either directly or using declare. Hope it explains the compromise. Luc P. Is there an explanation of how clojure deals with scoping and its static checking. It seems to be a hybrid of a static language and a dynamic language when it comes to compilation. I'll elaborate. The following code wont compile: (defn x [] nil) (defn y[]) ((x)) however this code will compile: (defn foo[] (defn x[] nil)) (defn y[]) ((x)) but calling y before foo fails with a runtime exception. Also, the following code: (println hello) (defn -main [args] (println world)) prints hello at compile time and also hello world at runtime. My conclusions from this is that the static symbol checker is actually fairly stupid and is just there to provide some simple sanity, and that all toplevel code in a namespace is executed at compile time AND at runtime. Is this correct? -- 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
Re: [ANN] Gorilla REPL 0.2.0 - all new extensible renderer
This is awesome (reminds me of ipython notebooks). I hope to use this to custom render some data structures internal to my compiler project. I'll have to read up on how to render directed graphs. On Thursday, March 20, 2014 9:22:57 AM UTC+13, Jony Hudson wrote: Hi all, I'm happy to announce a new release of Gorilla REPL. The number one comment I got from people on the original release was that it looked good, but they'd like to see it extended to some library or other. Jeff Rose hit the nail on the head with: Being able to render values of different types is important, and I think it deserves a lot of attention in both the design and documentation. So with that in mind, on to the changes: - All new renderer. This is the main change. The new renderer is simple and predictable, _very_ flexible, supports first-class pluggable custom rendering, and really respects the structure of Clojure values. In particular it renders aggregates of values as you might hope, so you can draw lists of tables, tables of plots, associatives of tables of tables of plots etc. I've made a couple of videos walking through its features, and how easy it is to extend. I'm really pleased with how it's come out :-) https://vimeo.com/89529751 https://vimeo.com/89532785 As per the request, there's also documentation on it. Enough to choke a horse! http://gorilla-repl.org/renderer.html - You can open multiple tabs on the same REPL. This works really nicely - they each get they own session, but share the REPL. - Runs a real nREPL server now, so should work together with things like vim-fireplace that make their own connection to the REPL server. (I haven't tested this though!) - As you might have guessed from the above, there's now a website. http://gorilla-repl.org - Numerous small bug-fixes and feature requests. There are some minor breaking changes, hence the version bump: - Old worksheets will need to be re-run to regenerate their output. - Code that dabbled with the internals of gorilla-plot might need to be adjusted. It's on clojars now, with coordinates [gorilla-repl 0.2.0] . The new renderer lays the foundation for adding rendering for other libraries. I'd love to see support for core.matrix and Incanter, so I think this will be the immediate focus of development. If you maintain a library and would like to see it supported, then please do get in touch. As always, all comments and criticism gratefully received. [Proof-reading this email, I realise I sound rather pleased with myself. My apologies for that, but in truth I think I _am_ rather pleased with how this version has came together!] Yours, Jony -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: true lightweight threads on clojurescript?
You need to write either an interpreter of some sort of bytecode in javascript/clojurescript and and have the interpreter implement the threading, or use a webworker for each process then something like core.async for sending ui events to the main browser loop. Clojurescript doesnt attempt to emulate full threads. On Wednesday, April 9, 2014 8:51:57 AM UTC+12, t x wrote: Hi, * I am aware of core.async. However, I don't like the fact that (go ... ) is a macro, thus forcing the ! and ! to appear in the body, and I can't do nested things like: (defn foo [chan] (let [x (! chan)] ... )) (go ... (foo ... )) * For the following, I only need it to work in ClojureScript. I don't need it to work in Clojure. Furthermore, we can assume browser = latest Firefox, or browser = latest Chrome. Now, my question: is there a library which provides true lightweight Clojurescript threads? 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] Gorilla REPL 0.2.0 - all new extensible renderer
Is there a way to rerun the whole notebook top to bottom with a hotkey? On Wed, Apr 16, 2014 at 3:59 PM, SteveSuehs skelter@gmail.com wrote: I'm running Leiningen 2.1.2 on Java 1.7.0_45 Java HotSpot(TM) 64-Bit Server VM Upgrading now...version 2.3.4 Removed tools.nrepl from project.clj $ lein gorilla Gorilla-REPL. Started nREPL server on port 50235 Running at http://localhost:8990/worksheet.html . Ctrl+C to exit. Looking good! On Tuesday, April 15, 2014 10:03:33 AM UTC-5, Jony Hudson wrote: Thanks for the kind words chaps - glad you like it! @Steve Are you sure your Leiningen is up to date? I've only seen this problem when accidentally trying to run Gorilla with Lein 1.7 (as Debian seems to have that version as its default install). @Andrew Probably not what you're looking for, but there should be a renderer for Loom graphs soon, which shells out to GraphViz to do the heavy lifting. Take a look at this PR: https://github.com/aysylu/loom/pull/20. Even if your data doesn't fit with loom then it might be useful for an idea. -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/a1FsteQXhrQ/unsubscribe. To unsubscribe from this group and all its topics, 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.
Extending a data model
Hi everyone,
I'm new to clojure and in order to learn I'm working on making some
compiler tools which converts a lightweight IR code into assembly.
My data model for an IR function is along the lines of
(def code
{
:entry
[[:loadaddr :x global_label]
[:loadconst 1 :y]
[:add :x :y :z]
[:jmp :exit]]
:exit
[[:ret :z]]
})
This, when translated to assembly and after register allocation would turn
into something like (ignoring calling conventions etc):
(def assembly-code
{
:entry
[[:x86.lea :eax global_label]
[:x86.loadimm 1, :eax]
[:x86.add32 :ebx :eax]
[:jmp :exit]]
:exit
[[:ret]]
})
The problem arises when I have to query the IR code for things like
accesses-memory? or get-output-vars in an
extensible way so that multiple target architectures can be supported.
e.g. (get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:x86.add :a :b]) - :b ;; the input and output
positions are opcode specific
(get-output-vars [:x86.add :a :b]) - :b
(get-output-vars [:divmod :a :b :c :d]) - :c :d
(accesses-memory? :x86.add) - false
(accesses-memory? :x86.load) - true
(accesses-memory? :loadconst) -false
I have to be able to write these functions in a way that knows about the
format of the basic IR opcodes, but can also be extended
to handle opcodes of architectures that don't exist in my code yet, the
extensions would exist within the namespaces of that specific architecture
and shouldn't need to modify the code for the built in opcodes.
What is the most seamless and efficient way to achieve this sort of
function extension in clojure? Also, how would I allow sharing
of implementations where instructions have similar layouts.
e.g.
(get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:sub :a :b :c]) - :c
--
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: Potential Intro clojure projects - libraries and ideas with wow factor
Clojure logic programming with core.logic (something akin to a sudoku solver https://gist.github.com/swannodette/3217582 is a good example) or using datomic to have a database with a time machine and datalog for queries might be cool (perhaps visualizing the data in the database at arbitrary times in the past). Both don't really have equivalents in other languages. Other things that are hard to achieve in other languages would involve the immutable data structures, concurrency, and macros. On Monday, April 14, 2014 9:15:31 AM UTC+12, utel wrote: A handful of developers at the organisation I work at, want to encourage interest in Clojure with the aim of using it in production amongst the organisation's wider developer community (hundreds of developers). We ourselves are Clojure hobbyists. We wanted to do this through a basic project (with few moving parts), so I wanted to get feedback on a couple of aspects: 1. Examples of basic project ideas that would be compelling to fellow developers not familiar with Clojure (e.g. something useful that you can do easily with Clojure that's harder to do in more established languages such as Java) 2. Particular libraries that again had a wow factor towards an objective not easily achievable in more established languages (perhaps related to data analysis, visualisation, or taking advantage of the benefit of lazy evaluation in a novel way as examples). I realise these questions are somewhat open-ended, but just wanted to spark off some ideas for us through bouncing these questions off the google group's members. Thanks for any leads! -- 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: Extending a data model
Thanks for the tip, I think multimethods may be what i need in this case
(perhaps which checks the current architecture in the dispatch function so
i can disable some). I want to avoid having to pass an object around and
extract methods (simply because it clutters my code). Dynamically binding
methods may be another solution.
On Tuesday, April 15, 2014 11:59:17 AM UTC+12, Reid McKenzie wrote:
Hey Andrew, I actually built something very much along these lines a few
months ago if you care to cheat off of it:
http://github.com/arrdem/toothpick is an assembler generator system that
works more or less along these lines. Label support is still a problem I
haven't completely solved and I never did build a compiler backed targeting
Toothpick, but the idea is there.
One approach, and the one that I took, is to make everything in your API
parametric on some representation of the target architecture. In Toothpick,
I build a monolithic map representing the target, and all the utility
functions are built in terms of operating on an arbitrary instruction
sequence in conjunction with this target description. This is probably the
easiest thing to do, as in your (accesses-memory?) you can simply enquire
of the target description structure rather than relying on the user to have
provided a multimethod implementation or anything else.
Hope this helps,
Reid
On Monday, April 14, 2014 6:52:36 PM UTC-5, Andrew Chambers wrote:
Hi everyone,
I'm new to clojure and in order to learn I'm working on making some
compiler tools which converts a lightweight IR code into assembly.
My data model for an IR function is along the lines of
(def code
{
:entry
[[:loadaddr :x global_label]
[:loadconst 1 :y]
[:add :x :y :z]
[:jmp :exit]]
:exit
[[:ret :z]]
})
This, when translated to assembly and after register allocation would
turn into something like (ignoring calling conventions etc):
(def assembly-code
{
:entry
[[:x86.lea :eax global_label]
[:x86.loadimm 1, :eax]
[:x86.add32 :ebx :eax]
[:jmp :exit]]
:exit
[[:ret]]
})
The problem arises when I have to query the IR code for things like
accesses-memory? or get-output-vars in an
extensible way so that multiple target architectures can be supported.
e.g. (get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:x86.add :a :b]) - :b ;; the input and output
positions are opcode specific
(get-output-vars [:x86.add :a :b]) - :b
(get-output-vars [:divmod :a :b :c :d]) - :c :d
(accesses-memory? :x86.add) - false
(accesses-memory? :x86.load) - true
(accesses-memory? :loadconst) -false
I have to be able to write these functions in a way that knows about the
format of the basic IR opcodes, but can also be extended
to handle opcodes of architectures that don't exist in my code yet, the
extensions would exist within the namespaces of that specific architecture
and shouldn't need to modify the code for the built in opcodes.
What is the most seamless and efficient way to achieve this sort of
function extension in clojure? Also, how would I allow sharing
of implementations where instructions have similar layouts.
e.g.
(get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:sub :a :b :c]) - :c
--
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: Extending a data model
An update, I read about protocols and multimethods. I think multimethods
are a decent way to go (cant use protocols without a defrecord) provided
they work across namespaces.
On Tuesday, April 15, 2014 11:52:36 AM UTC+12, Andrew Chambers wrote:
Hi everyone,
I'm new to clojure and in order to learn I'm working on making some
compiler tools which converts a lightweight IR code into assembly.
My data model for an IR function is along the lines of
(def code
{
:entry
[[:loadaddr :x global_label]
[:loadconst 1 :y]
[:add :x :y :z]
[:jmp :exit]]
:exit
[[:ret :z]]
})
This, when translated to assembly and after register allocation would turn
into something like (ignoring calling conventions etc):
(def assembly-code
{
:entry
[[:x86.lea :eax global_label]
[:x86.loadimm 1, :eax]
[:x86.add32 :ebx :eax]
[:jmp :exit]]
:exit
[[:ret]]
})
The problem arises when I have to query the IR code for things like
accesses-memory? or get-output-vars in an
extensible way so that multiple target architectures can be supported.
e.g. (get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:x86.add :a :b]) - :b ;; the input and output
positions are opcode specific
(get-output-vars [:x86.add :a :b]) - :b
(get-output-vars [:divmod :a :b :c :d]) - :c :d
(accesses-memory? :x86.add) - false
(accesses-memory? :x86.load) - true
(accesses-memory? :loadconst) -false
I have to be able to write these functions in a way that knows about the
format of the basic IR opcodes, but can also be extended
to handle opcodes of architectures that don't exist in my code yet, the
extensions would exist within the namespaces of that specific architecture
and shouldn't need to modify the code for the built in opcodes.
What is the most seamless and efficient way to achieve this sort of
function extension in clojure? Also, how would I allow sharing
of implementations where instructions have similar layouts.
e.g.
(get-output-vars [:add :a :b :c]) - :c
(get-output-vars [:sub :a :b :c]) - :c
--
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.
Clojure compiletime vs runtime
Is there an explanation of how clojure deals with scoping and its static checking. It seems to be a hybrid of a static language and a dynamic language when it comes to compilation. I'll elaborate. The following code wont compile: (defn x [] nil) (defn y[]) ((x)) however this code will compile: (defn foo[] (defn x[] nil)) (defn y[]) ((x)) but calling y before foo fails with a runtime exception. Also, the following code: (println hello) (defn -main [args] (println world)) prints hello at compile time and also hello world at runtime. My conclusions from this is that the static symbol checker is actually fairly stupid and is just there to provide some simple sanity, and that all toplevel code in a namespace is executed at compile time AND at runtime. Is this correct? -- 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 compiletime vs runtime
Forgive me, the first example was meant to be The following code wont compile: (defn y[]) ((x)) (defn x [] nil) On Tuesday, April 15, 2014 4:39:59 PM UTC+12, Andrew Chambers wrote: Is there an explanation of how clojure deals with scoping and its static checking. It seems to be a hybrid of a static language and a dynamic language when it comes to compilation. I'll elaborate. The following code wont compile: (defn x [] nil) (defn y[]) ((x)) however this code will compile: (defn foo[] (defn x[] nil)) (defn y[]) ((x)) but calling y before foo fails with a runtime exception. Also, the following code: (println hello) (defn -main [args] (println world)) prints hello at compile time and also hello world at runtime. My conclusions from this is that the static symbol checker is actually fairly stupid and is just there to provide some simple sanity, and that all toplevel code in a namespace is executed at compile time AND at runtime. Is this correct? -- 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.
lein2 - lein version fails due to org.apache.http.impl.client.DefaultRequestDirector
my lein started not working mysteriously. i can't even get lein version to work w/o a weird error: lein version Mar 31, 2014 3:11:38 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: I/O exception (java.net.NoRouteToHostException) caught when connecting to the target host: No route to host Mar 31, 2014 3:11:38 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect INFO: Retrying connect anyone else seen anything like this? my network/internet seems to be totally fine -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: Test G.Closure lib release 0.0-20140226-71326067
Huge apologies Stuart and David. In one of my projects I have a :hook for leiningen.cljsbuild. In the one I was testing and on a lein new mies ... it doesn't; so my lein clean was not doing a lein cljsbuild clean. Doh!!! Sorry for wasting your precious time and thanks for all your efforts on all of the wonderful things you create that I get to use everyday. Andrew On Thursday, 13 March 2014 12:32:37 UTC, David Nolen wrote: Andrew, I've tried the new JARs on a couple of projects and I have not encountered these issues. Did you make sure to run a `lein cljsbuild clean`? Thanks. David On Wed, Mar 12, 2014 at 8:19 PM, Andrew Keedle ake...@gmail.com wrote: Stuart, Did you ever get any response to this? I made the changes as suggested in the gist and ran into problems. With a simple [goog.events :as events] in the ns and optimizations :none I get the attached errors on a simple project from a lein new mies... optimizations :simple appears to work fine for this and more complicated setups. Thanks, Andrew -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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: Om 0.5.0-rc1
On Wednesday, 19 February 2014 03:51:15 UTC, David Nolen wrote: In order to stay in sync with React 0.9.0-rc1 I've cut Om 0.5.0-rc1. There are a couple of small breaking changes due to React but otherwise the differences between 0.4.2 and 0.5.0-rc1 are minor. One big enhancement is that you can now render to a string with om.dom/render-to-str. Another big enhancement that I had absolutely nothing to do with is that React is now almost 2X faster for the initial render under Chrome 32 Safari 7. This means under these browser Om is nearly 10X faster than a naive Backbone.js at rendering 200 items in the TodoMVC application. http://github.com/swannodette/om Feedback welcome! David Brief initial testing seems to work for me. Many thanks David. -- 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/groups/opt_out.
Re: [ANN] cljs-start 0.0.7 now support source-map
Good job. First thing that start and running from description in wiki. It seems like next evolution step in path: pure cljs - Piggieback - austin - cljs-start May be for newcomers like me it will be good to add some integraional tips for emacs(others) editors.. Thx. Andrew -- -- 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/groups/opt_out.
Re: [ANN] cljs-start 0.0.7 now support source-map
Well, Im not sure if I expressed myself correctly when asked for tips about editor - I thought about how to get Emacs (or may be other editor which support nrepl workflow) work with cljs-start. Now I see that it works good when I'm testing it. I use emacs-live for clojure work with emacs, and it seems like all things work not only from emacs clojurescript repl but from file - when I type C-x C-e - it evaluates my s-expressions and puts result to emacs's status buffer... Could you tell us maybe some other good shotcuts and tips that you use in development... I cant for ex. eval the whole buffer or reload the namescpace... What about other editors - I think they should work as far as them support nrepl... Personally I tryed Sublime Text 3, but without success... Ok, I go to play with emacs cljsrepl... -- -- 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/groups/opt_out.
Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata
For a pretty decent cover of when and how to use macros, On Lisp[1] is a pretty good book. It's written mainly for Common Lisp but most of it translates to Clojure well enough. I find that for common code, writing macros isn't so useful as most of the goods ones are already part of clojure.core. But if you ever find yourself in the position where you'd really like to have a control structure just for your program, or introduce a compile-time code generator, or subtly add a new paradigm to the language, a macro is your ticket. 1. http://code.google.com/p/onlisp/ On Friday, August 9, 2013 9:55:14 AM UTC-4, Jace Bennett wrote: Obviously I've encountered the advice no macros unless you know you need them before. And I even sort of know the syntax and what they do. I don't think that's my problem. I think I've lived a life without macros. I mean, clearly dynamic-functional and even OOP styles are perfectly capable of building most anything (within my now constrained view of what is feasible). And my head is full of techniques (what an experienced lisper might call workarounds) to deal with their limitations, so I'm habituated to the pain, and the narrow view of 'what is feasible'. So, it's not about whether I need a macro at all, because I could deal indefinitely. There are an endless supply of problems I could solve without them. It's about wisdom, discerning whether its a good tradeoff to use a macro in a given situation. I wish this was the kind of thing that could be taught. Instead, I fear, it must be learned. On Fri, Aug 9, 2013 at 9:50 AM, Jace Bennett jace.b...@gmail.comjavascript: wrote: Thanks again, Mike. That's really helpful. I'll take a look at the core.matrix stuff to try and understand implementation and motivation better. What games did you make? I'd love to check them out. Jace On Fri, Aug 9, 2013 at 4:10 AM, Mikera mike.r.an...@gmail.comjavascript: wrote: On Friday, 9 August 2013 05:07:10 UTC+8, Jonathan Fischer Friberg wrote: I'd suggest avoiding macros until you absolutely know that you need them. Usually they aren't necessary. Problem with this is that you don't really know when you need them unless you know what they do. I'm not saying don't learn how macros work. Learning is always good. My recommendation is just that your default approach should be to avoid using them unless you have tried very hard to achieve your goal with pure functions first, and convinced yourself that it isn't possible. Macros are only *needed* IMHO when one of the following applies: - You want to create new language/DSL syntax that isn't expressible with normal function application rules (e.g. short-circuiting evaluation, new control structures etc.) - You need to do custom code generation at compile time for some good reason (e.g. performance, since macros enable you to do compile-time specialisation of code) I wrote about these and gave some examples in a blog post a few months back for anyone interested: http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ On Thu, Aug 8, 2013 at 9:58 PM, Jace Bennett jace.b...@gmail.comwrote: Thanks, Mike. I guess my simple example is too simple. Out of the hypothetical, have you used techniques like this? I have this nagging feeling that there is a more direct and idiomatic way to glean this sort of information from my code. I mean, that's why we use AST's, right? So we can process them? I shouldn't need a data structure like the endpoint map in the first place. I just don't know how to capitalize on this rather abstract and vague notion. How do folks usually go about it when they have a desire to query the running system about its shape and structure? On Thu, Aug 8, 2013 at 2:36 AM, Mikera mike.r.an...@gmail.com wrote: I'd suggest avoiding macros until you absolutely know that you need them. Usually they aren't necessary. Prefer writing pure functions (without side effects) - these are easier to reason about, easier to test, simpler to write correctly and easier to plug together / compose via higher order functions. For example, in your endpoint example I would probably just use three functions: - a pure add endpoint metadata to an endpoint map function - an impure update endpoints function that updates endpoints using an endpoint map - a function that calls both of the above to declare and launch a new endpoint There might be a few other helper functions as well but hopefully you get the idea. On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote: Thanks to the community for a wondrous programming environment. I discovered SICP last year, and fell in love with the idea of lisp. But I've come to a point where I think I need practice on moderately sized projects before more reading will help. When starting on almost any moderately scoped effort, I quickly run into a
Re: Lisp newbie seeks (macro?) wisdom - instrumentation and app metadata
The difficulty with On Lisp when applied to Clojure is that the specific macros On Lisp demonstrates either depend on state, which Clojure avoids, or are already present in Clojure core. (if-let is a big one in my book.) Some of them also run into conflicts with Clojure implicit gensyming. I don't suggest it for the specific macros it demonstrates, but because it demonstrates very clearly what they are for, why and where you would use them, and how, in general, they are used. I also don't write macro much anymore in Clojure but that's mostly because Clojure has a few macros already which handle most of the things I would do with them in Common Lisp. On Friday, August 9, 2013 11:13:44 AM UTC-4, Lee wrote: On Aug 9, 2013, at 11:01 AM, Andrew Stine wrote: For a pretty decent cover of when and how to use macros, On Lisp[1] is a pretty good book. It's written mainly for Common Lisp but most of it translates to Clojure well enough. I find that for common code, writing macros isn't so useful as most of the goods ones are already part of clojure.core. But if you ever find yourself in the position where you'd really like to have a control structure just for your program, or introduce a compile-time code generator, or subtly add a new paradigm to the language, a macro is your ticket. 1. http://code.google.com/p/onlisp/ I think that On Lisp is completely awesome -- one of the best technical books of any kind that I've ever read. However, my recollection is that the macro stuff, in particular, doesn't translate so well to Clojure because the differences between Common Lisp and Clojure macros are pretty fundamental. Or at least that has been my impression and I mostly stopped writing macros when I switched from Common Lisp to Clojure because I found the differences confusing. Your experience may be different but I thought that a warning might be in order. -Lee -- -- 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/groups/opt_out.
Re: [ANN] Compliment - a completion library you deserve
Looks *very* cool. I like the drop-down list in ac-nrepl-compliment. On Friday, August 9, 2013 12:19:40 PM UTC-4, Alexander Yakushev wrote: Dear community, I've just released the initial version of my clojure-complete fork, Compliment. I decided to move it into a separate project after I rewrote most of it. Here is project's link: https://github.com/alexander-yakushev/compliment . There is a rationale in README, where I explain why I had to write this fork (initially the reason was clojure-complete being very slow to work on Android with Emacs' ac-complete, then other reasons turned up). You can see examples of what Compliment can do here: https://github.com/alexander-yakushev/compliment/wiki/Examples . Right now only Emacs is supported as a client, via my yet another fork, of ac-nrepl: https://github.com/alexander-yakushev/ac-nrepl-compliment . Finally, I don't want to seem like I'm hijacking clojure-complete's positions. It's just that clojure-complete happens to be a faithful swank-clojure's completion port, and it is pretty rigid; I think there is much to be improved in this area. -- -- 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/groups/opt_out.
Re: Hiring Clojure Programmer(s)
Might help if you said what part of the world you're in. On Friday, August 2, 2013 12:47:21 PM UTC-4, Quinn Finney wrote: Hello all, My company is looking to hire a Clojure programmer to help assess and finish our product, a server architecture system for Java instances. The product involves receiving input from a web control panel and making changes based on that. To our knowledge, the product is currently 85% complete. This will be a payed position. Please email me at quinn@gmail.com javascript: or call me at (206) 660 5366 for more information if you are interested. -- -- 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/groups/opt_out.
Re: is intellij idea a good ide for clojure development?
On 26 July 2013 09:53, Cedric Greevey wrote: Would that include a contemporary user interface that can show trees properly, do graphical diffs, and be quickly taken up by any reasonably adept Windows or Mac user the way Eclipse, clooj, and IntelliJ can? I don't speak for Håkan, but I don't think that's an explicit goal of the project. On the other hand, being in Clojure, I think it could be taken it in that direction and I'm sure it would be easier than starting from the Emacs C source. -- -- 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/groups/opt_out.
Re: is intellij idea a good ide for clojure development?
On 25 July 2013 21:55, Lee Spector wrote: For Sean or anyone who finds Sean's narrative compelling (I do), imagine emacs without the learning curve! I say it's possible and I point to the long-extinct FRED (Fred Resembles Emacs Deliberately) that was part of Macintosh Common Lisp as a proof of principle. I don't have the time or chops to develop such a thing, but if anyone here does then this would be a way to make the world a better place. Have you heard of Deuce https://github.com/hraberg/deuce by Håkan Råberg? He gave a talkhttp://skillsmatter.com/podcast/scala/deuce-is-not-yet-emacs-under-clojureon it at Skills Matter London. It not usable yet, but it looks promising. From the readme: *Deuce is a re-implementation of Emacs in Clojure.* It's a port of the C core and re-compiles existing Emacs Lisp to Clojure. It uses the Lanterna library for text UI. The goal is to reach reasonable compatibility with GNU Emacs during 2013. The longer term goal is to phase out Emacs Lisp in favour for Clojure, to add a Web UI and re-capture Emacs' spirit on a contemporary platform. Andrew -- -- 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/groups/opt_out.
Re: Latest JOGL with Clojure in Eclipse?
I dont know if I miss something, but after lein deps and trying to import NewtFacroty for ex. , clojure says me about absence of gluegen-rt-2.0.0-rc11-natives-windows-amd64.jar. All start working when I put this jar and native dlls into \.m2\repository\org\clojars\toxi\gluegen-rt\2.0.0-rc11\ I thought that all should work out of the box after lein deps, but may be I do something wrong -- -- 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/groups/opt_out.
Simple socket programming problem
Hello, I'm trying to create a very simple interaction between a client and server program using the server-socket library which used to be part of clojure-contrib and is now maintained by technomancy https://github.com/technomancy/server-socket/blob/master/src/server/socket.clj I created a simple echo server, which works fine when accessed by telnet but can't seem to accept messages from the python client. This is the code for the client and the server: client.py: import socket s = socket.socket() host = socket.gethostname() port = 9001 s.connect((host,port)) while 1: s.send(Hello) print s.recv(1024) s.close() And this is the code for the server--I tried to capture all of the input into a vector, but the vector never seems to change: (ns bot-backend.core) (use 'server.socket) (import '(java.io BufferedReader InputStreamReader PrintWriter)) (def server (create-server 9001 (fn [in out] (binding [*in* (BufferedReader. (InputStreamReader. in)) *out* (PrintWriter. out)] (loop [input []] (println input) (recur (conj input (read-line The only output the client displays is a single empty vector after which it waits to receive more data. Since this works correctly when I access the port over telnet I can't figure out what the problem is. As a novice to both clojure and socket programming my best guess is that it has something to do with multiple threading--I know that both python and clojure create a new thread for each distinct socket. It's probably an incorrect guess. That's why I've decided to consult the community :D. Any help is appreciated in advance! -- -- 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/groups/opt_out.
Re: Simple socket programming problem
It works! Wow, that was a simple solution! Thanks for the help :D :D. On Friday, May 31, 2013 9:04:42 PM UTC-4, atkaaz wrote: What happens if you send a newline after that Hello? ie. Hello\n since you're using read-line On Sat, Jun 1, 2013 at 3:44 AM, Andrew Spano werdn...@gmail.comjavascript: wrote: Hello, I'm trying to create a very simple interaction between a client and server program using the server-socket library which used to be part of clojure-contrib and is now maintained by technomancy https://github.com/technomancy/server-socket/blob/master/src/server/socket.clj I created a simple echo server, which works fine when accessed by telnet but can't seem to accept messages from the python client. This is the code for the client and the server: client.py: import socket s = socket.socket() host = socket.gethostname() port = 9001 s.connect((host,port)) while 1: s.send(Hello) print s.recv(1024) s.close() And this is the code for the server--I tried to capture all of the input into a vector, but the vector never seems to change: (ns bot-backend.core) (use 'server.socket) (import '(java.io BufferedReader InputStreamReader PrintWriter)) (def server (create-server 9001 (fn [in out] (binding [*in* (BufferedReader. (InputStreamReader. in)) *out* (PrintWriter. out)] (loop [input []] (println input) (recur (conj input (read-line The only output the client displays is a single empty vector after which it waits to receive more data. Since this works correctly when I access the port over telnet I can't figure out what the problem is. As a novice to both clojure and socket programming my best guess is that it has something to do with multiple threading--I know that both python and clojure create a new thread for each distinct socket. It's probably an incorrect guess. That's why I've decided to consult the community :D. Any help is appreciated in advance! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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/groups/opt_out.
Re: [ANN] tawny-owl 0.11
I went looking for the same thing. There are a few partial examples in the docs directory that might be worth looking at. On Wed, May 22, 2013 at 8:06 AM, atkaaz atk...@gmail.com wrote: For those who don't know the concepts (aka me) can we get a working example of what can be done ? I'm having a strange feeling that ontologies(although I've never heard the word/idea before except from you) might be something similar to what I am searching for... Possibly an example that showcases everything that can be done ? though that might be too much to ask, or perhaps suggest a link url to something that might help (me) understand ? Thanks. On Wed, May 22, 2013 at 2:41 PM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: I'm pleased to announce the release of tawny-owl 0.11. What is it? == This package allows users to construct OWL ontologies in a fully programmatic environment, namely Clojure. This means the user can take advantage of programmatic language to automate and abstract the ontology over the development process; also, rather than requiring the creation of ontology specific development environments, a normal programming IDE can be used; finally, a human readable text format means that we can integrate with the standard tooling for versioning and distributed development. Changes === # 0.11 ## New features - facts on individual are now supported - documentation has been greatly extended - OWL API 3.4.4 A new paper on the motivation and use cases for tawny-owl is also available at http://www.russet.org.uk/blog/2366 https://github.com/phillord/tawny-owl Feedback welcome! -- -- 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/groups/opt_out. -- -- 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/groups/opt_out. -- -- 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/groups/opt_out.
[GSoC 2013] Learning resource
Hello. It's probably late, but I want to offer to community a GSoC project idea. Recently, I took a part in a short Clojure courses, which were organized on pure enthusiasm by Dmitry Bushenko. There were a lot of people interested in it. Most of them didn't not know where to start but they wanted. I propose to create an engine (web resource) that allows to create educational materials for Clojure, give assignments and carry out their test. I imagine it like this: 1. Lecturer creates a video presentation or webinar. 2. Optional test task in the form of a blank leiningen project. 3. Members learn the materials and perform a task which would be tested by system after. I have ideas of how to implement different parts of the system, test project management and testing, mechanism to create whole courses for Clojure and some more. A lot can be learned from the experience of Codecademy. I think such a resource would be useful for community by promoting the language. Do you think the same and are there are any people ready to take on mentoring ? 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/groups/opt_out.
nREPL middleware for external repl.
Hello. I need a suggetion about one thing: las3r https://github.com/aemoncannon/las3r- is a subset of Clujure language, hosted inside flash runtime. The idea is to use emacs + nrepl (I want to use all it's sweet features) to talk with flash repl. My question is: can this be achieved via some combination of nrepl middlware and transport? So nrepl here is just a middleman between nrepl.el(emacs) and actual repl that executes inside flashplayer. Or a custom socket server for such a goal will be a better choice? Thx. -- -- 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/groups/opt_out.
Re: nREPL middleware for external repl.
Thanks for reply, Michael. Take a look at Piggieback by Chas Emerick: https://github.com/cemerick/piggieback Yes I saw it, but if I underestand it correctly, this middeware doesn't connect to any external repl, it passes in to inner ClojureScript evaluator, which outputs plain JavaScript which then goes either to the internal JSVM(rhino) or to the browser. Correct me please if I miss something. To be honest, I cant figure out for now how to extract any use from piggieback for my goal. I hoped that there is a simpler solution, and asked for advise.. -- -- 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/groups/opt_out.
Re: Surprising behaviour related to records, protocols and AOT
I guess extend-type does changes only to generated java class and the var
defrecordissue.arecord-ARecord
contains the 'old' version of ARecord constructor. Obviously it would be
weird for defprotocol to change the variable in another namespace.
Especially when you can extend a record from anywhere.
So If you want to create a record that implements your protocol via var
from record namespace, you should do some hackery to update that variable.
I've done a pull-request for you, but using direct constructor will be more
idiomatic
;
; this won't work unless you update manualy a variable -ARecord in the
namespace
;
;(defrecordissue.aprotocol/afn (defrecordissue.arecord/-ARecord))
;
; like
(defmacro from-ns[nmsps body]
launches body from namespace
`(binding
[*ns* (find-ns ~nmsps)]
(eval
(quote (do ~@body)
(from-ns 'defrecordissue.arecord
(import '(defrecordissue.arecord.ARecord))
(alter-var-root
('-ARecord (ns-publics 'defrecordissue.arecord))
(fn[x] (fn[] (new ARecord)
(println (defrecordissue.aprotocol/afn
(defrecordissue.arecord/-ARecord)))
; 42
ndrw
--
--
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/groups/opt_out.
Re: [ANN] Linode compromise possibly affecting Clojars
Just wanted to say, awesome job with this. I appreciate your diligence! On Wed, Apr 17, 2013 at 2:50 PM, Phil Hagelberg p...@hagelb.org wrote: Update: thanks to an older backup from Ivan Kozik, we've been able to verify the integrity of all but 45 jars. It's likely these were legitimate redeployments by the maintainers, but I'm going to be reviewing the diffs by hand. I've attached a list of jars which haven't been verified. If your dependency tree (visible with `lein deps :tree` under Leiningen 2) does not include any of these then you should be completely clear. If it does you're probably still safe; I hope to have these cleared by the end of the day. From what we know from Linode, the exposed data could not have resulted in a compromise of the box without a reboot in order to reset passwords or use the rescue image, and we've confirmed that a reboot did not occur. So checking the jar diffs is probably not necessary, but we'd rather be extra-careful. thanks, Phil amazonica/amazonica/0.1.3/amazonica-0.1.3.jar amazonica/amazonica/0.1.4/amazonica-0.1.4.jar amazonica/amazonica/0.1.5/amazonica-0.1.5.jar antler/caribou-admin/0.10.0/caribou-admin-0.10.0.jar bwo/monads/0.1.0/monads-0.1.0.jar cc/qbits/alia/1.0.0-beta7/alia-1.0.0-beta7.jar chlorine/chlorine/1.5.2.1/chlorine-1.5.2.1.jar chlorine/chlorine/1.5.2.2/chlorine-1.5.2.2.jar chlorine/chlorine/1.5.3/chlorine-1.5.3.jar clj-diffmatchpatch/clj-diffmatchpatch/ 0.0.9.1/clj-diffmatchpatch-0.0.9.1.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9.3/clj-diffmatchpatch-0.0.9.3.jar clj-diffmatchpatch/clj-diffmatchpatch/0.0.9/clj-diffmatchpatch-0.0.9.jar clojurewerkz/archimedes/1.0.0-alpha3/archimedes-1.0.0-alpha3.jar com/akolov/xelery/0.3.0/xelery-0.3.0.jar com/narkisr/carmine/1.6.0/carmine-1.6.0.jar com/narkisr/gelfino-client/0.4.0/gelfino-client-0.4.0.jar conveyor-coffeescript/conveyor-coffeescript/0.1.4/conveyor-coffeescript-0.1.4.jar core-cl2/core-cl2/0.7.0/core-cl2-0.7.0.jar core-cl2/core-cl2/0.7.1/core-cl2-0.7.1.jar docopt/docopt/0.6.1/docopt-0.6.1.jar factual/c4/0.0.11/c4-0.0.11.jar homestake-server/homestake-server/0.1/homestake-server-0.1.jar info/yasuhisay/clj-utils/0.1.1/clj-utils-0.1.1.jar info/yasuhisay/liblinear/0.0.1/liblinear-0.0.1.jar lamina/lamina/0.5.0-beta15/lamina-0.5.0-beta15.jar lein-haml-sass/lein-haml-sass/0.2.5/lein-haml-sass-0.2.5.jar lein-package/lein-package/0.1.2/lein-package-0.1.2.jar lib-noir/lib-noir/0.5.0/lib-noir-0.5.0.jar luminus/lein-template/0.5.3/lein-template-0.5.3.jar luminus/lein-template/0.5.5/lein-template-0.5.5.jar me/arrdem/imprecise/me.arrdem.imprecise/0.1.0/me.arrdem.imprecise-0.1.0.jar net/clojure/monads/1.0.1/monads-1.0.1.jar nsfw/lein-template/0.5.2/lein-template-0.5.2.jar org/flatland/phonograph/0.1.4/phonograph-0.1.4.jar org/trpr/integration-rabbitmq/1.2.2/integration-rabbitmq-1.2.2.jar org/trpr/platform-core/1.2.2/platform-core-1.2.2.jar org/trpr/platform-integration/1.2.2/platform-integration-1.2.2.jar rojat/rojat-arrows/0.0.6/rojat-arrows-0.0.6.jar rojat/rojat-math/0.0.2/rojat-math-0.0.2.jar rojat/rojat-math/0.0.3/rojat-math-0.0.3.jar rst-format-parser/rst-format-parser/0.0.1/rst-format-parser-0.0.1.jar service-hub/service-hub/1.0.3/service-hub-1.0.3.jar stereotype/stereotype/0.2.1/stereotype-0.2.1.jar stereotype/stereotype/0.2.2/stereotype-0.2.2.jar thebusby/clj-aws-ec2/0.2.2/clj-aws-ec2-0.2.2.jar -- -- 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/groups/opt_out.
Re: Surprising behaviour related to records, protocols and AOT
I guess you have to import defrecord generated class before you want to use it, check the sample from clojuredocs about defrecord ; If you define a defrecord in one namespace and want to use it ; from another, first require the namespace and then import ; the record as a regular class. ; The require+import order makes sense if you consider that first ; the namespace has to be compiled--which generates a class for ; the record--and then the generated class must be imported. ; (Thanks to raek in #clojure for the explanations!) ; Namespace 1 in my/data.clj, where a defrecord is declared (ns my.data) (defrecord Employee [name surname]) ; Namescape 2 in my/queries.clj, where a defrecord is used (ns my.queries (:require my.data) (:import [my.data Employee])) (println Employees named Albert: (filter #(= Albert (.name %)) [(Employee. Albert Smith) (Employee. John Maynard) (Employee. Albert Cheng)])) -- -- 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/groups/opt_out.
Re: Function recurring regardless of condition
Awesome! I've been re-factoring my code but I am having difficulty figuring out how to deal with state without manipulating global state; my first thought was to create a binding form within a doseq in a function that executed each instruction and mutated the cells when necessary--but that didn't work out. I like your usage of multimethods to deal with each instruction, although as a beginner some parts of your code are difficult for me to follow. This is shaping up to be a pretty good learning experience for me! I think my mind is still stuck in an imperative mode of thinking, and it's helpful to look at the code of a more seasoned clojure programmer. On Sunday, April 7, 2013 10:06:26 PM UTC-4, Michał Marczyk wrote: Incidentally, this thread made me feel a sudden desire to write my own bf interpreter. Feel free to take a look at https://github.com/michalmarczyk/bf.clj if you'd like. :-) Cheers, Michał On 7 April 2013 05:23, Sean Corfield seanco...@gmail.com javascript: wrote: I agree. I see nothing that sets the code pointer back to the start of the loop. I also agree with Michał's suggestion that getting rid of global state and making this more functional in style will make it much easier to read, debug and maintain - as it stands it not very idiomatic for Clojure. Sean On Sat, Apr 6, 2013 at 5:16 PM, Michał Marczyk michal@gmail.comjavascript: wrote: Not sure why you're using (- end-index 2) in the printed message. Also, you can use (dec end-index) in your termination condition. As for the main problem, I haven't studied your program very closely, but it seems to me that your program counter may never get reset to the beginning of the loop, in which case the next call to (exec-instruction end-loop) would start executing instructions just past the end of the loop body. Cheers, Michał On 7 April 2013 01:49, Andrew Spano werdn...@gmail.com javascript: wrote: Hello, I'm a new clojure programmer--but after learning a bit of clojure including iteration, some core high order functions, and a little bit about state management I decided to try my hand on a brainfuck interpreter. Located here: https://github.com/recursor94/brainfuck.clj/blob/master/brainfuck/src/brainfuck/fuck.clj Handling looping complicated things. And the way I chose to deal with looping resulted in some pretty ugly functions. I hope to clean that up in the future and refractor the code into a more functional style after I've finished the first draft. The issue is in a particular function which never stops recuring even when the condition for recuring is false: (defn exec-instruction executes each function in the codemap vector in sequential order ([end-index] (inc-code-pos) ;;side affect function that moves the code pointer (I have both a code pointer and a data pointer in my interpreter) (loop [index (:index @codemap)] (let [codevec (@codemap :struct) instruct (get codevec index)] (println index: index instruct instruct minus one index: (- end-index 2)) (instruct)) (when-not (= index (- end-index 1)) (println yeah you are) (inc-code-pos) (recur (inc index) ;;end problem ([] (doseq [instruct (@codemap :struct)] (instruct) ;;higher order functions ftw (inc-code-pos And here is the function that triggers this function: (defn begin-loop run through a loop until current cell drops to zero [] (loop [loop-counter (@cells @pointer) end-loop (find-end (@codemap :index)) ;;find-end returns an integer pos (@codemap :index)] (println cell counter: loop-counter other: (@cells @pointer) at 0: (@cells @pointer) also: end-loop) ;;debug output (exec-instruction end-loop) (when-not (= loop-counter 0) (recur (@cells @pointer) end-loop pos The program is supposed to stop when it reaches a closing end brace and jump back to the opening brace in the code. But the output indicates that the program never gets passed the first iteration. For example, given this hello world brainfuck program: ++[+-]++.+.+++..+++.++.+++..+++.--..+.. The program outputs the following: index: 11 instruct #'brainfuck.fuck/+pointer minus one index: 39 yeah you are index: 12 instruct #'brainfuck.fuck/plus minus one index: 39 yeah you are index: 13 instruct #'brainfuck.fuck/plus minus one index: 39 yeah you are index: 14 instruct #'brainfuck.fuck/plus minus one index: 39 yeah you are index: 15
