Re: core.matrix proposal
Mikera writes: BTW, I started my own attempt at something similar a while ago, but never found the time to get it to a usable state: https://code.google.com/p/clj-multiarray/ Konrad. Very interesting, thanks! I like the use of protocols to construct the specialised array types in particular. Would you be willing and interested to work on merging this into the core.matrix code base? I had started on a simple NDArray implementation myself but your code is clearly much further along than mine. Sure! I won't be able to work much on this over the next few weeks, but feel free to take over any code that looks good to you. See you on Numerical Clojure... 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: Numerical Clojure - discussion open!
Hi Mike, Could you please share the discussion group URL? Shantanu On Jan 11, 9:12 am, Mikera mike.r.anderson...@gmail.com wrote: Hello everybody, I've created a new discussion group Numerical Clojure for anyone interested in doing serious numerical computing in Clojure. The vision is to build a numerics capability / set of libraries in Clojure somewhat inspired by what the Python community has done with NumPy, but also building on the many natural strengths that Clojure should have in this space (e.g. the wealth of JVM libraries, symbolic metaprogramming, high level abstraction capabilities etc.) An initial focus is on creating a core.matrix API for vector / matrix maths. There's a working prototype of this on GitHub: -https://github.com/mikera/matrix-api Anyone interested in this topic, please join the group and contribute your ideas! Best regards, Mike. -- 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: Numerical Clojure - discussion open!
Why not to reuse existing Incanter group? On Fri, Jan 11, 2013 at 5:12 AM, Mikera mike.r.anderson...@gmail.com wrote: Hello everybody, I've created a new discussion group Numerical Clojure for anyone interested in doing serious numerical computing in Clojure. The vision is to build a numerics capability / set of libraries in Clojure somewhat inspired by what the Python community has done with NumPy, but also building on the many natural strengths that Clojure should have in this space (e.g. the wealth of JVM libraries, symbolic metaprogramming, high level abstraction capabilities etc.) An initial focus is on creating a core.matrix API for vector / matrix maths. There's a working prototype of this on GitHub: - https://github.com/mikera/matrix-api Anyone interested in this topic, please join the group and contribute your ideas! Best regards, Mike. -- 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 -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- 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
ANN: Clojure/West sessions
I have posted almost all of the Clojure/West sessions at http://clojurewest.org/sessions. Still missing: ** Rich Hickey's abstract - I assume he's written a browser or an operating system or something :) :) ** abstracts for the miniKanren Confo (Byrd/Friedman, David Nolen, Nada Amin, Ryan Senior, Adam Foltzer, and Gabriel Pickard will be presenting) ** abstracts about Pedestal, Relevance's new open source project. I've gotten a sneak preview and you're going to be hearing a lot more about this. Killer stuff. Registration is available at http://regonline.com/clojurewest2013 Sponsorship info is at http://clojurewest.org/sponsorship-prospectus 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
Re: Clojure web server benchmarks
This is very interesting. Have you tried running the Ring Jetty adapter with a larger thread pool? It's set lower than the default so as not to overload cloud hosts like Heroku. - James On 5 January 2013 15:52, Peter Taoussanis ptaoussa...@gmail.com wrote: Hi all, Quick post to mention that I've put up some rough benchmarks for a number of Clojure web servers: https://github.com/ptaoussanis/clojure-web-server-benchmarks. Getting semi-reliable numbers was a real PITA, and I'm sure there's still plenty of room left for improvement (suggestions welcome!). Usual disclaimers apply: the numbers vary by hardware, by OS, by concurrency, and by the response size (among other things). The servers also vary considerably in their feature sets. Not to mention that your web server is seldom going to be the bottleneck when generating dynamic content. Tl;dr: this is all very difficult to generalize: you'll need to bench in your own environment with your own workloads to get an accurate picture. Anyway I think the numbers are interesting (and pretty impressive all-round). Nginx can almost certainly be tweaked faster (ideas?), but I wouldn't have expected something like the standard Ring Jetty adapter even to be playing in the same ballpark - so that's nice. I'll try keep this updated as servers are updated. And as I've mentioned on the GitHub page, pull-requests welcome for anything I may have missed, including other servers or mis-configurations, etc. Hopefully with some tweaking we can converge on some reasonably accurate/useful common-case numbers. Cheers! -- 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
Re: How to integrate front-end designers into Clojure/Ring/Jetty workflow?
Thanks! Those are great ideas. On 10 Sty, 21:11, Sean Corfield seancorfi...@gmail.com wrote: My first thought is: don't bother compiling the code, just run it live from source (and maybe provide a way to easily reload the templates (such as a URL parameter). What I've done in my FW/1 framework (convention-based MVC, built on Ring and Enlive) is to have a mode that auto-reloads templates on every request (a development mode) or you can just specify a URL parameter to force the templates to be reloaded. If you're interested in looking at FW/1 for Clojure (it's a port of a seasoned and very popular CFML framework that I originally created back in 2009), the repo is:https://github.com/seancorfield/fw1-clj There's a FW/1 Leiningen template so it should be as simple as: * lein new fw1 myapp * cd myapp * lein run Then just edit controllers (and add a separate model if you want), edit your views, and add ?reload=secret to the URL to force a reload. For more background, the original CFML version is here:https://github.com/seancorfield/fw1with some overview information here:http://fw1.riaforge.org(including mailing list link). Sean On Thu, Jan 10, 2013 at 3:28 PM, larry google groups lawrencecloj...@gmail.com wrote: So, I am working on a web app that is buillt with Clojure/Ring/Jetty and, importantly, Enlive. My directory structure is like this: /resources /public /css /js /img /templates /src /discovery core.clj The great thing about Enlive is that the templates are pure HTML. This makes it easier for graphic designers and frontenders to work with them directly. I am working with a designer and frontend developer, who have absolute power over the stuff going into the /resources folder. I have 2 questions: 1.) In my routes, I am using (wrap-resource) instead of (wrap-file). Is there any way to enable live updates, so that if the designer changes the images in /resources/public/img, they can then see the changed images when looking at the app in their browser? Right now I have to recompile the app and restart it for change to be visible to the designer. 2.) I notice that if a change is made in /resources, but no change is made anywhere else, then if I run lein compile nothing happens. Is there a way to force lein to compile? I have little insight about how to build a multiperson workflow while doing Clojure development. One thought I had: I could automate the re- build of the app, and give the designer an easy way to trigger that rebuild (click a button in Jenkins -- easy enough because we rely on Jenkins for all of our builds, and the interface is simple enough for non-programmers to handle). But I would like to hear what other people do. -- 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 -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 user group in Budapest just launched
Hey, Delighted to announce that the Budapest Clojure Group has just launched: http://www.meetup.com/Budapest-Clojure-User-Group/ The official language is English so consider joining/attending if you're from a relatively close city but don't speak Hungarian (Bratislava Vienna come to mind). One city closer to world domination! Balint http://twitter.com/baaz -- 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 user group in Budapest just launched
Great, just sent the pull request. On Friday, January 11, 2013 at 4:03 PM, Michael Klishin wrote: 2013/1/11 Balint Erdi balint.e...@gmail.com (mailto:balint.e...@gmail.com) Delighted to announce that the Budapest Clojure Group has just launched: http://www.meetup.com/Budapest-Clojure-User-Group/ Balint, Please consider adding it to the User Groups page on http://clojure-doc.org. All it takes is a pull request on GitHub that edits [1]. 1. https://github.com/clojuredocs/cds/blob/master/articles/ecosystem/user_groups.md -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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 (mailto: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 (mailto: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
Re: ANN: Clojure/West sessions
Most of the miniKanren Confo sessions are now also included at the end (http://clojurewest.org/sessions#confo). On Friday, January 11, 2013 7:53:39 AM UTC-6, Alex Miller wrote: I have posted almost all of the Clojure/West sessions at http://clojurewest.org/sessions. Still missing: ** Rich Hickey's abstract - I assume he's written a browser or an operating system or something :) :) ** abstracts for the miniKanren Confo (Byrd/Friedman, David Nolen, Nada Amin, Ryan Senior, Adam Foltzer, and Gabriel Pickard will be presenting) ** abstracts about Pedestal, Relevance's new open source project. I've gotten a sneak preview and you're going to be hearing a lot more about this. Killer stuff. Registration is available at http://regonline.com/clojurewest2013 Sponsorship info is at http://clojurewest.org/sponsorship-prospectus 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
Full stack Clojure web/REST framework - is there any mileage in it?
I've been experimenting with Clojure web services recently, and posting the work on GitHub https://github.com/3rddog/doitnow and my bloghttp://internistic.blogspot.ca/search/label/clojure . When putting this test app together, it occurred to me that most other languages have a full-stack API available which makes life easier when it comes to making decisions about which libraries/APIs/frameworks to use. It also reduces the possibility of impedance mismatch between the libraries. For Java, you can use Spring (or any one of a dozen or more other popular frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, Ring, several logging, validation and database libraries, and they can be used together but they don't constitute a coordinated full stack - and that creates issues. For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. By the time you add logging, validation, data access, etc the odds of a mismatch between these libraries goes up dramatically. This is a concern, because these mismatches must be worked around in *my*code and are likely to break as the libraries are upgraded in future versions. So, I'm having to spend my time maintaining what are essentially patches for third-party libraries just so that they work together. Now, it may not be the best decision to try to put together a true full-stack framework from scratch, but is it worth choosing a bunch of existing frameworks and coordinating their releases - in much the same way as Eclipse coordinates plugin releases for major releases - so that putting together a full-stack app becomes easier? Projects taking part in the meta-project will work together to harmonize their functionality APIs, and coordinate their development cycles releases so that the meta-framework remains consistent and easily usable. Is this another barrier to adoption the Clojure community can remove? Is this even a barrier? Am I missing something? Thoughts? [Also posted to http://www.reddit.com/r/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
Re: Numerical Clojure - discussion open!
The url is https://groups.google.com/forum/#!forum/numerical-clojure Marek On Friday, January 11, 2013 10:41:58 AM UTC+1, Shantanu Kumar wrote: Hi Mike, Could you please share the discussion group URL? Shantanu On Jan 11, 9:12 am, Mikera mike.r.anderson...@gmail.com wrote: Hello everybody, I've created a new discussion group Numerical Clojure for anyone interested in doing serious numerical computing in Clojure. The vision is to build a numerics capability / set of libraries in Clojure somewhat inspired by what the Python community has done with NumPy, but also building on the many natural strengths that Clojure should have in this space (e.g. the wealth of JVM libraries, symbolic metaprogramming, high level abstraction capabilities etc.) An initial focus is on creating a core.matrix API for vector / matrix maths. There's a working prototype of this on GitHub: -https://github.com/mikera/matrix-api Anyone interested in this topic, please join the group and contribute your ideas! Best regards, Mike. -- 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: Full stack Clojure web/REST framework - is there any mileage in it?
On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - 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
Re: Full stack Clojure web/REST framework - is there any mileage in it?
My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - 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
Re: Full stack Clojure web/REST framework - is there any mileage in it?
I think there's a philosophical bent in the Clojure community toward small, composable libraries, rather than monolithic pre-built combinations - across all domains. This has come up in discussions before, mostly around the full-stack web framework issue, and the consensus each time seems to be we're better served by doing a mix'n'match from the available libraries. Scala is aimed much more squarely at the enterprise world of Java, which in turn is much more inclined toward the full-stack approach. FWIW, I ported my mature, popular, convention-based MVC framework FW/1 from CFML to Clojure and even tho' it's nowhere near full-stack, in the Clojure world it's already far beyond the norm of small, composable libraries, as it bundles Ring and Enlive and has its own route processing. In the CFML world, FW/1 was a reaction to the large, full-stack frameworks inspired by Spring, Rails etc, and those CFML frameworks have routing, security, DI/AOP, ORM, environment control, logging, test generation and all sorts of things built in... hundreds of files, tens of thousands of lines of code, massive documentation and so on. Even FW/1 (for CFML) has routing, some DI and environment control all built in! FW/1 for Clojure has no DI nor environment control (although that probably will get added at some point). I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) Sean On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers paul.umb...@gmail.com wrote: My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - 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 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Full stack Clojure web/REST framework - is there any mileage in it?
IMO there is little value in big dependency hair-balls and gui tools leakily abstracting devop taks. There is, however, value in curated sets of independent libriaries that work well together. Also in having declarative syntax available for common tasks. Still IMO, Clojure's web story is still somewhat lacking on those. More specifically in in environment integration, since ring does a great job for binding application components. Lately I'm trying to push all code that deals with environment and project configuration into leiningen plugins. I think together with project templates, that can be a great way to get more of the convenience of your classic framework. kind regards -- 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
clojurescript browser repl and static files
I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj, `send-static` has the cases for handling files other than .html such as css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits this and only accepts .js and .html. Any reason for this? Any chance of changing 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 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: clojurescript browser repl and static files
No reason beyond not having received a patch for it :) On Fri, Jan 11, 2013 at 2:21 PM, Brent Millare brent.mill...@gmail.comwrote: I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj, `send-static` has the cases for handling files other than .html such as css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits this and only accepts .js and .html. Any reason for this? Any chance of changing 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 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
Re: clojurescript browser repl and static files
Hmm I just realized, send-and-close doesn't quite handle the binary data case very well atm. I'd probably need to fix that first. On Friday, January 11, 2013 2:50:31 PM UTC-5, David Nolen wrote: No reason beyond not having received a patch for it :) On Fri, Jan 11, 2013 at 2:21 PM, Brent Millare brent@gmail.comjavascript: wrote: I noticed in the code in clojurescript, src/clj/cljs/repl/browser.clj, `send-static` has the cases for handling files other than .html such as css, jpg, .png etc, but the dispatching `(server/dispatch-on ...)` limits this and only accepts .js and .html. Any reason for this? Any chance of changing this? -- 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 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
Leiningen profiles for dev and prod dbs and other settings
I just read about leiningen profiles, and I'm trying to figure out how to access those settings within my code for db selection. What are the canonical ways to do 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 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: Full stack Clojure web/REST framework - is there any mileage in it?
I think a lot of the issues can be addressed via a good template which sets up all the boiler plate, demonstrates idiomatic usage, and defaults to some common libraries. I'm actively working on filling this gap with the Luminushttp://www.luminusweb.net/, which aims to make it easy to get rolling, and sets up all the basic things like sessions, static resources, packaging, etc. On Friday, January 11, 2013 11:52:05 AM UTC-5, Paul Umbers wrote: I've been experimenting with Clojure web services recently, and posting the work on GitHub https://github.com/3rddog/doitnow and my bloghttp://internistic.blogspot.ca/search/label/clojure . When putting this test app together, it occurred to me that most other languages have a full-stack API available which makes life easier when it comes to making decisions about which libraries/APIs/frameworks to use. It also reduces the possibility of impedance mismatch between the libraries. For Java, you can use Spring (or any one of a dozen or more other popular frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, Ring, several logging, validation and database libraries, and they can be used together but they don't constitute a coordinated full stack - and that creates issues. For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. By the time you add logging, validation, data access, etc the odds of a mismatch between these libraries goes up dramatically. This is a concern, because these mismatches must be worked around in *my*code and are likely to break as the libraries are upgraded in future versions. So, I'm having to spend my time maintaining what are essentially patches for third-party libraries just so that they work together. Now, it may not be the best decision to try to put together a true full-stack framework from scratch, but is it worth choosing a bunch of existing frameworks and coordinating their releases - in much the same way as Eclipse coordinates plugin releases for major releases - so that putting together a full-stack app becomes easier? Projects taking part in the meta-project will work together to harmonize their functionality APIs, and coordinate their development cycles releases so that the meta-framework remains consistent and easily usable. Is this another barrier to adoption the Clojure community can remove? Is this even a barrier? Am I missing something? Thoughts? [Also posted to http://www.reddit.com/r/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
Re: Leiningen profiles for dev and prod dbs and other settings
Perhaps this is better done with .env files? On Friday, January 11, 2013 3:49:06 PM UTC-5, Jonathon McKitrick wrote: I just read about leiningen profiles, and I'm trying to figure out how to access those settings within my code for db selection. What are the canonical ways to do 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 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: Full stack Clojure web/REST framework - is there any mileage in it?
I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) You are not alone: ORM, together with the idea of a persistent state manager is a beautifully paved road---to hell. In the prototype phase it gives the impression of an ideal solution: code looks just like it's operating on plain memory objects. What could ideally be milliseconds, ORM turns them into tenths of a second, and this doesn't get anyone worried. Then, when you have the whole project committed to ORM and start working on some really tough requirements---and only those are the ones that *truly* add value to your product, tasks that could take a tenth of a second turn into show-stopping pauses of ten seconds and more. Now, if you are using a full-stack framework like Rails, you are pretty much stuck with its ORM solution, like it or not; with Clojure's mix-and-match approach, you just find what you are more comfortable with. -- 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: Full stack Clojure web/REST framework - is there any mileage in it?
Is there a page that gives Clojure web recipes? It would be great for beginners if you could have one place that says To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs. - Eric MacAdie On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield seancorfi...@gmail.comwrote: I think there's a philosophical bent in the Clojure community toward small, composable libraries, rather than monolithic pre-built combinations - across all domains. This has come up in discussions before, mostly around the full-stack web framework issue, and the consensus each time seems to be we're better served by doing a mix'n'match from the available libraries. Scala is aimed much more squarely at the enterprise world of Java, which in turn is much more inclined toward the full-stack approach. FWIW, I ported my mature, popular, convention-based MVC framework FW/1 from CFML to Clojure and even tho' it's nowhere near full-stack, in the Clojure world it's already far beyond the norm of small, composable libraries, as it bundles Ring and Enlive and has its own route processing. In the CFML world, FW/1 was a reaction to the large, full-stack frameworks inspired by Spring, Rails etc, and those CFML frameworks have routing, security, DI/AOP, ORM, environment control, logging, test generation and all sorts of things built in... hundreds of files, tens of thousands of lines of code, massive documentation and so on. Even FW/1 (for CFML) has routing, some DI and environment control all built in! FW/1 for Clojure has no DI nor environment control (although that probably will get added at some point). I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) Sean On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers paul.umb...@gmail.com wrote: My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - 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 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert,
Re: Full stack Clojure web/REST framework - is there any mileage in it?
There's a pretty good page at herokuhttps://devcenter.heroku.com/articles/clojure-web-application. There's also this classic pagehttp://brehaut.net/blog/2011/ring_introduction: aging, but still very relevant. On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote: Is there a page that gives Clojure web recipes? It would be great for beginners if you could have one place that says To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs. - Eric MacAdie On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield seanco...@gmail.comjavascript: wrote: I think there's a philosophical bent in the Clojure community toward small, composable libraries, rather than monolithic pre-built combinations - across all domains. This has come up in discussions before, mostly around the full-stack web framework issue, and the consensus each time seems to be we're better served by doing a mix'n'match from the available libraries. Scala is aimed much more squarely at the enterprise world of Java, which in turn is much more inclined toward the full-stack approach. FWIW, I ported my mature, popular, convention-based MVC framework FW/1 from CFML to Clojure and even tho' it's nowhere near full-stack, in the Clojure world it's already far beyond the norm of small, composable libraries, as it bundles Ring and Enlive and has its own route processing. In the CFML world, FW/1 was a reaction to the large, full-stack frameworks inspired by Spring, Rails etc, and those CFML frameworks have routing, security, DI/AOP, ORM, environment control, logging, test generation and all sorts of things built in... hundreds of files, tens of thousands of lines of code, massive documentation and so on. Even FW/1 (for CFML) has routing, some DI and environment control all built in! FW/1 for Clojure has no DI nor environment control (although that probably will get added at some point). I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) Sean On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers paul@gmail.comjavascript: wrote: My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - James -- 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
Re: Full stack Clojure web/REST framework - is there any mileage in it?
Thanks for the info. I will look this over, and perhaps finally build my world-changing Clojure app. Or maybe just Hello World. - Eric MacAdie On Fri, Jan 11, 2013 at 3:58 PM, Marko Topolnik marko.topol...@gmail.comwrote: There's a pretty good page at herokuhttps://devcenter.heroku.com/articles/clojure-web-application. There's also this classic pagehttp://brehaut.net/blog/2011/ring_introduction: aging, but still very relevant. On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote: Is there a page that gives Clojure web recipes? It would be great for beginners if you could have one place that says To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs. - Eric MacAdie On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield seanco...@gmail.comwrote: I think there's a philosophical bent in the Clojure community toward small, composable libraries, rather than monolithic pre-built combinations - across all domains. This has come up in discussions before, mostly around the full-stack web framework issue, and the consensus each time seems to be we're better served by doing a mix'n'match from the available libraries. Scala is aimed much more squarely at the enterprise world of Java, which in turn is much more inclined toward the full-stack approach. FWIW, I ported my mature, popular, convention-based MVC framework FW/1 from CFML to Clojure and even tho' it's nowhere near full-stack, in the Clojure world it's already far beyond the norm of small, composable libraries, as it bundles Ring and Enlive and has its own route processing. In the CFML world, FW/1 was a reaction to the large, full-stack frameworks inspired by Spring, Rails etc, and those CFML frameworks have routing, security, DI/AOP, ORM, environment control, logging, test generation and all sorts of things built in... hundreds of files, tens of thousands of lines of code, massive documentation and so on. Even FW/1 (for CFML) has routing, some DI and environment control all built in! FW/1 for Clojure has no DI nor environment control (although that probably will get added at some point). I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) Sean On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers paul@gmail.com wrote: My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a library depends on version 1.0, you know it will work with version 1.1, 1.2, and so forth. Only major versions, such as a leap from 1.5 to 2.0, have breaking changes. - James -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this
Re: Full stack Clojure web/REST framework - is there any mileage in it?
On Friday, 11 January 2013 12:17:35 UTC-7, Herwig Hochleitner wrote: There is, however, value in curated sets of independent libriaries that work well together. Also in having declarative syntax available for common tasks. Still IMO, Clojure's web story is still somewhat lacking on those. More specifically in in environment integration, since ring does a great job for binding application components. I would have to agree with this, because it's exactly the kind of thing I was thinking of in the original post. Eclipse is made up of a core application and a large set of plugins. While the individual plugin developers are free to develop as they see fit, they have all chosen to join together to produce at least one stable, consistent release per year where everything just works together nicely (well, OK, maybe not so nicely with Juno). I know the Clojure philosophy is, as Sean mentioned above, to build from small composable libraries, but to foster increased adoption in enterprise environments there's something to be said for a quick, easy start. I think maybe a combination approach of curated library versions (that work well together) and a comprehensive set of templates would go a long way towards easing adoption. I get the feeling we're almost there with Leiningen templates and the more mature libraries (like Compojure/Ring), and it would just take some buy-in and coordinated effort making it happen. -- 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: ANN: bouncer, validation library for clojure
Leonardo Borges www.leonardoborges.com On Jan 11, 2013 3:44 PM, faenvie fanny.aen...@gmx.de wrote: i took a look at it. bouncers DSL seems smart inside and out. Has an excellent Documentation too. Thanks for sharing 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 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: Full stack Clojure web/REST framework - is there any mileage in it?
Though the Clojure community has traditionally gone with smaller libraries rather than large frameworks, there is a full-stack web framework for Clojure called Conjure: https://github.com/macourtney/Conjure On Friday, January 11, 2013 11:52:05 AM UTC-5, Paul Umbers wrote: I've been experimenting with Clojure web services recently, and posting the work on GitHub https://github.com/3rddog/doitnow and my bloghttp://internistic.blogspot.ca/search/label/clojure . When putting this test app together, it occurred to me that most other languages have a full-stack API available which makes life easier when it comes to making decisions about which libraries/APIs/frameworks to use. It also reduces the possibility of impedance mismatch between the libraries. For Java, you can use Spring (or any one of a dozen or more other popular frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, Ring, several logging, validation and database libraries, and they can be used together but they don't constitute a coordinated full stack - and that creates issues. For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. By the time you add logging, validation, data access, etc the odds of a mismatch between these libraries goes up dramatically. This is a concern, because these mismatches must be worked around in *my*code and are likely to break as the libraries are upgraded in future versions. So, I'm having to spend my time maintaining what are essentially patches for third-party libraries just so that they work together. Now, it may not be the best decision to try to put together a true full-stack framework from scratch, but is it worth choosing a bunch of existing frameworks and coordinating their releases - in much the same way as Eclipse coordinates plugin releases for major releases - so that putting together a full-stack app becomes easier? Projects taking part in the meta-project will work together to harmonize their functionality APIs, and coordinate their development cycles releases so that the meta-framework remains consistent and easily usable. Is this another barrier to adoption the Clojure community can remove? Is this even a barrier? Am I missing something? Thoughts? [Also posted to http://www.reddit.com/r/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
Re: Full stack Clojure web/REST framework - is there any mileage in it?
You could just do: lein new fw1 myapp cd myapp lein run assuming you have nothing running on port 8080 already - otherwise: PORT=8123 lein run Noir also has a simple Leiningen template (although Noir is deprecated now): lein new noir noirapp cd noirapp lein run (same caveat applies regarding ports) On Fri, Jan 11, 2013 at 2:56 PM, Eric MacAdie emaca...@gmail.com wrote: Thanks for the info. I will look this over, and perhaps finally build my world-changing Clojure app. Or maybe just Hello World. - Eric MacAdie On Fri, Jan 11, 2013 at 3:58 PM, Marko Topolnik marko.topol...@gmail.com wrote: There's a pretty good page at heroku. There's also this classic page: aging, but still very relevant. On Friday, January 11, 2013 10:33:15 PM UTC+1, Eric MacAdie wrote: Is there a page that gives Clojure web recipes? It would be great for beginners if you could have one place that says To make a web app, you need X, Y and Z, and here are libraries that fulfil each of these needs. - Eric MacAdie On Fri, Jan 11, 2013 at 12:25 PM, Sean Corfield seanco...@gmail.com wrote: I think there's a philosophical bent in the Clojure community toward small, composable libraries, rather than monolithic pre-built combinations - across all domains. This has come up in discussions before, mostly around the full-stack web framework issue, and the consensus each time seems to be we're better served by doing a mix'n'match from the available libraries. Scala is aimed much more squarely at the enterprise world of Java, which in turn is much more inclined toward the full-stack approach. FWIW, I ported my mature, popular, convention-based MVC framework FW/1 from CFML to Clojure and even tho' it's nowhere near full-stack, in the Clojure world it's already far beyond the norm of small, composable libraries, as it bundles Ring and Enlive and has its own route processing. In the CFML world, FW/1 was a reaction to the large, full-stack frameworks inspired by Spring, Rails etc, and those CFML frameworks have routing, security, DI/AOP, ORM, environment control, logging, test generation and all sorts of things built in... hundreds of files, tens of thousands of lines of code, massive documentation and so on. Even FW/1 (for CFML) has routing, some DI and environment control all built in! FW/1 for Clojure has no DI nor environment control (although that probably will get added at some point). I'm somewhat allergic to ORM, favoring thin, simple data mappers instead :) Sean On Fri, Jan 11, 2013 at 10:08 AM, Paul Umbers paul@gmail.com wrote: My oopsie. You're right, it is 1.2.0. I was looking at the current head of master, which I guess is 1.2.0-SNAPSHOT. As long as all projects stick to semantic versioning (a lot do), that problem is not so great. The other problem though is that of which libraries to choose for a particular function. I understand the choice is pretty wide, and that's a good thing to some extent, but it means anyone new to Clojure has to evaluate and choose almost every library they could use - which takes time effort. If I want to build a web app/service with Java I know I can just go to Spring and it will have pretty much everything I need - tested compatible. The choice almost becomes a no-brainer. I don't have that same ease of use with Clojure - if someone asked me to build a web app or service now (commercially, so I'm on the Client's clock) I would have to factor in a significant amount of time to choose, test evaluate frameworks. I guess that kind of ease-of-use comes from maturity, and Clojure is still relatively immature compared with Java. But then Scala is roughly the same age and they have TypeSafe which, as a full-stack, has a more certain feel to it than having to cherry-pick individual Clojure libraries (albeit those that have become de facto standards). Still, clients pay me to know this stuff, and that was one of the reasons for doing the project - to learn what works, what doesn't and how to go about it. On Friday, 11 January 2013 10:12:43 UTC-7, James Reeves wrote: On Friday, January 11, 2013 4:52:05 PM UTC, Paul Umbers wrote: For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. Ring 1.1.6 doesn't have any new functions - it's just a patch release. You're thinking of Ring 1.2.0-SNAPSHOT, which should be released within the next month, and will go into beta soon. Both Ring and Compojure use semantic versioning (http://semver.org/), so Ring 1.2.0 is backward compatible with Ring 1.1.0. This means that you can quite happily use Compojure 1.1.3 with Ring 1.2.0-SNAPSHOT if you so desire. Semantic versioning solves a lot of the problems you describe, because if a
Re: Full stack Clojure web/REST framework - is there any mileage in it?
A good thought/discussion provoking post, thanks. I find myself between two camps here. On one side and coming from the position of both learning Clojure and coming back to web development after a long period of mainly working on large backend database apps, the suggestion of a nicely bundled and complete clojure web framework is appealing. On the other hand, having been required to become familiar with some frameworks, such as spring, being forced to search through large quantities of documentation and then finding 80% of what it offered was not relevant to what I needed for my application, I'm far less enthusiastic regarding complete frameworks. I think there may be two different requirements here which need addressing. The first is for those, often new to clojure, who would like to get up and running fast. They have a new idea to start developing and don't want to spend hours evaluating lots of different, but outwardly similar libraries - especially as they may not yet have the knowledge to easily make such decisions. The second requirement is for more experienced or knowledgable devs or those who have a well defined design who just need to know which specific libraries to use. I suspect that as you gain web dev experience with clojure, you will move more twards the second group. If this is the case, complete frameworks are likely to be of only limited benefit while you become familiar and experienced. This may asiist adoption to some degree. However, as individuals become more experenced and accustomed to a more clojure style philosophy of fewer and more specific libraries for a task, they will likely move away from the framework. Unfortunately, this may have a detremental impact on the maintenance of such a framework as it may be difficult to attract or retain interest as experience grows. I think possibly the best way to assist adoption and also provide valuable content for more experienced developers are things like case studies, examples and reviews which cover the various libraries and their use. Example dependency templates etc may also be useful. Blogs such as yours, where you document your experiences and give examples are very valuable. Articles like the hooroku one or Andrew Brehaut's one are extremely useful and valuable. Possibly what would be very valuable would be one consolidated place where all this valuable information could be found. Someone interested in clojure and web development could just go to a single place and find a majority of the good articles, case studies, overviews and evaluation of web dev relevant libraries and techniques/idioms for Clojure. Ideally, this would just be part of another well know Clojure documentation site. Tim On Saturday, January 12, 2013 3:52:05 AM UTC+11, Paul Umbers wrote: I've been experimenting with Clojure web services recently, and posting the work on GitHub https://github.com/3rddog/doitnow and my bloghttp://internistic.blogspot.ca/search/label/clojure . When putting this test app together, it occurred to me that most other languages have a full-stack API available which makes life easier when it comes to making decisions about which libraries/APIs/frameworks to use. It also reduces the possibility of impedance mismatch between the libraries. For Java, you can use Spring (or any one of a dozen or more other popular frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, Ring, several logging, validation and database libraries, and they can be used together but they don't constitute a coordinated full stack - and that creates issues. For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and not the latest version of Ring (1.1.6) which has significantly better util functions available - but I can't use them until Compojure catches up. By the time you add logging, validation, data access, etc the odds of a mismatch between these libraries goes up dramatically. This is a concern, because these mismatches must be worked around in *my*code and are likely to break as the libraries are upgraded in future versions. So, I'm having to spend my time maintaining what are essentially patches for third-party libraries just so that they work together. Now, it may not be the best decision to try to put together a true full-stack framework from scratch, but is it worth choosing a bunch of existing frameworks and coordinating their releases - in much the same way as Eclipse coordinates plugin releases for major releases - so that putting together a full-stack app becomes easier? Projects taking part in the meta-project will work together to harmonize their functionality APIs, and coordinate their development cycles releases so that the meta-framework remains consistent and easily usable. Is this another barrier to adoption the Clojure community can remove? Is this even a barrier? Am I missing something? Thoughts?
ANN: fipp - Fast Idiomatic Pretty-Printer
Hi all, I decided to create a new pretty printer in the spirit of Data All The Things! And it's fast too! Fipp, the Fast Idiomatic Pretty-Printer for Clojure, is a pretty printer with linear runtime and bounded space requirements. Unlike clojure.pprint's side-effectual API, Fipp is configured by pretty print documents that are similar to Hiccup HTML templates. It's based on some fancy pants research pretty printers from the Haskell world. You can see my implementation and lots more notes at https://github.com/brandonbloom/fipp Let me know what you guys think. Cheers, Brandon -- 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: Leiningen profiles for dev and prod dbs and other settings
Jonathon McKitrick writes: I just read about leiningen profiles, and I'm trying to figure out how to access those settings within my code for db selection. What are the canonical ways to do this? Two ways: one is to use .clj data files on the classpath and take advantage of the fact that different profiles put different resources directories on the classpath. This is the approach taken by Carica (https://github.com/sonian/carica) and works great if you have complex config with nested values. The other approach is to use environment variables; the best tool for that is Environ: https://github.com/weavejester/environ -Phil pgp6PTnriGgt5.pgp Description: PGP signature
Re: Clojure web server benchmarks
This is very interesting. Have you tried running the Ring Jetty adapter with a larger thread pool? It's set lower than the default so as not to overload cloud hosts like Heroku. You mean the :max-threads? No, I left it at the default (50, if I recall correctly?). I'll try bump it next time I run the benchmarks (probably next week). I'm just on a dual core though, so I wouldn't expect any major changes. As it is, I think the standard Jetty adapter performs remarkably well. -- 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: How to integrate front-end designers into Clojure/Ring/Jetty workflow?
Another tip, I have extracted the support for nesting html templates using enlive from http://clojurescriptone.com. What that gives you is the support for sandboxing all the templates under a given url i.e templates/* so that the designers can work with HTML-only but in a DRY fashion. What I mean by that is that you don't have to repeat including resources like CSS, scripts, headers/footers etc. in all your templates. It's a ring middleware: https://github.com/ebaxt/enlive-partials kl. 00:28:02 UTC+1 fredag 11. januar 2013 skrev larry google groups følgende: So, I am working on a web app that is buillt with Clojure/Ring/Jetty and, importantly, Enlive. My directory structure is like this: /resources /public /css /js /img /templates /src /discovery core.clj The great thing about Enlive is that the templates are pure HTML. This makes it easier for graphic designers and frontenders to work with them directly. I am working with a designer and frontend developer, who have absolute power over the stuff going into the /resources folder. I have 2 questions: 1.) In my routes, I am using (wrap-resource) instead of (wrap-file). Is there any way to enable live updates, so that if the designer changes the images in /resources/public/img, they can then see the changed images when looking at the app in their browser? Right now I have to recompile the app and restart it for change to be visible to the designer. 2.) I notice that if a change is made in /resources, but no change is made anywhere else, then if I run lein compile nothing happens. Is there a way to force lein to compile? I have little insight about how to build a multiperson workflow while doing Clojure development. One thought I had: I could automate the re- build of the app, and give the designer an easy way to trigger that rebuild (click a button in Jenkins -- easy enough because we rely on Jenkins for all of our builds, and the interface is simple enough for non-programmers to handle). But I would like to hear what other people do. -- 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
