[ANN] Happy 0.5.0 - a Clojure(Script) HTTP async client library
Hi, I am pleased to announce the first release of happy [1] - a Clojure(Script) HTTP async client library with swappable client implementation. Happy is a low-level HTTP async client callback driven following RING spec. Most advanced usage can be implemented on top of an interceptor [2] abstraction, notably media-type driven body transformation via a representor [3] protocol. This first release ships with a Clojure client based on OkHttp and a ClojureScript client based on XHR. Julien [1] https://github.com/jeluard/happy/ [2] https://github.com/jeluard/happy#interceptor [3] https://github.com/jeluard/happy#representor -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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-RC1 now available
My bad I was using an older beta. With latest RC1 the issue goes away. Julien Le mardi 26 mai 2015 23:24:41 UTC-3, Alex Miller a écrit : > > No, please report if so. > > On Tuesday, May 26, 2015 at 8:39:32 PM UTC-5, Julien wrote: >> >> I just ported an app with significant CLJX usage (55 files) to reader >> conditionals and it works perfectly! >> >> It looks like there is a small issue related to map literal containing >> comments but I am not sure if it has been reported yet. >> >> Julien >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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-RC1 now available
I just ported an app with significant CLJX usage (55 files) to reader conditionals and it works perfectly! It looks like there is a small issue related to map literal containing comments but I am not sure if it has been reported yet. Julien Le jeudi 21 mai 2015 13:31:16 UTC-3, Alex Miller a écrit : > > Clojure 1.7.0-RC1 is now available. > > Try it via > - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/ > - Leiningen: [org.clojure/clojure "1.7.0-RC1"] > > The only change since 1.7.0-beta3 is CLJ-1706, which makes reader > conditional splicing an error at the top level (previously it would > silently drop all but the first spliced element). > > For a full list of changes since 1.6.0, see: > https://github.com/clojure/clojure/blob/master/changes.md > > Please give it a try and let us know if things are working (or not). The > more and quicker feedback we get, the sooner we can release 1.7.0 final! > > - Alex > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] ANN: ClojureScript 0.0-3196, Conditional Reading, REPLs, and Code Motion
Hi,
that looks like a tools.reader version conflict. You can get more details about
all your project dependencies using `lein deps :tree`. Make sure the only
tools.reader is the one coming from ClojureScript.
Julien
Le vendredi 10 avril 2015 23:42:35 UTC-3, Ravindra Jaju a écrit :
> Hi.
>
>
> I need some help here to understand some errors I see after switching to
> 0.0-3196
>
>
> Top-level exception message:
> clojure.lang.ArityException: Wrong number of args (2) passed to: reader/read
>
>
>
> This was working okay with 0.0-3169
>
>
> The change commit-id 6d4ee9c0f938ac62147ecda6a2a47fcb2cca69e4 has the
> following diff around reader/read
>
> - (reader/read pbr nil eof-sentinel opts nil))]
> + (reader/read opts pbr))]
>
>
> I'm using leiningen (lein-cljsbuild) to build this, but a direct build from
> REPL as follows (as suggested in the Wiki)
> (require 'cljs.closure)
>
> (cljs.closure/build "src" {:output-to "out/main.js"})
>
>
> also throws the same exception.
>
>
> What could I be missing?
>
>
> Thanks,
> jaju
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send 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: ClojureScript 0.0-2371
Hi David, thanks once again for the continuous effort to improve the ClojureScript compiler. Some warnings are now printed when using a specific `include-macros` syntax. I wanted to confirm that this syntax was indeed incorrect. An example is: [secretary.core :as secretary :include-macros true :refer [defroute]] Is the proper way to include macros to rely on the top-level `require-macros` keyword? Thanks, Julien Le vendredi 10 octobre 2014 09:07:31 UTC-3, David Nolen a écrit : > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > > README and source code: https://github.com/clojure/clojurescript > > > > New release version: 0.0-2371 > > > > Leiningen dependency information: > > > > [org.clojure/clojurescript "0.0-2371"] > > > > This release includes minor fixes, faster collection iterators, and > > stays in sync with the latest transducers changes in Clojure master. > > > > ### Fixes > > * CLJS-862: fix inconsistent re-pattern > > * CLJS-866: Faulty ns macro desugaring > > * CLJS-869: When preamble is not found in source directory, compiler > > does not report 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: Clojure and clojurescript deps in libraries
Hi Nikita,
it does sound like a good advice from a dependency perspective. If you don't do
that clojurescript and all its dependencies leak to projects using your library
and that's definitively problematic. For clojure/clojurescript projects it's
even more important to consider that point.
That said clojure/clojurescript are not regular dependency and by defining a
version you also declare the minimum language features needed by your library.
That's definitively a grey area as both concepts are merged now.
Julien
Le samedi 7 juin 2014 11:08:31 UTC-3, Nikita Beloglazov a écrit :
> Hi
>
> I have a question about best practice for development clojure/clojurescript
> libraries.
> Usually you can see following in project.clj in some library:
>
>
>
>
> :dependencies [[org.clojure/clojure "1.5.1"]
>
> [org.clojure/clojurescript "0.0-2197"]]
>
>
>
> Why not to put clojure and clojurescript deps under :dev profile? All
> clojure and clojurescript projects explicitly specify versions of clojure ans
> clojurescript in their project.clj so I find it reduntant and potentially
> conflicting to inherit them from library. So why put it library project.clj
> in the first place?
>
>
>
> So I would suggest to use :dev profile for this:
>
>
>
> :profiles {:dev {:dependencies [[org.clojure/clojure "1.5.1"]
>
> [org.clojure/clojurescript "0.0-2197"]]}}}
>
>
> Using dev profile means that you have clojure and clojurescript for
> development but when you release library - the library doesn't depend on them
> and users get just code without "infrastructure" deps. I see following pros
> with this approach:
>
> No potential conflicts between library and project depsReduces confusion like
> "ah, library depends on clojure 1.6.0, that means it doesn't work with 1.5.1".
>
> I can't think of cons of this approach.
>
>
> I'd be happy to hear other people opinions on that question.
>
>
> Thanks,
> Nikita
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send 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: Garden, Thorn - Looking for contributors
Hi Joel, thanks for your great work on garden! Definitively helping me every day. Can you share what you have in mind regarding CSSOM integration? It certainly opens cool perspective and I'm curious how you see it fit with garden. I would be interested in giving you a hand here. Maybe a github issue would help start discussions? Julien Le samedi 22 mars 2014 22:41:04 UTC-3, Joel Holdbrooks a écrit : > > Greetings everyone, > > About a year ago I began working on Garden and in the short time the > library has been around it's grown a bit. Although many folks seem to be > interested in it, there's certainly not as much adoption of the library as > I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be > the default choices for many people writing web applications in Clojure. > > This is something I'd like to change... but I need *your* help! > > No, no. Put down the phone. Don't look for a KickStarter URL. It's nothing > like that. > > How you can help Garden > > I'm looking for individuals who are interested in the following: > > >- improving the compiler code >- improving/extending existing API's >- building an interface to the CSSOM > > I'm also open to good 'ol fashioned suggestions, pain points you've > experienced using the library, or flat out letting me know what it would > take to get you to choose Garden over the alternatives for your next > project. > > How you can help Thorn > > Thorn is very young project and has no official release yet. So what is > it? At the moment it's the beginnings of a Sass Parse Tree transformer; > something that will take CSS/SCSS/Sass code and give you Garden code. > There's a lot of fabulous libraries available in Sass and I'm sure it's a > big factor when choosing how to go about CSS generation. > > I'm looking for individuals who are interested in the following: > > >- accurately transforming CSS/SCSS/Sass to real Clojure code targeting >Garden >- accurately transforming Less to real Clojure code targeting Garden > > Why? > > I deeply believe that being able to author CSS in Clojure or ClojureScript > is a key piece to having an extremely compelling story for web application > development in Clojure. Being able to *program* CSS and not just > *preprocess* is a big advantage over existing tools. Being able to use > all of Clojure everywhere has astounding possibilities. > > > If any of this sounds interesting to you please get in contact with me or > reply here. I will also be in San Francisco tomorrow until Tuesday for > Clojure/West if you'd like to discuss these items in person. > > > Truly, > > Joel > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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] Lucuma 0.2.0
Hi, I am pleased to announce release 0.2.0 of lucuma [1][2] - a Web Components library for ClojureScript. Lucuma helps with creating custom HTML elements encapsulating document, style and logic. You can think of it as Google polymer in ClojureScript world. This release [3] introduces element definition reusability, greatly improves properties support and rationalizes the syntax. I consider its API fairly stable at this stage. Next release [4] will focus on introducing a new syntax to unify document definition with dynamic document changes. [5] Feedback welcomed! Thanks, Julien [1] http://jeluard.github.io/lucuma/ [2] https://github.com/jeluard/lucuma/ [3] https://github.com/jeluard/lucuma/blob/master/CHANGELOG.md [4] https://github.com/jeluard/lucuma/issues?milestone=2&page=1&state=open [5] https://github.com/jeluard/lucuma/issues/8 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server
Impressive! Did you run some benchmark? How does it compare to ring-jetty and http-kit? Julien Le jeudi 9 janvier 2014 12:42:31 UTC-3, Xfeep Zhang a écrit : > > [image: Alt > text]<https://github.com/xfeep/nginx-clojure/blob/master/logo.png>Nginx-Clojure > > is a Nginx <http://nginx.org/> module for embedding Clojure or Java > programs, typically those > Ring<https://github.com/ring-clojure/ring/blob/master/SPEC>based handlers. > > There are some core features : > >1. Compatible with > Ring<https://github.com/ring-clojure/ring/blob/master/SPEC>and obviously > supports those Ring based frameworks, such as Compojure etc. >2. One of benifits of Nginx <http://nginx.org/> is worker processes >are automatically restarted by a master process if they crash >3. Utilizes lazy headers and direct memory operation between > Nginx<http://nginx.org/>and JVM to fast handle dynamic contents from Clojure > or Java code. >4. Utilizes Nginx <http://nginx.org/> zero copy file sending mechanism >to fast handle static contents controlled by Clojure or Java code. >5. > >Supports Linux x64, Win32 and Mac OS X > > > Use Nginx-Clojure, you can deploy clojure web app on Nginx without any > Java web server. For more detials please check Nginx-Clojure github > site<https://github.com/xfeep/nginx-clojure>. > > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: request for feedback
Very nice! Definitively something I find useful. I guess most are already part of your todo list but here are some features I think might be interesting for library writers: * receive some notification when new versions are available * update some dedicated branch with new versions so they can be tested by continuous integration system for early feedback Beyond that here are suggestions of somewhat orthogonal ideas: * allow to add metadata to libraries (like known bugs, security issues) => you could then qualify the urgency to update some dependency * resolve license conflicts (say your license is incompatible with the license of one of the dependencies) (sonatype has some product doing that: http://www.sonatype.com/application-health-check) Maybe some sort of extension mechanism could be helpful? Julien Le mercredi 30 octobre 2013 21:09:02 UTC-3, Anton Podviaznikov a écrit : > > Hey everyone, > > I'm working on project called jarkeeper ( > https://github.com/hashobject/jarkeeper.com). > > It's a simple tool that may be helpful in few cases: > > 1. Can help you understand if some Clojure library uses latest > dependencies (e.x. http://www.jarkeeper.com/korma/Korma) > 2. Provides status of dependencies in your own Clojure projects. > > I'm curious if anyone founds this useful (because I'm thinking on adding > more functionality). Appreciate any feedback. > > > P.S. Most of the work is done inside https://github.com/xsc/ancient-clj > library. > Also there is similar project. > > Anton Podviaznikov > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: [ClojureScript] Re: Fast path to having fun with ClojureScript
Thanks that's clearer now. Somehow I understood that output-to was supposed to be relative to output-dir. One thing that prevents me to use optimizations :none is that the generated js are not as straightforward to use as with others optimizations: you need to manually include some js files (at least goog/base.js) and call goog.require. Is that something that could be automatically added to the entry point js? Thanks, Julien -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: Fast path to having fun with ClojureScript
Hi David, awesome to see all those recent improvements in the ClojureScript compiler! Thanks for the hard work. Compilation is super fast in optimizations :none mode. A dumb change will be compiled in below a second. Now the same change in optimizations :simple takes 30 s. Is that expected? Is it worth my time to investigate that? Also I am not entirely clear when the output-dir property should be used and how it interacts with output-to and source-map. Could you clarify that? Thanks, Julien Le lundi 28 octobre 2013 01:25:31 UTC-3, David Nolen a écrit : > Given the source map improvements to ClojureScript, now is a good time to > present a newbie friendly guide to hacking with ClojureScript. Emphasis on no > fuss and getting as quickly as possible to productive experimentation: > > > > http://swannodette.github.io/2013/10/27/the-essence-of-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/groups/opt_out.
Re: another game of exploding heap, via clojure.string/split
You might want to give Eclipse MAT (http://www.eclipse.org/mat/) a try. It can be used as a standalone tool. Julien Le mardi 17 septembre 2013 12:45:41 UTC-3, Brian Craft a écrit : > > I did, of course, spend a lot of time with google before posting. All of > the hits point to jconsole, jmap, and visualvm. None of these tools work > reliably. They hang, they crash, they spit up errors, they generate useless > results. You'll note in another thread this morning another developer > having jmap and visualvm barf on them. It's not an isolated incident. > > On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: >> >> Another possibility: The people who know aren't reading this thread. >> >> I'd tell you if I knew, but I haven't needed to track down a problem like >> this for several years, and forgotten whatever tool I used at the time (it >> was probably jmap). >> >> Suggestion: Google search "java memory leak" and see what tools and >> techniques people suggest in articles they write on the topic. >> >> Andy >> >> >> On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft wrote: >> >>> >>> >>> On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: >>> >>>> On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut >>>> wrote: >>>> >>>>> I have just added some discussion of this on ClojureDocs.org for the >>>>> function clojure.core/subs, and references to that discussion for several >>>>> other Clojure functions that I am pretty sure are affected, e.g. re-find, >>>>> re-seq, re-matches, clojure.string/split, replace, replace-first >>>>> >>>> >>>> We know with certainty that clojure.string/split is affected. Also, the >>>> OP's question about how to use tooling to track down similar leaks in the >>>> future does not appear to have been satisfactorily answered as of yet. >>>> >>> >>> cricket, cricket, cricket... >>> >>> ;) >>> >>> Is there really no working tooling for the jvm? >>> >>> The string thing bothers me less than the problem of seq heads. It is >>> ridiculously easy to create a memory leak with a seq, and desperately hard >>> to track one down. I would be surprised if most clojure apps were not >>> leaking memory somewhere, in places that go unnoticed until a sufficiently >>> large input fills the heap. >>> >>> I wonder if a static analysis approach could identify code that appears >>> to retain a seq head to no effect. >>> >>> -- >>> -- >>> 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/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: ClojureScript 0.0-1877 (Breaking change)
Hi David, that is really nice! Speedup during incremental build is definitively the one thing that would improve my ClojureScript dev workflow. I gave this build a try with lein-cljsbuild and got some unexpected WARNINGS. What I am doing: * lein cljsbuild once => everything is fine * change some cljs file * lein cljsbuild once => tons of WARNINGS, all variations of "WARNING: Use of undeclared Var clojure.string/reduce at line 16 file:/Users/../clojurescript-0.0-1877.jar!/clojure/string.cljs" It looks like unchanged cljs files also generate those warnings (but I am not quite sure what the incremental compilation does exactly). Interestingly resulting js file seems correct. Let me know if I should open a JIRA/create a simple reproducing example. Thanks for the awesome work on ClojureScript, Julien Le dimanche 8 septembre 2013 20:42:51 UTC-3, David Nolen a écrit : > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > README and source code: https://github.com/clojure/clojurescript > > > New release version: 0.0-1877 > > > Leiningen dependency information: > > [org.clojure/clojurescript "0.0-1877"] > > > > > > Breaking Changes: > > * Keywords are no longer represented as JavaScript Strings > > > > > Enhancements: > > * Only analyze files that need re-analysis, significant speedup for > incremental compilation > * Leiningen project.clj provided > > > Fixes: > * CLJS-582: duplicate items in sets > > * CLJS-585: ChunkedCons does not implement INext > * ClojureScript clojure.string/split same behavior as Clojure > > * CLJS-565: Allow the clojurescript reader to read "%" > * CLJS-580: def + fn bug when fn in a data literal > > * CLJS-509: spurious protocol warning under incremental compilation -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: Exception propagation design in Clojure web APIs.
For anyone looking to do something similar (i.e. using exception control flow for handling request errors & validation), I found the slingshot<https://github.com/scgilardi/slingshot> library invaluable for enhanced try and throw leveraging Clojure. Going with 'native' try/throw was becoming nightmarish very quickly. Thank you all for your input on this. Julien On Thursday, March 21, 2013 3:27:07 AM UTC-4, Marko Topolnik wrote: > > On Wednesday, March 20, 2013 11:29:55 PM UTC+1, James Reeves wrote: > >> On 20 March 2013 16:41, Marko Topolnik wrote: >> >>> On Wednesday, March 20, 2013 4:34:32 PM UTC+1, James Reeves wrote: >>> >>>> >>>> If validation happens "all around", that implies there is no one >>>> function that can test whether a value of data is valid for a given data >>>> store. This strikes me as a somewhat shaky foundation for a system. >>>> >>> >>> The idea is that all validation functions share the same contract to >>> call the appropriate *add-failure* function that registers the >>> validation result. >>> >> >> I don't see why that would be necessary. Why not put all the validation >> logic in one place? >> > > Indeed, why not. If the requirements allow it, it is definitely preferred. > > >> >> >>> There may be instances where it makes sense to use exceptions as a >>>> control flow mechanism, but I wonder whether it wouldn't be better to use >>>> something like CPS in those instances. >>>> >>> >>> I can't picture how such a mechanism would work, and what benefit it >>> would bring over the exceptions mechanism. CPS in Clojure means >>> trampolining, which is quite an unwieldy, and I'd say "cheap" tack-on. A >>> validating function would then be supposed to return a common, >>> globally-defined "continuation", in fact just a simple function, that would >>> redirect the flow towards the validation failure-handling case. >>> >> >> I wasn't thinking of validation when I suggested CPS, because I don't see >> a need for any unusual control flow when validating data. >> > > That's enterely use case-dependent. In some project validation was > specified as fail-fast, and it happened in the middle of business logic > because the validation status couldn't be determined without computing some > interim results. Throwing an exception from a function three-four levels > down was the perfect choice in that case. > > -marko > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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: Exception propagation design in Clojure web APIs.
Would there be a way of combining this approach with the use of
preconditions in clojure?
E.g.
(defn create-user [user]
{:pre validation/user? user}
(db/insert! user))
On Wednesday, March 20, 2013 1:00:23 PM UTC-4, Marko Topolnik wrote:
>
> On Wednesday, March 20, 2013 5:51:59 PM UTC+1, Julien Dreux wrote:
>
>> Thank you all for your answers,
>>
>> I like Marko's approach.
>>
>> What I had in mind, related to OP's post, would be a middleware that does
>>> (binding [*validation-failures* []]
>>>(handler req)
>>>(do-something-about *validation-failures*))
>>> There would be a global function, such as *add-failure*, which would *
>>> conj* a new failure to the vector.
>>
>>
>> Being a Clojure novice I had no idea that this was a possibility and it
>> sounds like a better approach than exception throwing. Is this something
>> similar to the way lib-noir does it?
>> https://github.com/noir-clojure/lib-noir/blob/master/src/noir/validation.cljsee
>> the set-error fn.
>>
>
> Hm, that's really it, quite precisely; I wasn't aware of it. Seeing it now
> I realize that in my example I made the mistake of forgetting to wrap the
> failure vector inside an atom. Without that it won't work.
>
> -marko
>
>
>
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send 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: Exception propagation design in Clojure web APIs.
Thank you all for your answers, I like Marko's approach. What I had in mind, related to OP's post, would be a middleware that does > (binding [*validation-failures* []] >(handler req) >(do-something-about *validation-failures*)) > There would be a global function, such as *add-failure*, which would *conj > * a new failure to the vector. Being a Clojure novice I had no idea that this was a possibility and it sounds like a better approach than exception throwing. Is this something similar to the way lib-noir does it? https://github.com/noir-clojure/lib-noir/blob/master/src/noir/validation.clj see the set-error fn. I would still code my own library because I am learning clojure at the moment. Question: how is it possible to guarantee that the *failure-list* or *error-list* is only available to the current request. Is that one of the properties of :dynamic? On Wednesday, March 20, 2013 8:24:48 AM UTC-4, Marko Topolnik wrote: > > On Wednesday, March 20, 2013 1:06:54 PM UTC+1, Dave Sann wrote: > >> Marko, do you have a good example of doing what you say? >> > > What I had in mind, related to OP's post, would be a middleware that does > > (binding [*validation-failures* []] >(handler req) >(do-something-about *validation-failures*)) > > There would be a global function, such as *add-failure*, which would *conj > * a new failure to the vector. > > -marko > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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.
Exception propagation design in Clojure web APIs.
Hi all,
Coming from a Java background, I am having a hard time understanding how
validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName);
} else if (...) {
throw new EmailAlreadyInUseException(u.getEmail());
}
}
/** Endpoint method, catches & formats the exceptions thrown by the db
method. **/
@POST("/api/user/create")
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions to
responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to write
tons of if/else statements for validation handling. Exception were just
thrown from anywhere, bubbling back up to inital call, and if not handled
in the endpoint method, a specialized class mapped them into a proper
response. The exceptions contained all the information needed to generate
'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors ["error 1" "error 2" ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send 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: Can "lein install" create checksum (MD5, SHA-1) files?
On Tuesday, March 27, 2012 4:54:56 PM UTC-6, Phil Hagelberg wrote: > > Julien Chastang writes: > > > Can lein install create checksum (MD5, SHA-1) files when installing > > artifacts in a local Maven repository? Heroku requires artifacts be > > deployed with checksum files. > > Can you explain a bit more about what you're trying to do? I can't think > of anything specific to Heroku that would require checksum files. > I have Clojure project artifacts that are not in a public Maven repository, but simply in a local repository (so-called unmanaged dependencies). When pushing a project to Heroku, Heroku will attempt to install the local dependencies from a Maven repository that is bundled with your project. See https://devcenter.heroku.com/articles/local-maven-dependencies. If the artifacts do not contain checksum files, they are ignored by the installation process, or at the very least you get pesky warnings about this. (The whole unmanaged dependency Heroku deployment is fragile, and took me a while to get right.) > > lein install generates a pom.xml, but when running mvn install > > -DcreateChecksum=true from that pom.xml, mysteriously the .clj files > > are not packaged up in the artifact jar. > > It sounds like you might want "lein deploy" rather than "lein install"; > that should create the necessary metadata files. > $ lein help deploy Build jar and deploy to remote repository. $ lein help install Install current project or download specified project. With no arguments, installs the current project and its dependencies in your local repository. I believe lein install is the correct choice. Thanks for all your work with leiningen. It is a nice tool. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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
Can "lein install" create checksum (MD5, SHA-1) files?
Can lein install create checksum (MD5, SHA-1) files when installing artifacts in a local Maven repository? Heroku requires artifacts be deployed with checksum files. lein install generates a pom.xml, but when running mvn install -DcreateChecksum=true from that pom.xml, mysteriously the .clj files are not packaged up in the artifact 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
Re: Could be my favourite improvement in 1.4
for these cases wouldn't be simpler to paste the map in a string and to create a function that could parse such a json-compatible map into a clojure map ? A. On Dec 20, 2011, at 1:36 PM, Alex Baranosky wrote: > For what it's worth, I think colon's as whitespace in maps adds confusion, > without, imo adding a ton of power or readability. In terms of power, it > gives you the ability to paste JSON into a Clojure REPL; I wonder how often > that use case comes up? In terms of readability, any benefit it gives you in > readability would be counterweighted by the additional syntax rules it adds. > > The only way I could see this as worth it, would be if people wanted to paste > 'foreign' map data into a Clojure REPL a ton more frequently than I imagine > they do. > > Alex > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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
Are reader macros and "regular" macros handled differently by the compiler?
Are reader macros and "regular" macros handled differently by the compiler? If possible, please give some contrasting details about what the compiler is doing in each case. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Possible Issue with Listing 11.5 from the "Joy of Clojure"
Thanks for your in-depth analysis. In conclusion, the 11.5 listing is broken specifically with the reification of the seq function. The problem is that the seq function allows the array reference to escape in an unsafe manner. The issue is concurrency as well as visibility. As you suggest, the only fix is to safely copy (via the locking function, i.e. synchronized block) the contents of the array into a data structure that would be passed back to the calling code. By the way, I still think you need a lock in the count function in the case where the caller tries to invoke the count function on a partially constructed object. You may be able to reason otherwise, but it is simply confusing to do so. Just access shared mutables in a safe manner and you will be OK. On Jul 29, 3:38 pm, Ken Wesson wrote: > On Fri, Jul 29, 2011 at 3:19 PM, Julien wrote: > > This listing is an attempt to make the function safe for concurrent > > modification. My claim is that count and seq should also be locking > > around "a" for exactly same reason as aget and aset. In particular, > > locking is not only ensuring mutual exclusion but also *visibility*. > > The danger is that count and seq may be accessing stale values of "a". > > In the case of "count" that danger doesn't exist; Java arrays are of > fixed size from creation, so the "count" value cannot change. > > The case of "seq" is trickier: the array can indeed change contents > midway through iteration. But there's no simple fix. One could write > something like > > (let [cnt (dec (count a)) > step (fn step [i] > (lazy-seq > (if (> i cnt) > (do (monitorexit a) nil) > (cons x (step (inc i))] > (monitorenter a) > (step 0)) > > to hold a lock all the way through seq traversal, but if the seq is > only partially traversed (either deliberately, or because of a thrown > exception) the lock will never get released. > > More complicatedly, you could create a CloseableSeq defprotocol that > extends ISeq and Closeable and create closeable seqs (line-seq could > benefit from this as well); for the above the close operation would be > (monitorexit a) (and for line-seq (.close rdr)). Closeable seqs could > then be created in (with-open ...) and handled in an exception-safe > manner -- so long as you made sure to consume or doall the seq before > the end of the with-open scope. In the array seq case, the seq would > still seem to work after the scope exited, but it would show an array > in a possible state of flux again instead of a fixed state. > > Given all this complication, easiest might be > > (seq [this] > (locking a > (seq (into [] a > > which has the downside of copying the array into a vector but the > upside of being thread- and exception-safe; the seq is backed by a > fixed snapshot of the array. And can be traversed lazily and at > leisure without holding onto a lock the whole time; the lock's held > only during the copying. If you're worried about seeing inconsistent > cell values during a traversal of a short array this is what you ought > to use. > > But you should probably prefer to avoid arrays for the most part. :) > > Note: you will still potentially see *stale* values; the array can > change after the snapshot is made. To avoid that you'd always have to > lock during the operation where you want to be seeing the most up to > date values. But you wouldn't see *inconsistent* values. If the array > contains all 1s, and then someone else locks it, changes each cell to > 2, and unlocks, and you are traversing the seq given above, you might > get back (1 1 1 1 2 2 2 ...) which violates the intended invariant of > all-the-same-number. With the snapshot you'll possibly see all-1s even > after it's been updated to all-2s but you will never see a mixture. > With locking the array the whole time you're working with the seq, > you'll see all-2s if the array was ever updated to all-2s and > otherwise the thing that will eventually update it to all-2s will > block until you're done with the seq. > > > See Java Concurrency in Practice, Section 3.1 for more of a > > discussion. My reasoning is based on the assumption that locking is > > simply an abstraction for the Java synchronized keyword. That > > assumption may or may not be correct. > > It is correct, though Clojure exposes the lower-level monitorenter and > monitorexit; both Java synchronized and Clojure locking boil down to > (the bytecode emitted by) > > (try > (monitorenter foo) > ... > (finally (monitorexit foo))) > > so as to ensure the lock is re
Possible Issue with Listing 11.5 from the "Joy of Clojure"
Hi Everyone. I have been reading the "Joy of Clojure" with great interest, but I may have noticed a possible problem with listing 11.5. For those of you who don't have the book, here is the listing: (defn make-safe-array [ t sz] (let [a (make-array t sz)] (reify SafeArray (count [ _] ( clj/count a)) (seq [_] (clj /seq a)) (aget [_ i] ( locking a (clj /aget a i))) (aset [ this i f] ( locking a (clj /aset a i (f ( aget this i This listing is an attempt to make the function safe for concurrent modification. My claim is that count and seq should also be locking around "a" for exactly same reason as aget and aset. In particular, locking is not only ensuring mutual exclusion but also *visibility*. The danger is that count and seq may be accessing stale values of "a". See Java Concurrency in Practice, Section 3.1 for more of a discussion. My reasoning is based on the assumption that locking is simply an abstraction for the Java synchronized keyword. That assumption may or may not be 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
Re: Set performance
Did you run the test with the -server jvm option? This command line argument is usually recommended when measuring performance. -Julien On Mar 31, 10:56 am, Krukow wrote: > On Mar 29, 10:21 pm, Krukow wrote:> Hello, > [snip..] > > What was surprising to me wasn't that "inserts" are slower - that is > > ok and it could be improved with transients. The surprising thing was > > that iterating through the entire set was significantly slower. > > [snip..] > > I've dug through the source, and to answer my own question: The 10x > slowdown occurred only in the first iteration through the set. It > turns out the PersistentHashSet (and others) calls RT which caused the > clojure runtime to load costing about two seconds. Once the runtime is > loaded it is 1-4 time java.util.HashSet for iteration which is fine. > > It would be nice to have a version of the clojure data structures > which doesn't depend on the runtime. I may start extracting such a > version myself. > > /Karl -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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 To unsubscribe, reply using "remove me" as the subject.
Re: Clojure function varargs (not Java interop varargs)
Thanks Timothy. That did the trick. One small comment below. On Feb 19, 12:11 am, Timothy Pratley wrote: > On 19 February 2010 18:04, Julien wrote: > > > > > Question #1 > > > I want to write a vararg function that does something like this: > > > (map vector [1 2 3] [4 5 6]) > > which yields > > ([1 4] [2 5] [3 6]) > > > I try to capture this as a function: > > > (defn rotate[& x] (map vector x)) > > > but > > > (rotate [1 2 3] [4 5 6]) > > > yields > > > ([[1 2 3]] [[4 5 6]]) instead of ([1 4] [2 5] [3 6]) > > > What am I doing wrong? > > You want apply... > > clojure.core/apply > ([f args* argseq]) > Applies fn f to the argument list formed by prepending args to argseq. > > foo=> (defn rotate [& x] (apply map vector x)) > #'foo/rotate > foo=> (rotate [1 2 3] [4 5 6]) > ([1 4] [2 5] [3 6]) > > > > > Question #2 > > > Question #1 was somewhat of a diversion. What I actually want my > > function to look like is something like this: > > > (defn rotate[x] (map vector x)) > > > where the x passed in is a vector of vectors e.g. [[4 2 3] [ 9 8 7]] > > > so > > > (rotate [[1 2 3] [4 5 6]]) > > > would yield > > > ([1 4] [2 5] [3 6]) > > > How can I achieve this? > > same answer :) Almost the same answer: (defn rotate [x] (apply map vector x)) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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
Clojure function varargs (not Java interop varargs)
Dear Clojurists, Two questions: Question #1 I want to write a vararg function that does something like this: (map vector [1 2 3] [4 5 6]) which yields ([1 4] [2 5] [3 6]) I try to capture this as a function: (defn rotate[& x] (map vector x)) but (rotate [1 2 3] [4 5 6]) yields ([[1 2 3]] [[4 5 6]]) instead of ([1 4] [2 5] [3 6]) What am I doing wrong? Question #2 Question #1 was somewhat of a diversion. What I actually want my function to look like is something like this: (defn rotate[x] (map vector x)) where the x passed in is a vector of vectors e.g. [[4 2 3] [ 9 8 7]] so (rotate [[1 2 3] [4 5 6]]) would yield ([1 4] [2 5] [3 6]) How can I achieve this? Many thanks for this great language. -Julien -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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
Re: Clojure Conference Poll
What about colocating this conference with say OOPSLA (or ECOOP). You will probably get good attendance. On Jan 26, 1:29 pm, Michel Vollebregt wrote: > +1 for Europe > > On Jan 26, 12:22 am, mudphone wrote: > > > +1 Paris > > > On Jan 22, 11:54 pm, Konrad Hinsen wrote:> On > > 22 Jan 2010, at 22:15, Wilson MacGyver wrote: > > > > > I vote let's turn this into a clojure vacation, and hold it in an > > > > exotic location. > > > > > Otherwise, hey, Columbus Ohio is as good as any other city. :) > > > > My vote is for Paris, France :-) > > > > Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send 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
Re: java faster than clojure?(probably not)
here's a improved version of the byte-array-sound function which is probably easier to understand. based upon a real mathematical formula. (defn byte-array-sound-2 [frequency sample-rate nb-frame] (let [sample-array (make-array (. Byte TYPE) (* nb-frame 2)) sample-interval (/ 1 (double sample-rate)) limit (alength sample-array)] (loop [sample-index 0 t (double 0)] (let [sample (short (* (int Short/MAX_VALUE) (Math/sin (* (* t 2.0) (* Math/PI frequency)] (aset-byte sample-array sample-index (byte (bit-shift-right sample 8))) (aset-byte sample-array (+ sample-index 1) (byte (bit-and (int sample) (int 255) (if (< (+ sample-index 2) limit) (recur (inc (inc sample-index)) (double (+ t sample-interval))) sample-array --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: java faster than clojure?(probably not)
On May 10, 2:08 am, David Nolen wrote: > What's a sample set of values you would pass to this function? (byte-array-sound 2000 44100 10) here frequency would be the pitch of the sound generated 2000Hz, sample-rate set to 44100Hz. Thank you David, it does work faster now. I uploaded the whole code to actually play the sound. http://groups.google.com/group/clojure/web/sample.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 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 -~--~~~~--~~--~--~---
Re: java faster than clojure?(probably not)
> Out of curiosity, how long does that function take to execute in Java? The java version is much faster even with much more work to do, which put me perplex. I didn't check how much it takes, must be about 100ms. Thx for the tips, though that doesn't really improve anything. My guess is that it has something to do recursion. I set *warn-on-reflection* but doesn't give me any warning. Is there another way to do iterations in clojure? Would trying to compile the code do any good? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
java faster than clojure?(probably not)
I'm interested to do audio synthesis and eventually audio DSP on the JVM using the Java sound API and I think that it could be fun to do that following the functional programming paradigm. I don't intend to build a huge library but just to try some experiment on my own to better understand how digital audio synthesis work. Here is a piece of code that is filling up a byte array putting into it audio samples calculated from the math sin function. I'm trying to convert this java code into clojure. While the java version is almost instantaneous my clojure version is way too slow. So I figured I must be doing something wrong. It is assuming that the audio channel is mono and sample size of 16 bits. The sample rate is set to 44100Hz. -java code int EXTERNAL_BUFFER_SIZE = 128000; byte[] sampleArray = new byte[EXTERNAL_BUFFER_SIZE*20]; float frequency = 2000; // Hz double sampleInterval = frequency/sampleRate; short sample; float impulseTrain = 0; for(int sampleIndex=0;sampleIndex+1> 8); sampleArray[sampleIndex+1] = (byte) (sample & 0xFF); impulseTrain += sampleInterval; if(impulseTrain>1) impulseTrain -= 1; } -my clojure function (defn byte-array-sound [frequency sample-rate nb-frame] (let [sample-array (make-array (. Byte TYPE) (* nb-frame 2)) sample-interval (/ frequency sample-rate) limit (alength sample-array)] (loop [sample-index 0 impulse-train 0] (let [sample (short (* (Short/MAX_VALUE) (Math/sin (* impulse- train 2 (Math/PI)] (aset sample-array sample-index (byte (bit-shift-right sample 8))) (aset sample-array (+ sample-index 1) (byte (bit-and sample 255 (if (< (+ sample-index 2) limit) (recur (inc (inc sample-index)) (let [next-impl-tr (+ impulse-train sample-interval)] (if (< next-impl-tr 1) next-impl-tr (- next-impl-tr 1 sample-array With a byte array of 2 560 000 bytes the java version is very fast, may be because of some optimizations somehow not available from clojure. I tried the clojure function with a much smaller byte array of 100 000 bytes and it is very slow.(about 40 sec to return) May be clojure isn't optimize to handle primitive types as java is or I need to learn my clojure. I figured those functions out by myself so there might be another way to achieve the same thing more efficiently. My knowledge about audio synthesis, DSP is just growing. I'd appreciate any suggestions. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Interfaces : not fully implemented in clojure?
Thank you Rich for answering, I appreciate your expertise. > It's always best to post a complete example - it makes it easier for > people to help you, e.g. ";audioFormat is defined above" just leaves > me having to figure out how to make one in order to reproduce your > problem. > Use of camelCase in Clojure code is non-idiomatic - better audio- > format, source-data-line etc. That also helps make it easier to > distinguish Java-originated names from Clojure names Well sorry about that, your right i'm taking note. I'm still learning clojure, thanks for the advices and solutions. Using type hint solves the problem, but if I put the def form in a try it fails. So I assume top level def cannot occur in a try, but it's ok I don't need that anymore. -Julien --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Interfaces : not fully implemented in clojure?
Hello all,
A quick newbie question about getting hold of an object implementing
interface from the Java sound API.
The static method AudioSystem/getSourceDataLine returns an object
implementing the SourceDataLine interface.
But the returned object in clojure doesn't seem to fully implement the
interface.
(ns sample.main
(:import (javax.sound.sampled AudioFormat AudioSystem
LineUnavailableException SourceDataLine)
))
(try
(def sourceDataLine (AudioSystem/getSourceDataLine
audioFormat)) ;audioFormat is defined above
(println "sourceDataLine :" sourceDataLine)
(.open sourceDataLine audioFormat)
(catch LineUnavailableException ex
(. ex printStackTrace))
)
outputs: sourceDataLine : #
sourceDataLine resolve to a DirectSDL object, but apparently does not
fully implement the interface SourceDataLine.
-stack trace:
java.lang.IllegalArgumentException: No matching method found: open
for class com.sun.media.sound.DirectAudioDevice$DirectSDL
-here's interface SourceDataLine:
package javax.sound.sampled;
public abstract interface SourceDataLine extends DataLine
{
public abstract void open(AudioFormat paramAudioFormat, int
paramInt)
throws LineUnavailableException;
public abstract void open(AudioFormat paramAudioFormat)
throws LineUnavailableException;
public abstract int write(byte[] paramArrayOfByte, int paramInt1,
int paramInt2);
}
+ calling the open method without argument works fine
+ a java version of this code works fine
+ a write method isn't implemented either
Is this the expected clojure behavior? or what I am doing wrong?
-Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Does read-string ignore bindings local to forms?
Well thank you Christophe. I didn't know it was possible to redirect the output like this. Even got the exception working. Thank you for your expertise and your time, it works perfect, just what wanted. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Does read-string ignore bindings local to forms?
Thanks for your quick answer. On May 1, 3:53 pm, Christophe Grand wrote: > > Whate are you trying to achieve? > I'll try to clarify my problem. I'm a newcomer to clojure (enthusiast about it) and I'm working on small project to get familiar with clojure. The idea consist of making a jabber bot that would allow me to remotely execute clojure code from a jabber account(Jabber is an instant messaging protocol). It would be kind of a remote repl. This way I could set the bot running on my personal computer and could access it from school, or any computer that i don't own. So that I could experiment with the repl at school where i don't have the right to install anything on their machine. I need to access to a local binding because I must put the (eval (read- string code)) into a messageListener method. I can execute clojure code remotely over jabber but I want the bot to send me back the output of a form. And for that I think I need to refer to the chat connection instance. Here's the code so far: (ns replbot.main) (import '(org.jivesoftware.smack XMPPConnection ConnectionConfiguration SASLAuthentication MessageListener ChatManagerListener)) (def mess "Test from Clojure!!") (def connection (new org.jivesoftware.smack.XMPPConnection (new ConnectionConfiguration "jabber.org" 5222 "jabber.org"))) (defn main [] (. connection connect) (. SASLAuthentication supportSASLMechanism "PLAIN" 0) (. connection login "nakyssjabbertest" "testjabber") (.. connection (getChatManager) (addChatListener (proxy [ChatManagerListener] [] (chatCreated [chat1 created] (. chat1 addMessageListener (proxy [MessageListener] [] (processMessage [chat2 message] (do (. chat2 sendMessage "trying to...") (let [chat chat2 test001 "test001"] (binding [*ns* (the-ns 'replbot.main)] (eval (read-string (. message getBody) )) ) ) (. chat2 sendMessage "done.") ) ) ) ) ) (main) The processMessage method takes a chat argument, i need to be able to refer to it from the (eval (read-string "")) call to get a feedback. for exemple (let [chat chat2 test001 "test001"] (binding [*ns* (the-ns 'replbot.main)] ;;; getBody could be : (some code ) (def feedback (...)) (. chat sendMessage feedback) (eval (read-string (. message getBody) )) ) ) I don't fully understand the function to explicitly pass argument. Could you clarify Christophe ? Does anyone have any thought? I would appreciate. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Does read-string ignore bindings local to forms?
Here is a quick newbie question. (def test1 "test1") (let [test2 "test2"] (eval (read-string "(println test1)")) (eval (read-string "(println test2)")) ) -output test1 1:1 user=> java.lang.Exception: Unable to resolve symbol: test2 in this context (testLet.clj:0) How could (read-string "") access to a binding local to a form? Is this possible? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: testing the reader...
Thanks a lot for this thorough explanation. I appreciate it. Changing \"(println text1)\" to \"(println user/text1)\" actually do the job. I had to read it several time to begin to understand but I do have a better understanding of how compilation and namespaces work now. Thank you Stephen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: clojure-contrib build error
You can try the eclipse plug in for clojure. It is easy to install and provided with its own clojure.jar and clojure-contrib.jar. here is the link: http://code.google.com/p/clojure-dev/ you will need Eclipse though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
testing the reader...
Hi all, I'm currently working on a small project to get started with clojure. I can't solve this problem which seem to be related to the reader. So I ran some test against it. -here's the clojure code: (def text1 "testing thread") (def T (proxy [Thread] [] (run [] (println "T thread : (eval (println text1))") ;this works fine so i assume the var text1 is available from the thread (eval (println text1)) (println "T thread : (eval (read-string \"(println text1)\"))") ; this instruction seem to be causing the problem ; Unable to resolve symbol: text1 in this context (eval (read-string "(println text1)")) ))) (println "Main thread : (eval (println text1))") (eval (println text1)) (println "Main thread : (eval (read-string \"(println text1)\"))") (eval (read-string "(println text1)")) (. T start) -and the output: Clojure Main thread : (eval (println text1)) testing thread Main thread : (eval (read-string "(println text1)")) testing thread 1:1 user=> T thread : (eval (println text1)) testing thread T thread : (eval (read-string "(println text1)")) -followed by the stack trace Exception in thread "Thread-1" java.lang.Exception: Unable to resolve symbol: text1 in this context (NO_SOURCE_FILE:0) at clojure.lang.Compiler.analyze(Compiler.java:4330) at clojure.lang.Compiler.analyze(Compiler.java:4276) at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:2761) at clojure.lang.Compiler.analyzeSeq(Compiler.java:4488) at clojure.lang.Compiler.analyze(Compiler.java:4315) at clojure.lang.Compiler.analyze(Compiler.java:4276) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:3852) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:3687) at clojure.lang.Compiler$FnMethod.access$1100(Compiler.java:3564) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2953) at clojure.lang.Compiler.analyzeSeq(Compiler.java:4484) at clojure.lang.Compiler.analyze(Compiler.java:4315) at clojure.lang.Compiler.eval(Compiler.java:4520) at clojure.core$eval__3975.invoke(core.clj:1743) at user$fn__88$fn__90.invoke(testReader.clj:8) at clojure.proxy.java.lang.Thread.run(Unknown Source) Caused by: java.lang.Exception: Unable to resolve symbol: text1 in this context at clojure.lang.Compiler.resolveIn(Compiler.java:4671) at clojure.lang.Compiler.resolve(Compiler.java:4617) at clojure.lang.Compiler.analyzeSymbol(Compiler.java:4594) at clojure.lang.Compiler.analyze(Compiler.java:4297) ... 15 more So my question is would it be possible to get access to text1 in the thread using this code (eval (read-string "(println text1)"))? Is the reader really involved in this? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: clojure-contrib build error
You can try the eclipse plug in for clojure. It is easy to install and provided with its own clojure.jar and clojure-contrib.jar. here is the link: http://code.google.com/p/clojure-dev/ you will need Eclipse though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
