Re: using core.async results in page getting replaced with empty iframe
Could you also run lein deps :tree and paste the output to the thread. It could be that one of your dependencies is already depending on core.async transitively, and the explicit inclusion of a different version of core.async causes that to break. This is a long shot but it could help. On 20 August 2015 at 10:22, Colin Yates colin.ya...@gmail.com wrote: Daniel, is the UI constructed based on receiving something from a channel? which is incorrectly setup and so the UI is 'blocked' pulling from that channel. Timothy Baldridge writes: core.async has nothing to do with the DOM, so I don't know how this could happen. On Wed, Aug 19, 2015 at 3:00 PM, Malcolm Sparks malc...@juxt.pro wrote: Would you mind pasting the rest of your dependencies? This is the most curious of puzzles and I'd love to know the answer - but I'm really stumped so please provide the next clue! On Wednesday, 19 August 2015 19:32:22 UTC+1, Daniel Higginbotham wrote: I've found that using core.async in one of my projects results in the entire DOM getting replaced with an empty iframe when I view the site in Firefox. I'm using [org.clojure/clojure 1.7.0] [org.clojure/clojurescript 1.7.48] [org.clojure/core.async0.1.346.0-17112a-alpha] I've tried to isolate the problem and am unable to reproduce it in a minimal project using only core.async. However - has anyone else run into anything similar? Does core.async use iframes somehow? Any other suggestions or leads? Thanks! Daniel -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- Sent with my mu4e -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/kgLcFpTnxL4/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: when the body of the request is HttpInputOverHTTP, how do I get the string representation?
If I were you, I would reach into my toolbox for https://github.com/ztellman/byte-streams - worth a try On Wednesday, 19 August 2015 20:57:57 UTC+1, Lawrence Krubner wrote: I know this has been asked before, but Google is interpreting HttpInputOverHTTP as Http Input Over HTTP which renders it useless for finding conversations that are specific to the HttpInputOverHTTP class. (off topic: I wish there was a good search engine for software terms). I've a simple web app using Jetty and Ring and Compojure. The body of each request that comes in is: :body #HttpInputOverHTTP HttpInputOverHTTP@3aa0a4ac If I do: (str (:body request)) I simply get: HttpInputOverHTTP@3aa0a4ac Can someone remind how I get a string representation of what should be in the body? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: using core.async results in page getting replaced with empty iframe
Would you mind pasting the rest of your dependencies? This is the most curious of puzzles and I'd love to know the answer - but I'm really stumped so please provide the next clue! On Wednesday, 19 August 2015 19:32:22 UTC+1, Daniel Higginbotham wrote: I've found that using core.async in one of my projects results in the entire DOM getting replaced with an empty iframe when I view the site in Firefox. I'm using [org.clojure/clojure 1.7.0] [org.clojure/clojurescript 1.7.48] [org.clojure/core.async0.1.346.0-17112a-alpha] I've tried to isolate the problem and am unable to reproduce it in a minimal project using only core.async. However - has anyone else run into anything similar? Does core.async use iframes somehow? Any other suggestions or leads? Thanks! Daniel -- 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] iota - Infix operators for test assertions
I've been writing quite a lot of tests recently, with clojure.test
I wrote a little macro to help.
It means you could replace this :
(require '[clojure.test :refer :all]
'[schema.core :as s])
(deftest my-test
(let [response ...]
(is (= (:status response) 200))
(is (= (count (get-in response [:headers content-length])) (count Hello
World!)))
(is (= (count (get-in response [:headers content-type]))
text/plain;charset=utf-8))
(is (nil? (s/check s/Str (get-in response [:headers content-type]
(is (instance? java.nio.ByteBuffer response))
))
, with this :
(require '[clojure.test :refer :all]
'[schema.core :as s]
'[juxt.iota :refer [given]])
(deftest my-test
(given response
:status := 200
:headers :⊃ {content-length (count Hello World!)
content-type text/plain;charset=utf-8}
[:headers content-type] :- s/Str
:body :instanceof java.nio.ByteBuffer))
, using various infix operators :
:=is equal to:!=isn't equal to:-conforms to schema:!-doesn't conform to
schema:?satifies predicate:!?doesn't satisfy predicate:#matches regex:!#doesn't
match regex: or :⊃is superset of:! or :⊅isn't superset of: or :⊂is
subset of:! or :⊄isn't subset of:instanceofis instance of:!instanceofisn't
instance of
It's hardly ground-breaking, but feel free to use it if you like.
https://github.com/juxt/iota
Regards,
Malcolm
--
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] bidi 1.20.0 - with Schema suppport
Hi Dylan, Yes, that's right. This is validation for the bidi route structure itself. For now, I've left it open to the bidi user whether and when to use route validation (although I may add it to modular in due course as you point out) Libraries that use ring-swagger, https://github.com/metosin/ring-swagger, including yada, provide path parameter validation. Therefore I don't think it's necessary to add path parameter validation to bidi. Regards, Malcolm On Tuesday, 30 June 2015 04:50:06 UTC+1, Dylan Butman wrote: Hey Malcolm, Just confirming my understand, the schema addition is to validate the bidi routes themselves, not path parameters matched within the routes, right? Is this something you're thinking one might do at component start, say https://github.com/juxt/modular/blob/master/modules/bidi/src/modular/bidi.clj#L88 . Best Dylan On Monday, June 29, 2015 at 11:47:00 AM UTC-4, Malcolm Sparks wrote: bidi is a routing library that lets you define the URI routes for your website as data. Until now, there has been no way to validate whether that data conforms to the expected structure. Not doing so can often lead to problems. I've just released a new version that defines a Prismatic Schema for letting you check and validate your bidi routes in your code. Schema validation works for both Clojure and ClojureScript, now that ClojureScript has Var instances (see https://groups.google.com/forum/#!topic/prismatic-plumbing/jqOkv_r8QZk) See http://github.com/juxt/bidi for further details. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing REST api the right way
yada exploits aleph's async model of returning futures and leverages manifold's ability to chain together futures and promises. This means you can effectively use a Java synchronous API by wrapping it in a future, or exploit an asynchronous Java API by returning a promise which is delivered in the callback. This programming model will give you a lot of options on the JVM. I'm sorry that yada is still in alpha, but I've been working hard on it recently and taking on the feedback of a number of early adopters. I hope to get to beta in a matter of weeks. HTTP is a big feature set and rushing things will lead to migration churn later on. On Thursday, 25 June 2015 21:20:05 UTC+1, Mike Grabowski wrote: Yeah, looks interesting, but unfortunately still in alpha, so I can't profit from it at this stage. But will check later! Thank you all for your responses! It's been really great source of new ideas and thoughts about API benchmarking and blocking/non-blocking approaches :) On Thursday, 25 June 2015 16:45:45 UTC+2, Dylan Butman wrote: Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] bidi 1.20.0 - with Schema suppport
bidi is a routing library that lets you define the URI routes for your website as data. Until now, there has been no way to validate whether that data conforms to the expected structure. Not doing so can often lead to problems. I've just released a new version that defines a Prismatic Schema for letting you check and validate your bidi routes in your code. Schema validation works for both Clojure and ClojureScript, now that ClojureScript has Var instances (see https://groups.google.com/forum/#!topic/prismatic-plumbing/jqOkv_r8QZk) See http://github.com/juxt/bidi for further details. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] yada 0.4.0 - async REST web library
yada is a library for creating RESTful Ring handlers, similar(ish) to
Liberator. The main difference is that yada fully supports async operation
(provided by Zach Tellman's manifold library). It is a kind of reactive
Clojure-based response to Java's ratpack.io or Scala's spray.io.
yada is designed to be sufficiently terse to be used for both RESTful web
APIs and content. For example, here's how to create a Ring handler
providing HTML5 server-sent-events via a core.async channel :-
(yada {:body (chan)})
yada is designed to complement bidi (a uri routing library). While both are
separate libraries, yada's resource-maps combine with bidi's routes to
define a full web API (providing sufficient information to publish a
Swagger 2.0 specification if required).
Naturally yada is new, still alpha-status and under active development. I
wanted to let folks know about it and would be grateful for any
help/feedback prior to any beta release.
MIT licensed. Further information can be found in the docs which can be
found both in the git repo (https://github.com/juxt/yada) and self-hosted
at http://yada.juxt.pro
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Clojure needs a web framework with more momentum
How do we effectively leverage some of the more advanced Clojure-oriented webservers such as Aleph and Immutant? I've just posted about yada on another thread, a library for 'proper' handling of Ring requests, fully supporting async. Although yada is a separate library, it fully complements bidi (a url routing library). There are a couple more complementary libraries on the way which will combine to form something akin to a 'web framework' discussed on this thread. Regards, Malcolm On Sunday, 3 May 2015 04:19:19 UTC+1, puzzler wrote: Last week, at the Clojure/West conference, someone (I think it was Brandon Bloom) summed up the general vibe well, by saying something along the lines of, We now have all the pieces in place to make web development an order of magnitude more productive than in any other language, we just need to figure out how to put it all together and make that happen. I think that's right. From a technological standpoint, I think we're there. The things we most need are informational resources and higher-level shared resources, such as UI widgets. For example: How do we use Buddy/Friend effectively to achieve secure web apps? (The docs are not sufficiently informative for those who haven't thought much about security and assume too much prior knowledge). How do we effectively leverage some of the more advanced Clojure-oriented webservers such as Aleph and Immutant? Clojure is great for creating new, disruptive web models, but what's the easiest path to creating something that can be done trivially with, say, Drupal or Django? Since more and more people are working with Reagent/Om/etc., we need as many Bootstrap-like widgets as possible for those tools, and more informational resources about how to use these new reactive models effectively, for example, how to do animated UIs. Are there reusable components like, say, shopping baskets? -- 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: Minimum Viable Database Component
I think it can be a dangerous road trying to create abstractions over data sources. It can be a lot of work maintaining a stub/mock implementation to work alongside a database, and sometimes it's not that much more work (or less work) to install Postgres, SQLite, or whatever you're using, locally. One of the pain points of working with databases is managing their state, and this is one of the reasons why stub/mock implementations initially look attractive. However, there are solid alternative approaches to making the job of managing databases a lot easier. For example, https://github.com/juxt/joplin is a good choice for managing database schema migrations, seeding databases with state (for test setups) and has a good range of supported data sources. (Disclosure: I work for juxt) On Thursday, April 30, 2015 at 4:54:38 AM UTC+1, Andy Chambers wrote: Hi All, I'm trying to follow the component architecture for an app I'm working on and wondered if I was missing something. In the Just enough structure talk, one of the examples Stuart presents is a DB component that contains just a small selection of DB related functions (i.e. insert, and query IIRC) so that when you need to mock it out for your tests, you don't have to implement the entire JDBC interface. This makes sense but I'm wondering if anyone has released such a subset (possibly expanded to include things like transactions, and maybe a few utility query builders) as open source ideally with a corresponding mock implementation. With the popularity of the component library, I'm surprised not to find ready made components I can just plug into my app. If there's nothing like this already, then I guess I have an idea for a new project. Anyone think this is a good idea or would everyone's ideal DB component look a little different? Look forward to hearing your thoughts. Cheers, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
Author of bidi here. In his blog article, REST Litmus Test for Web Frameworks - https://www.innoq.com/blog/st/2010/07/rest-litmus-test-for-web-frameworks/ - Stefan Tilkov asks of REST libraries: Is there an easy way to produce links that point back resources identified by whatever means the framework exposes (such as some form of routing)? The idea of bidi came out of a discussion I had with Philipp Meier about Liberator's support for hyperlinks, to meet Stefan's litmus test. Philipp argued that while he felt Liberator should remain independent of the URI routing layer, any routing layer that was part of a proper REST API should make it easy, and reliable, to produce hyperlinks. Now that REST APIs are a mission-critical part of many websites, I believe that producing reliable working hyperlinks is too important to be left to *ad-hoc* string concatenation, however disciplined. If the community are to standardise on a routing library, I feel it should be one that support isomorphism (as Pedestal, bidi and Silk do) The design of bidi was heavily influenced by my experiences with Pedestal routing, which demonstrated the value of a data structure over macros. Unfortunately, I felt that Pedestal's integration of routing with its interceptor definitions meant that you couldn't extract an independent routing library from it. I also didn't really like the terse versus expanded format, and wanted bidi to have a single format, one that would strike the balance between being easy to write by hand and easy to generate. I'm still a fan of Pedestal but wish it had been offered from the beginning as a set of independent libraries which worked well together. 'All or nothing' is never a great choice. Silk was heavily influenced by bidi, as Dom has described earlier in this thread, and if you compare their source code they are very similar. Now that bidi supports ClojureScript, the key difference is in syntax and the fact that bidi routing is hierarchical, whereas Silk allows you to dispatch at a number of levels, as far as I can tell. The syntax differences are such that you could probably create some records and record constructors, satisfying the bidi protocols, that allowed you to layer Silk's syntax over bidi, a sort of 'silk-flavored-bidi' if you will. The hierarchical design of bidi was driven by the desire to support modularity- when you have multiple people or teams working on different parts of a website, it helps to be able to 'remount' one of the parts without anything breaking. Also, bidi excludes support for dispatching on differences in query parameters, as I believe that query parameters shouldn't, by definition, determine which resource is identified by the URI. Opinionated? Maybe! Until recently, the way that you did isomorphism in bidi was to use a handler as an argument to path-for, which would return the route. That required URI-forming code (like views) to have access to all the handlers in the system - not great. I played around with using keywords, with some funky record injection in the route structure to convert them to handlers during dispatch, but then I looked at Secretary's 'named routes' and slapped myself very hard on the forehead (doh!). Since then, bidi has a 'tag' function that you use to tag a handler with a keyword, from then on you can use that keyword when forming routes instead of the handler itself. bidi will undergo some rework when the new reader conditionals of Clojure 1.7 arrive out of beta, which I expect will replace its use of cljx. Otherwise, bidi itself is going to remain fairly stable. It is relied on by many production websites, such as https://www.onthemarket.com/, so can't change radically. However, building on protocols opens up numerous ways of extending bidi. For example, we're working on a new REST library (http://yada.juxt.pro) which combines bidi routing structures with resource maps to generate published Swagger definitions. This is achieved by adding a couple of new small records which satisfy bidi's protocols, demonstrating the endless flexibility of Clojure's protocols feature. So I'd hope that a 'standard' routing library would be built on protocols too. So, in summary, I think it would be useful to have a single 'default' routing library in Clojure that supported isomorphism and was built on protocols, as a minimum. Now that Clojure is attracting so many new users, it would be great to discuss the outstanding differences between all the routing libraries and try to drive some consensus as to what a combined library would include. On Saturday, April 11, 2015 at 1:08:30 AM UTC+1, Daniel Jomphe wrote: This thread over Silk, Bidi and Secretary has been very interesting. I looked at the three projects to see how they evolved after this thread started. Any cross-pollination or progress worth sharing now that I've missed? From what I could gather: * Secretary is evolving
Re: core.async: Deprecated - this function will be removed. Use transducer instead
You're right - thanks for that! I've updated the blog article to remove it. On 19 February 2015 at 17:37, Ben Smith-Mannschott bsmith.o...@gmail.com wrote: I'm unclear on one thing: what's the purpose of core.async/pipe? In your blog article, you write: (- source (pipe (chan)) payload-decoder payload-json-decoder) (pipe source destination) just copies elements from source to destination. How is that any different than just using source here directly?: (- source payload-decoder payload-json-decoder) What have I missed? // Ben On Thu, Feb 19, 2015 at 3:06 AM, Malcolm Sparks malc...@juxt.pro wrote: I have recently written a blog article which explains how to use transducers with core.async. You can find it here: http://malcolmsparks.com/posts/transducers.html On Wednesday, 18 February 2015 21:48:05 UTC, bsmith.occs wrote: I'm probably just especially dense today, but perhaps someone can give me a poke in the right direction. I'm trying to wrap my head around transducers. (1) For debugging purposes I'd like to be able to consume the values on a channel and put them in a collection to be printed. I'm doing this at the REPL: (async/!! (async/into [] channel)) This seems needlessly clunky. Is this really the best way to accomplish this? (2) async/map is deprecated, what's the alternative, exactly? (let [ch (async/to-chan [1 2 3])] (async/map inc ch)) AFAICT this would produce a channel, which when consumed would yield the values 2 3 4, correct? Now I suppose if I didn't already have the channel ch, I could create one with an associated transformation function, and then stuff the values 1 2 3 into it somehow, right? (let [ch (async/chan nil (map inc))] (async/onto-chan ch [1 2 3]) ch) ;; returns a channel yielding items 2, 3, 4 But, I'm not clear at all how I can apply the operation (inc) to the all values yielded by a channel I already have in my hand. Any help would be appreciated. I feel like I'm missing some critical bit of insight and that async and transducers might just fall into place for me if I could only find out what that bit is. // Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/z1B-42npgaI/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: core.async: Deprecated - this function will be removed. Use transducer instead
I have recently written a blog article which explains how to use transducers with core.async. You can find it here: http://malcolmsparks.com/posts/transducers.html On Wednesday, 18 February 2015 21:48:05 UTC, bsmith.occs wrote: I'm probably just especially dense today, but perhaps someone can give me a poke in the right direction. I'm trying to wrap my head around transducers. (1) For debugging purposes I'd like to be able to consume the values on a channel and put them in a collection to be printed. I'm doing this at the REPL: (async/!! (async/into [] channel)) This seems needlessly clunky. Is this really the best way to accomplish this? (2) async/map is deprecated, what's the alternative, exactly? (let [ch (async/to-chan [1 2 3])] (async/map inc ch)) AFAICT this would produce a channel, which when consumed would yield the values 2 3 4, correct? Now I suppose if I didn't already have the channel ch, I could create one with an associated transformation function, and then stuff the values 1 2 3 into it somehow, right? (let [ch (async/chan nil (map inc))] (async/onto-chan ch [1 2 3]) ch) ;; returns a channel yielding items 2, 3, 4 But, I'm not clear at all how I can apply the operation (inc) to the all values yielded by a channel I already have in my hand. Any help would be appreciated. I feel like I'm missing some critical bit of insight and that async and transducers might just fall into place for me if I could only find out what that bit is. // Ben -- 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] clean-blog @ modularity.org
I've added a blog-site template called 'clean-blog' to the collection at http://modularity.org - documented here: http://modularity.org/templates/clean-blog.html clean-blog is intended as a live site, rather than a static site generator like Cryogen: https://github.com/cryogen-project/cryogen , although it does have a site-generation option via lein gen. It could be that you want to add a blog section to an existing website, and clean-blog provides those modules. But mostly it's another demonstration of a working project using Stuart Sierra's component library, showing how to compose applications from components, bespoke and pre-existing ones. If you want to build your own blog-site in Clojure, and have ideas for custom features you might want to add, clean-blog might give you the jump-start you need. You can see an example of clean-blog (which I'm using to run my own blog) at http://malcolmsparks.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] dformat 0.1.0
Very nice! On Monday, 12 January 2015 21:43:08 UTC, zirkonit wrote: A tiny library, my first open-source Clojure release. Removes some head-scratching when formatting dates (is it or ? or YYY?) by building date format strings automatically based on a sample. For example: (dformat date March 1, 1999) ;; June 9, 2011 (dformat date Jan 1, 1999) ;; Jun 9, 2011 (dformat date Jan 01) ;; Jun 09 (dformat date Sunday, May 1, 2000) ;; Thursday, June 9, 2011 (dformat date Sun Aug 5) ;; Thu Jun 9 (dformat date 12/31/99);; 06/09/11 (dformat date DOB: 12/31/2000) ;; DOB: 06/09/2011 (dformat date March 15, 1999) ;; June 09, 2011 https://github.com/zirkonit/dformat All comments are welcome! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: equivalent of Compojure resources in juxt/bidi
Hi Clifford,
First, br/resource-maybe can only appear as the second item of a route
pair, because it only satisfies the bidi.bidi/Matched protocol. The first
item of a route pair is for patterns only, i.e. types that satisfy
bidi.bidi/Pattern protocol.
What you are trying to do is easy (when you know how).
Let's assume you have a file in your project resources/public/foo.txt such
that
(io/resource public/foo.txt)
returns non-nil
Your route structure could look like this :-
(def routes
[ [
[/index.html :index]
[ (br/resources {:prefix public})]
]])
Note here I'm using a *vector-of-vectors* syntax, which I recommend when
you have ambiguous patterns because the order in which the patterns should
be tried is made explicit. (You can use maps, but I suggest using the more
verbose vector-of-vectors syntax in cases such as this)
(bidi/match-route routes /index.html) = {:handler :index}
as we should expect.
(bidi/match-route routes /foo.txt)
will try fail the /index.html pattern, and try the pattern with a
remainder of /foo.txt. The prefix of public is then preprending,
resulting in the string public/foo.txt, which is passed to io/resource -
and we get a hit.
The difference between resources and resources-maybe, is that resources
will always return a handler - if the resource doesn't exist the handler
will return {:status 404} - no other patterns will be tried. If you use
resources-maybe, then a nil is returned if there is no matching resource,
and any remaining patterns are then tried.
I hope this helps - let me know if you need more help.
Regards,
Malcolm
On Monday, 12 January 2015 07:27:16 UTC, cliff wrote:
Would something like this be correct?
(def routes
[ {
/ {[ (br/resources-maybe {:prefix public})]
:home-page-handler}}])
On Monday, 12 January 2015 08:39:19 UTC+2, cliff wrote:
Hi Dan
Thanks for that. I have read that section.
My question is, how do I associate the / route with both a handler and
the 'resources-maybe'?
I would like the resources to pick up the Google Closure library sitting
in 'resources/public/js/out' when navigating to '/index.html'
On Monday, 12 January 2015 00:36:59 UTC+2, Dan Kersten wrote:
Hi,
Take a look at https://github.com/juxt/bidi#resources-and-resourcesmaybe
Regards,
Dan
On 11 January 2015 at 19:27, cliff clifford...@gmail.com wrote:
Hi
I am trying to mimic the following Compojure behaviour, in juxt/bidi
(defroutes routes
(*resources* /)
(GET /* req (io/resource index.html)))
(def http-handler (reload/wrap-reload (api #'routes)))
In Compojure, the 'resources' function seems to load all resources by
default from /resources/public/.
When I try set up the equivalent routes in bidi, I keep getting errors
of resources not found.
How would you do this in, juxt/bidi ?
Thanks
Clifford
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] modularity.org
Hi James,
If I understand your pattern correctly, you assoc a :routes entry to each
component that contains routes. Then your router component depends on these
components, selecting those that have a :routes key, and call each :routes
value function in turn until one return a non-nil Ring response.?
I think the two approaches share the same essential design.
First, the db (or anything else) is injected via the closure's lexical
scope, which I think is one of the nicest aspects of the component pattern
(compared with alternative approaches listed
here http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope)
The component-with-routes-to-try is 'marked' as such by having a :routes
key. With my bidi-based design I similarly 'mark' a component, but with a
protocol (modular.bidi.WebService). Essentially bidi works the same way as
Compojure - rather than calling functions, it keeps trying to match
patterns until it gets one that returns a non-nil map.
Aside: The reason I mark components with a protocol is because I need the
component to provide two maps - one from routes to keywords, the other from
keywords to handlers. This is not a core bidi idea, but something extra
I've built on top by extending bidi's protocols in modular.bidi, which has
to do with wanting the option of url formation (from the keyword back to
the path). I'm not yet sure if this is the right design.
In summary, yes, I think that the endpoint-component approach would work
very well with Modular and having a Compojure router component (together
with the endpoint-component function/pattern) would be very valuable.
Regards,
Malcolm
On Friday, 9 January 2015 16:34:05 UTC, James Reeves wrote:
On 8 January 2015 at 15:10, Malcolm Sparks mal...@juxt.pro javascript:
wrote:
The idea here is that you want individual components to be able to
'contribute' groups of routes. That way, you can avoid the common practice
of having one big 'god' namespace containing all the Ring routes, which is
then tightly coupled to all your Ring handlers. Instead, it's nice to have
the flexibility to compose systems from different combinations of
components.
One implementation approach is to have a 'router' component that
delegates to its dependencies. That way, routes can be 'plugged in' using
dependency declarations.
Currently I only implemented this with bidi, which I'm slightly biased
towards (because I wrote it). My 'router' implementation is here:
https://github.com/juxt/modular/blob/master/modules/bidi/src/modular/bidi.clj
That's an interesting setup. Are you merging the data-driven bidi routes
together?
If I may, let me run past you an idea I've been experimenting with that
has a similar goal.
I've been using functions that take in a configuration map (in practice, a
component) and return a handler. I call these endpoints (highly original,
I know).
(defn hello-endpoint [config]
(fn [request]
{:status 200
:headers {Content-Type text/plain}
:bodyHello World}))
Wrapping endpoints in a component is relatively straightforward:
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj
In Duct, the template/framework I'm designing, I use the Compojure
mechanism of trying endpoints in turn until one returns a non-nil value.
However, one could quite easily write a routing mechanism that dispatches
on a context path, or a regular expression.
This approach is pretty minimal, but has a few advantages:
1. It's not tied to a particular routing library
2. It's a simple interface
3. Configuration is passed down via a closure destructuring
As a more practical example, consider an endpoint that relies on a
database connection:
(defn product-endpoint [{db :db}]
(routes
(GET / [](list-products db)
(POST / [product] (add-product db product))
(GET /:id [id] (find-product db id
When we come to write our system, we wrap the endpoint in a component, and
have it depend upon the database component:
(defn new-system [config]
(- (component/system-map
:db (database (:db config))
:product (endpoint-component product-endpoint))
(component/system-using
{:product [:db]}))
(In the above example I've omitted the component that combines all the
endpoints together into a handler, as I think that's a more opinionated
component.)
Do you think this endpoint approach could work in Modular? I like the
idea of having a standard way of defining a subset of routes that depend on
a configuration.
- 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
Re: [ANN] modularity.org
Hi James, Yes. The idea here is that you want individual components to be able to 'contribute' groups of routes. That way, you can avoid the common practice of having one big 'god' namespace containing all the Ring routes, which is then tightly coupled to all your Ring handlers. Instead, it's nice to have the flexibility to compose systems from different combinations of components. One implementation approach is to have a 'router' component that delegates to its dependencies. That way, routes can be 'plugged in' using dependency declarations. Currently I only implemented this with bidi, which I'm slightly biased towards (because I wrote it). My 'router' implementation is here: https://github.com/juxt/modular/blob/master/modules/bidi/src/modular/bidi.clj But I have been meaning to add a Compojure equivalent, just haven't yet done so. Is this what you mean? If so, does Duct implement a similar pattern or does it do things differently? Also, I'm hoping that many of these pre-written components will be compatible with each other. For example, modular components are compatible with Daniel Szmulewicz's 'system' https://github.com/danielsz/system, and vice versa. On 8 January 2015 at 14:55, James Reeves ja...@booleanknot.com wrote: Out of curiosity, does Modular have a mechanism for abstracting groups of Ring routes? I'm wondering how much work can be shared between Modular and other projects, such as my own Duct template, which has similar ideas. - James On 8 January 2015 at 14:42, Malcolm Sparks malc...@juxt.pro wrote: I've created a new website to help new Clojure developers get started with Clojure and specifically with Stuart Sierra's component/reloaded-workflow pattern. On http://modularity.org you can find documentation about modular. Modular comprises :- - a set of pre-written components - a template system for creating new projects - some optional utility libraries There are also full instructions for creating new Clojure projects that are based on component, which involves typing the following :- $ lein new modular project-name template where template is one of a number listed on the site here: http://modularity.org/docs.html Don't expect everything to work perfectly yet, and please help if you can by suggesting improvements to make this easier for new Clojure developers. Thanks, Malcolm PS: There is a Google group mailing list 'modularity'. If you want to get more involved with this project, please join the list. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/YP_VM6Zf4RQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] modularity.org
I've created a new website to help new Clojure developers get started with Clojure and specifically with Stuart Sierra's component/reloaded-workflow pattern. On http://modularity.org you can find documentation about modular. Modular comprises :- - a set of pre-written components - a template system for creating new projects - some optional utility libraries There are also full instructions for creating new Clojure projects that are based on component, which involves typing the following :- $ lein new modular project-name template where template is one of a number listed on the site here: http://modularity.org/docs.html Don't expect everything to work perfectly yet, and please help if you can by suggesting improvements to make this easier for new Clojure developers. Thanks, Malcolm PS: There is a Google group mailing list 'modularity'. If you want to get more involved with this project, please join the list. -- 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: TDD and lein
LISP systems work better when they are continually up-and-running. Take Emacs for example. Clojure systems aren't much different. I prefer to think of lein more as a launch tool than a build tool. I don't think anyone has mentioned it on this thread yet, but lots of people are using Stuart Sierra's component workflow for precisely this reason - you can make changes and see the effects very quickly simply by typing (reset) into the REPL. See https://github.com/stuartsierra/component For a working example of incremental compilation, see http://modularity.org/templates/dashboard.html - it will recompile your ClojureScript and Less css files incrementally, and can do so because it can keep context between resets. It's possible to add 'test' components which will run your tests after every reset. I don't have any templates demonstrating that yet, but I have seen people do it. On Thursday, 8 January 2015 14:20:56 UTC, Andrea Crotti wrote: Ah great that's what I wanted, I'll try later. Does it give some feedback on what it's compiling and what is going on? I would use just cider in theory but I had some errors with namespaces (probably my fault) and more importantly it seemed that it didn't always recompiled things that were changed (again probably my fault). So in short only changing dependencies should require a new lein test or lein deps? And this useful plugins do you normally put them in your ./lein/profiles.clj or in every project you have? thanks a lot 2015-01-08 11:41 GMT+00:00 Robin Heggelund Hansen skinn...@gmail.com javascript:: The reason lein is initially slow, has to do with Clojures bootstrapping process, which is slow. People tend to avoid starting clojure programs repeatedly, and thus do alot of work from the repl, or using leiningen plugins which keeps running and listens for changes. Take a look at lein-test-refresh for tdd: https://github.com/jakemcc/lein-test-refresh It detects when you change your code, incrementally compiles and re-runs the tests. It runs your tests everytime you save a file :) kl. 12:32:44 UTC+1 torsdag 8. januar 2015 skrev Andrea Crotti følgende: Hi guys, I'm starting to use Clojure a bit more seriously, I knew already Lisp a bit and Haskell, in plus I've been using Emacs for a long time so luckily it's not as hard, and it's a lot of fun. I'm using Emacs + Cider for development and it works wonderfully, however I have a few problems/questions trying to do TDD. 1. Isn't it possible to make Lein more verbose? It's often quite slow and it would be nice to know what is going on, I can stand the slowness but at least tell me something :D 2. When is exactly that I need to run again lein test (which is painfully slow) and when just rerunning the tests from the same REPL suffice? I thought only when changing dependencies, but I had different experiences so I'm not too sure about the rule. And what command exactly is Cider triggering when I run the tests? It would be nice to be able to see somewhere more information like: - compiling file x - running tests for y with command z 3. Does incremental compilation work well/make sense for Clojure? I found something but the fact that it's not done straight away in Leiningen makes me think it's maybe not much used? Thanks a lot, and congratulations to all the developers for the great language! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
Thanks for the nice words about Bidi (https://github.com/juxt/bidi). For the record, Bidi now supports ClojureScript too. btw. The reason for matching on the path (rather than allowing matches on the query-string) is intentional, since I think that encourages a more RESTful architecture. However, it's possible to extend the Pattern protocol to match on anything in the request, should that be needed. On Wednesday, 6 August 2014 09:27:44 UTC+1, DomKM wrote: Hi Craig, Great question! Bidi https://github.com/juxt/bidi is a fantastic library and was my favorite Clojure routing library prior to Silk. The design of Silk was heavily influenced by that of Bidi. In terms of commonalities, both Silk and Bidi are bidirectional, pure (no side effects), based on data composition (not function/macro composition), extensible via protocols, and decouple matching from handling. In terms of differences, Bidi is (obviously) not compatible with ClojureScript. Bidi's design is the most amenable to porting to ClojureScript of any Clojure library that I've reviewed, but it still makes many assumptions about using Ring and running in a server environment. Bidi routes are defined in a tree structure that branches at URL path segments. While Silk can match any part of a URL, Bidi can only match the URL path due to its routes structure. I also think that Silk's route syntax is a lot easier to read and programmatically manipulate than Bidi's, but this is subjective. Hope that helps. :) Cheers, Dom On Mon, Aug 4, 2014 at 10:10 PM, Craig craig@gmail.com javascript: wrote: How would you position Silk in relation to Bidi? Thanks for any insights. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: how do you name your protocols?
I agree with you and Meikel's points about wrapping protocols with API functions, it makes sense, especially if you want to combine these calls with (Prismatic) schema checks. However, I'm not sure about your point that Stuart made an 'unfortunate' design to 'expose' protocol methods directly, it's just a necessary consequence of the component design, unless you can suggest an alternative approach. On Sunday, 28 December 2014 16:54:30 UTC, Jozef Wagner wrote: I was not implying anything about what Rich have said. While the SPI term may be used in the 'enterprise' field too much (and in an unnecessary complicated manner), I think it has perfectly valid uses in Clojure. The API tells you what a function or a macro does for you, but SPI tells you what you have to do in order to integrate with existing functionalities. BTW I think protocol methods should be in SPI too. (Stuart's components library made IMO a bit unfortunate decision to expose 'start' and 'stop' protocol methods directly) See http://kotka.de/blog/2011/07/Separation_of_concerns.html for a related write-up. Jozef On Sunday, December 28, 2014 4:18:47 PM UTC+1, adrian...@mail.yu.edu wrote: You're overlooking the fact that a service provider interface is simply enterprise design pattern jargon for a subset of public APIs that expose the underlying interfaces of the library to consumers. Saying that Rich is saying protocols should never ever be part of the public API is both misleading and false. On Sunday, December 28, 2014 2:50:06 AM UTC-5, Jozef Wagner wrote: Protocols should never ever be part of public API. Protocols can be part of the SPI, if custom extensions are to be supported. Otherwise they are an implementation detail. See Rich's talk at 4:30 http://vimeo.com/100518968 Jozef On Sun, Dec 28, 2014 at 8:11 AM, Mikera mike.r.an...@gmail.com wrote: That depends if the protocols are part of your user-facing API or not - a lot of the time I find that protocols are best hidden as implementation details rather than exposed to users. In core.matrix, for example, users never see the protocols directly: only implementers of new matrix libraries need to care On Sunday, 28 December 2014 02:32:44 UTC+8, Ashton Kemerling wrote: Changing old protocol names should trigger a major revision change in the minimum because it breaks backwards compatibility. --Ashton Sent from my iPhone On Dec 27, 2014, at 11:18 AM, Michael Klishin michael@gmail.com wrote: On 27 December 2014 at 19:10:38, Jozef Wagner (jozef@gmail.com) wrote: clj-time seems to be naming protocols inconsistently. It uses ISomething, Something and SomethingProtocol naming. I suspect it is because it has 60 contributors and most users never have to extend the protocols. Feel free to submit a PR that standardises all names on Something. -- @michaelklishin, github.com/michaelklishin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: problem redefining protocols and records in emacs+nrepl
I once worked with a Clojure dev who had a note stuck to his monitor with
the words 'Have you tried lein clean?'. :)
On Thursday, 16 May 2013 11:56:58 UTC+1, Joachim De Beule wrote:
Just a small follow up in case somebody else hits the same problems: they
disappear after a lein clean...
Op vrijdag 1 maart 2013 17:52:36 UTC+1 schreef Jim foo.bar het volgende:
On 01/03/13 16:17, Joachim De Beule wrote:
I'm not sure what you mean. I am not changing between namespaces in
this last example, only trying to delete a slot from a record
definition and create a record according to the new definition
subsequently. The problem occurs even when I do a C-c C-k
(nrepl-load-current-buffer) on the buffer containing the defrecord
form (apart from other things). It disappears when I change the name
of the record (but then I need to change it in all other files as
well, which is very annoying)
yes I'm sorry I got confused...your use case works on my bare repl so
I'll assume something is wrong in your setup/enviroment...unfortunately
I cannot help there...
user= (defrecord Foo [a b])
user.Foo
user= (Foo. 1 2)
#user.Foo{:a 1, :b 2}
user= (defrecord Foo [a])
user.Foo
user= (Foo. 1)
#user.Foo{:a 1} ;;all good
Jim
--
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: Server Sent Events under Http-Kit
Here is a solution for SSE over http-kit channels
(defn server-event-source [ch] ;; Adding a mult here is dangerous because
it bleeds the underlying ;; channel dry. We should provide the mult via
modular.async (let [m (async/mult ch)] (fn [req] (let [ch (async/chan 16)]
(async/tap m ch) (with-channel req net-ch (on-close net-ch (fn [_]
(async/untap m ch) (async/close! ch))) (send! net-ch {:headers headers}
false) (go-loop [] (when-let [data (! ch)] (println Got data! data)
(send! net-ch (-message data) false) (recur
https://github.com/juxt/modular/blob/master/modules/http-kit-events/src/modular/http_kit/events.clj
On Saturday, 6 December 2014 17:03:41 UTC, Lars Ole Avery Simonsen wrote:
Hi guys
I am trying to implement Server Sent Event support in a small hobby
project based on the http-kit server framework and compojure.
I am still quite new to clojure in general, so it may very well be that I
am missing something obvious, but this SSE detail has me stumped.
What I have tried is to take inspiration from the Eventual
https://github.com/ninjudd/eventual library for the SSE implementation
(which is aimed at jetty). I have changed the Eventual implementation so
that it uses the http-kit async-channel implementation for data
transmission. What I am seeing is that everything seems to run without
errors except for the fact that no data is being received at the
EventSource in the browser.
If I allow the sse channel to close immediately after opening (which is
pretty useless), the initial message is received at the browser side, but
if I keep the connection open, nothing gets received.
Having had a look at the http-kit internals, my suspicion is that the
socket doesn't get flushed and so all my attempts at communication are
sitting in some buffer somewhere.
All SSE implementations I have looked at for other platforms have explicit
calls to flush the socket buffers on the long lived connection after each
message transmission.
Does anyone have any suggestions as to a better way to achieve SSE support
in a http-kit based server? Or maybe ideas as to what I might be doing
wrong?
Thanks in advance.
LOAS
--
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: Server Sent Events under Http-Kit
http-kit's send! doesn't block normally -
From http://www.http-kit.org/server.html :-
send!: Sends data to client and returns true if the data was successfully
written to the output queue, or false if the channel is closed. Normally,
checking the returned value is not needed. This function returns
immediately (does not block).
http-kit will attempt to write to the output queue, otherwise will place
the message in a pending queue backed by a
java.util.LinkedListByteBuffer, so there's no back-pressure (except for
that exerted by an OutOfMemory exception)
AFAICT there's no way of finding whether http-kit's output channel is empty
or not, that would certainly be a feature I'd like to see.
Does aleph support this?
On 17 December 2014 at 18:23, Zach Tellman ztell...@gmail.com wrote:
Does `send!` block if it needs to exert backpressure? If so, the
`go-loop` seems dangerous. If not, how does backpressure work?
On Wed, Dec 17, 2014 at 8:07 AM, Malcolm Sparks malc...@juxt.pro wrote:
Here is a solution for SSE over http-kit channels
(defn server-event-source [ch] ;; Adding a mult here is dangerous
because it bleeds the underlying ;; channel dry. We should provide the
mult via modular.async (let [m (async/mult ch)] (fn [req] (let [ch
(async/chan 16)] (async/tap m ch) (with-channel req net-ch (on-close
net-ch (fn [_] (async/untap m ch) (async/close! ch))) (send! net-ch {
:headers headers} false) (go-loop [] (when-let [data (! ch)] (println Got
data! data) (send! net-ch (-message data) false) (recur
https://github.com/juxt/modular/blob/master/modules/http-kit-events/src/modular/http_kit/events.clj
On Saturday, 6 December 2014 17:03:41 UTC, Lars Ole Avery Simonsen wrote:
Hi guys
I am trying to implement Server Sent Event support in a small hobby
project based on the http-kit server framework and compojure.
I am still quite new to clojure in general, so it may very well be that
I am missing something obvious, but this SSE detail has me stumped.
What I have tried is to take inspiration from the Eventual
https://github.com/ninjudd/eventual library for the SSE
implementation (which is aimed at jetty). I have changed the Eventual
implementation so that it uses the http-kit async-channel implementation
for data transmission. What I am seeing is that everything seems to run
without errors except for the fact that no data is being received at the
EventSource in the browser.
If I allow the sse channel to close immediately after opening (which is
pretty useless), the initial message is received at the browser side, but
if I keep the connection open, nothing gets received.
Having had a look at the http-kit internals, my suspicion is that the
socket doesn't get flushed and so all my attempts at communication are
sitting in some buffer somewhere.
All SSE implementations I have looked at for other platforms have
explicit calls to flush the socket buffers on the long lived connection
after each message transmission.
Does anyone have any suggestions as to a better way to achieve SSE
support in a http-kit based server? Or maybe ideas as to what I might be
doing wrong?
Thanks in advance.
LOAS
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/DbBzM3AG9wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/DbBzM3AG9wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members
Re: Starting a project the right way - tips?
Adding a vote for Potemkin's import-vars. Also, I've been using Stuart's component approach for almost a year in a half-dozen projects and it's real value is having a consistent architecture - I find projects that don't use it are likely to invent their own ad-hoc, informally-specified alternative. We've also used the library in a project developed by ~10 engineers and it's scaled up well. I think the best resource for learning about component is one of Stuart's talks: https://www.youtube.com/watch?v=13cmHf_kt-Q I've also talked about many of the underlying details and subtleties of the approach, and how you would recreate it from the ground up. See here for the recording: https://skillsmatter.com/skillscasts/5820-components-with-clojure On Thursday, 30 October 2014 02:52:46 UTC, jaju wrote: I find Potemkin's import-vars [https://github.com/ztellman/potemkin] too a very neat addition to one's toolbox. Allows one to keep a clean code-layout. I haven't used the other parts to comment on them. Best, Ravindra On Thu, Oct 30, 2014 at 5:44 AM, Daniel Szmulewicz daniel.s...@gmail.com javascript: wrote: If you'll follow James Reeves' recommendations (which you should), you might want to have a look at System, a library that streamlines the process of setting up components. This is the first step I take with any Clojure project. https://github.com/danielsz/system Its sole dependencies are Components by Stuart Sierra and reloaded.repl by James Reeves. On Monday, October 27, 2014 3:42:27 PM UTC+2, Colin Yates wrote: Thanks all. Just managed to wire in clojurescript.test into my lein build - woot :). On Monday, October 27, 2014 1:38:02 PM UTC, James Reeves wrote: I've gotten on well with using Component https://github.com/stuartsierra/component for managing the high-level I/O dependencies of my application. There's also Ring-Defaults https://github.com/ring-clojure/ring-defaults, which provides sensible and customisable default middleware settings. - James On 27 October 2014 11:07, Colin Yates colin...@gmail.com wrote: About to embark on a new project and interested in wish I knew this/wish I had used this type sentiments. An extension of this splendid article: http://blog.mattgauger.com/blog/2014/09/15/clojure-code- quality-tools/. Any others? For context, this is going to be a non-trivial SPA using clojurescript supported by a Clojure backend (https://groups.google.com/d/ topic/clojurescript/9cDFfAGsDE4/discussion) In addition to the tips I found in the article I am also planning on using core.typed, primarily to address the anyone remember what this data structure looked like? 12 month maintenance risk. I did look at schematic but I like the extra enforcement core.typed gives. On a side note, answering this question from google alone is non-trivial. We, as a community have reached that point where there are so many (good, but overlapping and sometimes contradictory) good next steps it is easy to be paralysed by choice. A few more authorized (whatever that means) prescriptions wouldn't go amiss. Not sure what the answer is, merely raising the flag. So, what tips/techniques/XYZ do you wish you had started with? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: As framework creator, how would you get user defined specific functions/macros?
I think you should consider using Clojure's protocols feature rather that code-loading. Frameworks take control away from a developer, seeing the developer's code as somewhat subservient to the framework. The more common approach in Clojure applications is to provide libraries, and expect your library to be just one of many libraries the developer may be adopting. That means leaving the developer in control, providing functions that the developer can call. If you want to provide 'callback' behaviour, protocols are ideal. On Thursday, 20 November 2014 11:22:52 UTC, Hussein B. wrote: Hi, Lets say that you are framework creator and to use your framework, you defined a macro called defcontroller where the users of your framework add their logic. You -as framework creator- how would you load user defined source code files and collect their defcontroller definitions? Thanks for help. -- 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] modular 0.5.1 with cylon 0.4.0
Hi, As a follow-up to my talk at EuroClojure 2014, I have deployed the latest modular and cylon releases to clojars. Both of these projects contain pre-built components to get up-and-running quickly with a component-based application as described by Stuart Sierra :- [1] https://github.com/stuartsierra/component [2] https://www.youtube.com/watch?v=13cmHf_kt-Q [3] http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded You don't need to download anything because the functionality is built into Leiningen already. For example, to create a simple website, do this :- $ cd /tmp $ lein new modular myapp $ cd myapp $ lein run You can also add various options to determine what kind of project gets generated (and lots more will be added in the future). For example, here's how to generate the same site with a login page, and run using the repl :- $ cd /tmp $ lein new modular my-secure-app +cylon/login $ cd myapp $ lein repl nREPL server started on port 56307 on host 127.0.0.1 REPL-y 0.3.0 Clojure 1.6.0 Type (dev) to start user= (dev) #Namespace dev dev= (go) Adding user 'dev' with password: Zl6OrGs :ok dev= (reset) ; - and repeat, as per Stuart's 'reloaded' workflow in [3] Now browse to http://localhost:3000 and you should see a Login link in the menu bar. Login with user 'dev' and with the password shown in the repl (the dev user is only added when you run a dev system). In the future we are planning to make all the modular components available via lein new generation options. Bear in mind that unlike most template generated projects, projects are based on the component pattern are easy to change post-generation via the system.clj namespace, so the 'lein new modular' step is merely to help beginners get started more quickly. As I mentioned in my talk, we have a Google discussion group called 'modularity' for discussion about this and other component-related topics, all welcome. Malcolm -- 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] modular 0.5.1 with cylon 0.4.0
Hi Michael. No, it wasn't intentional. I think I've fixed it now, let me know if you still can't see the content. Regards, Malcolm On Tuesday, August 5, 2014 1:01:11 PM UTC+1, Michael Klishin wrote: On 5 August 2014 at 15:54:58, Malcolm Sparks (mal...@juxt.pro javascript:) wrote: As I mentioned in my talk, we have a Google discussion group called 'modularity' for discussion about this and other component-related topics, all welcome. Looks like non-members cannot even view group content. Is this intentional? -- @michaelklishin, github.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 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] System
Michael is right, but I'll expand a bit. Jig is based on Stuart's tools.namespace and workflow-reloaded pattern, and I released it before I was really aware of Stuart's component library. Neale Swinnerton introduced me to 'component' and persuaded me of the strengths of Stuart's approach, in particular, constructing components in Clojure code. (I originally planned to 'rebase' Jig onto component but it was going to require a complete overhaul and I didn't want to put existing users Jig through that transition). I really like component, it's much better than Jig! My current plan is to recreate Jig's browser-based tooling as a set of components that can be integrated into the dev-system of any component-based project. For example, I have an Om component that present a live visualisation of a system's dependency graph as a diagram. I used this in my EuroClojure slides and I want to make this available to developers, via a lein new modular +switch or direct inclusion in the system.clj namespace. Michael is right about the fact there is no 'retro-fitting' issue. I very much welcome Daniel's work - I don't think duplication of effort is a concern, the fact is there's duplication of effort everywhere, we mostly don't see it. Actually, that's exactly what we're trying to tackle here. The nice thing is that components in Daniel's 'system' project and compatible with modular's - where there is overlap the code is almost identical (a good sign!), and there are components in 'system' that don't exist in modular and vice versa. Since they both use Stuart's component library idioms, you can pick and choose between the collections. I do hope others in the community will contribute to an existing collection or create their own. On Tuesday, July 29, 2014 7:26:16 AM UTC+1, Michael Klishin wrote: On 29 July 2014 at 10:21:33, Daniel Szmulewicz (daniel.s...@gmail.com javascript:) wrote: I wasn't aware of it. How does it relate to Jig (of which I was aware), if it does? Jig originally was reinventing parts of Component + did what Modular does. Malcolm will likely correct me but I believe Modular is what Jig meant to be, built on top of Component (which has taken off in the community). Anyway, modular looks neat and has more components, for sure. The example in the README shows usage via a Leiningen template. I found it was difficult to retrofit changes on existing projects with the template approach. You can use the modules individually, the template simply brings together a few commonly used for Web development. You can use e.g. the Netty module w/o the template or any other modules. -- @michaelklishin, github.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 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] Jig
It's a nice idea to load your schema and data on every reset, if you can. But if you need to, place you data anywhere under the :safe key in the system map and it will survive a reset. On 18 Mar 2014 15:57, Joachim De Beule joachim.de.be...@gmail.com wrote: Got it! :-) One more thing. While developing, I often have to deal with large amounts of data that take quite a while to load. However, the data is lost and so has to be reloaded after every reset, which is a bit annoying. Is there a way to prevent 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Om-powered HTML slide-decks
Yes, I believe it will be posted there soon. On 13 March 2014 17:35, Laurens Van Houtven _...@lvh.cc wrote: Hi Malcolm, Love the code, excited about the talk as well. Will it eventually end up on infoq.com/Clojure? thanks in advance lvh -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/2f7cQCl6q28/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Jig
Hi Joachim, What you're describing is a dynamic system map, whereas the current pattern as described by Stuart in his classic blog post http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloadeddescribes a static system map which is established at the beginning of a reset cycle and remains. After all, it's a var, not an atom. The reset pattern is intended as a development aid, with the bonus of providing some architectural hygiene that comes in having system state located in a single map (rather than as vars spread over many namespaces). There is no intention to reset a production system. However, there's no reason why you can't put an atom or ref in the system map, have that atom or ref updated every time the config changes, and connect everything together with core.async. Parts of your program that need up-to-date configuration details can deref the atom or ref, just in time, or watch the atom or ref in order to trigger database re-connections. You definitely shouldn't be altering the global var root which contains the system, as suggested in 2. You shouldn't access user/system in your program code (although it's a useful thing to access in an exploratory REPL). Instead, a component should pass the system it receives in the start phase as an argument when building structures, such as Ring middle-ware chains, connection managers, thread pools, etc. Regards, Malcolm On 11 March 2014 15:17, Joachim De Beule joachim.de.be...@gmail.com wrote: update: I made mistake at the end of my previous post: I mean that the db component does NOT sufficiently encapsulate the internals of course... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] 1st public release of thi.ng geometry toolkit (CLJ CLJS)
Karsten, This is amazing. Watching you work with your geom library in this fantastic video has really inspired me :- http://www.youtube.com/watch?v=tKIVJ2TaS2kfeature=youtu.bet=20m9s I've been looking for some geom library to build animated data visualizations, so I'm looking forward to exploring this more. Thanks for making this available to everyone - it's obviously been a huge amount of work. Regards, Malcolm On Monday, 10 March 2014 21:32:02 UTC, Karsten Schmidt wrote: It is my absolute pleasure to finally announce the first public release of the 2d/3d geometry library/toolkit: thi.ng/geom Having worked on this regularly since late 2011 as successor of my Java-based toxiclibs.org project, the new project has already undergone three complete overhauls as I've been improving my grasp of Clojure. The project currently consists of 26 namespaces and 6500+ lines of code. You can find all existing details, sources initial examples at: https://github.com/thi-ng/geom/blob/master/src/index.org Leiningen coords: [thi.ng/geom 0.2.0] (available from Clojars) This project is part of a bigger rapidly growing collection of Clojure libraries targeted at the wider computational/generative design context. All libraries in the thi.ng collection are (will be) developed in a literal programming format to also encourage their use in teaching contexts and generally try to improve the state of documentation managing source code. Clojure with its focus on isolated functionality is particular nice to work with in this sense and Org-mode has completely transformed my way of working. Since this is only the 1st release and I've planned a few more (potentially) breaking API changes I cannot currently accept major pull requests until the API is more solid (and once I'm less up against deadlines). In general though, I hope this project has a wide enough scope license to encourage further communal development. Lastly, if you're not too allergic to strong German accents, you can also watch (and follow along) a little live coding session I've done with Paul Kinlan @ Google Developers Live last month: http://youtu.be/tKIVJ2TaS2k?t=20m9s Happy coding! :) -- 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.
Om-powered HTML slide-decks
There are some HTML-based tools out there (reveal.js, slidy, impress.js, deck.js ...) for building slide-based presentations for conference talks. But you usually have to write your slides in raw HTML. This feels cumbersome when you're used to writing LISP s-expressions with paredit. And if you want to build in more interactivity, you have to be proficient in JavaScript. Last week I gave a presentation at QCon in London for which I built a slide-deck in Om. This proved (far) easier than my previous failed attempts with other technologies (including vanilla ClojureScript). I've found that ClojureScript + Om/RevealJS + core.async (go-blocks) also makes a great platform for browser-based interactive SVG diagrams and animations. Not quite Flash, but almost, and in some ways better. Anyway, I've uploaded the slides, code, instructions and everything to here: https://github.com/juxt/qcon2014. in case anyone else wants to try building an Om-based slide-deck at a future event. -- 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: Om-powered HTML slide-decks
Sure. For SVG examples please view the presentation here:
http://qcon.juxt.pro - I'm sorry it isn't (yet) responsive or
touch-sensitive (getting it working on my laptop before the talk became the
overriding priority) so you'll need a keyboard to control it. Use the
left/right arrow keys to navigate between slides.
SVG animations are on slides 19, 20, 22, 26, 29 and 30.
Source code is here:
https://github.com/juxt/qcon2014/blob/master/src-cljs/qcon/main.cljs
Thanks in part to Ŝablono[1] providing the Hiccup syntax, blending together
SVG, ClojureScript and Om component state is easy :-
[:g {:transform translate(30,0)
:onClick (fn [_] (new-random-pick owner))}
[:rect
{:x 0 :y 65 :width 100 :height 100 :fill black :stroke white
:stroke-width 3}]
(when-let [n (om/get-state owner :pending-put)]
[:text {:x 20 :y 150 :style {:font-size 64pt :color white} :fill
white} (str n)])]
[1] Ŝablonp - https://github.com/r0man/sablono
On Sunday, 9 March 2014 15:15:29 UTC, Base wrote:
This is really cool. Could you share some examples of the SVG animations
you have been playing 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
---
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] Jig
Hi Joachim, I suggest you create a component, C, that assocs a channel in the system map. Now create a component, A that depends on C. A should start and stop a thread in the usual start/stop Lifecycle. The component should get the channel from the system map. The thread should check the resource, and if it changes, put messages on the channel. Components that are dependent on changes to the resource should also depend on C, start go blocks are read from the channel it provides. If you need multiple consumers, a pub/sub mechanism, all that stuff is provided by the core.async API. If you really need to automatically cause a reset, you can do that too - see the API in jig.reset, but it's rarely necessary. I don't think it's what you want to do in this case. Jig Version 2 is in RC status. This is mostly because the documentation (README) needs to catch up. As soon as I've fully updated the docs I'll release the final 2.0.0. Regards, Malcolm On 5 February 2014 10:19, Joachim De Beule joachim.de.be...@gmail.comwrote: Hi Malcolm, I have a follow up question if you don't mind. Suppose I want to define a component that starts a thread and regularly checks a resource. If the resource changes, this has repercussions for other (dependent) components. How would you do that in jig? Maybe this question is too broad, so let me ask some more specific questions. All components should get/set their state from/in the system map, right? Now the system map is a var defined in the user namespace. Does this mean then that the resource-checking thread should alter the system var? And then I guess it should also call user/reset? Or am I still missing something here? BTW, not that I want to press you, but do you have any idea when you will be finishing up version 2? I ask because it seems that the github code currently is kind of in-between versions... Thanks again, Joachim. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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] Jig
Hi Joachim The component lifecycle protocol is used to group together the init, start and stop functions tied to ephemeral services common to many Java server-side applications. I'm not sure it makes sense for components to satisfy other protocols that are functional in nature, as this invite coupling of concerns. The intention is that component functions inject/reject state into/from the system map. Your suggestion of retaining a JDBC connection under [:jdbc-component :db] is exactly what Jig intends. Clojure applications should, as far as possible, avoid state. But when applications need to retain state, they should do so in a system map that is continually subject to repetitive creation and destruction, if only to avoid the detrimental effect that stale state can have on the speedy and iterative development of applications. I have toyed with the idea of adding core.async protocols and provides/requires metadata to components, but none of my approaches have felt satisfactory. I think it's better to keep components as lightweight as possible, letting them setup and teardown state within the system map, and with that as their single responsibility. (However, if you have alternative suggestions, do let me know) Regards, Malcolm On 22 January 2014 22:22, Joachim De Beule joachim.de.be...@gmail.comwrote: (follow up) I just realized that another approach would be to hold the jdbc connection type implementing the JDBCProtocol in system under [:jdbc-component :db] or something, and then call the clojure.java.jdbc/query like functions on that. Anyway, I would be very happy to hear your comments on 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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: How to handle configuration in Clojure?
There's also Jig : https://github.com/juxt/jig Jig's recommendation is for configuration to be held in EDN files. I much prefer EDN over environment variables. Environment variables feel awkward when there you have lots of configuration, usually in the form of a tree. Usually it makes sense to have one configuration file per environment. That can make it hard to keep configuration files up to date, so judicious use of the #=() Clojure reader macro can allow you to programmatically deviate from a default configuration - often the delta from a default configuration is more informative. There are more details in Jig's README.md file. I agree with the comments against using dynamic vars. They reduce the ability to reason about functions and are precarious when dealing with threads - binding conveyance is tricky and small mistakes can lead to elusive bugs. I pass configuration as a single argument into types/records that declare lifecycle methods. I have found this pattern to serve me well in over a dozen projects. Since stumbling on this pattern I have had no need to resort to dynamic vars for environment config, and my projects have been smaller, more reliable and easier to reason about. On Tuesday, January 14, 2014 9:04:45 AM UTC, James Trunk wrote: Thanks for all the great links and ideas you have all posted, now I have plenty of reading and thinking to do! I am curious about what you mean by 'thread safety'. Perhaps thread safety is the wrong term, but what I meant was the limitations dynamic binding introduces around thread dispatching, which Stuart Sierra explains in this blog posthttp://stuartsierra.com/2013/03/29/perils-of-dynamic-scope . Cheers, James On Monday, January 13, 2014 7:10:38 PM UTC+1, Stefan Kanev wrote: On 13/01/14, James Trunk wrote: The downsides to dynamic vars seem to be: hiddenness, thread safety, and more complex tests (binding before each test). I am curious about what you mean by 'thread safety'. As far as I know, dynamic variables are thread-local, which means that they are thread-safe, at least to some extend. I assume you mean something specific? -- Stefan Kanev ¦ @skanev ¦ http://skanev.com/ If a program manipulates a large amount of data, it does so in a small number of ways. -- -- 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.
ANN: bidi, a URI dispatch and formation library for Clojure
I'd like to announce a new URI routing library called bidi. If you're planning to write HTTP/web applications in Clojure in 2014, chances are you'll be including hyperlinks (URIs) in your pages/views/templates. After all, this is what the web is all about. But the code that includes/generates your URIs can get tightly coupled with the code that dispatches on them (Compojure routes, etc.), this can lead to broken links if you're not careful. Having used Pedestal services in many of my systems, I'd made heavy use of the (url-for) function. But I found it difficult to extract the Pedestal routing code from the rest of the Pedestal back-end concepts. When I wanted to be able to use http-kit for another project, this prevented me from using Pedestal and I really missed the ability to form URIs - I wanted was the (url-for) function back! Like Pedestal, bidi starts with a data description of your routes - acting as the basis for both the generation of URIs and the dispatch to your handlers. However, bidi only offers URI routing and formation - nothing else - so it can be used for 'traditional' Ring web apps, http-kit, Liberator and so on. With a little work it should work well with ClojureScript too, since it is based on protocols rather than macros. You can find more about bidi, with code examples, here: https://github.com/juxt/bidi While I've been thinking about writing bidi for a long time (hoping someone else more capable than me would write it!), the actual code is very new and so all the usual disclaimers apply. However, I'd be very grateful for feedback on this new library - what you like and dislike about it, initial impressions, complaints, alternatives you know about and any questions etc.. And finally I'd like to wish everyone on this list a Happy New Year and the very best for your Clojure hacking activies in 2014. Malcolm JUXT - https://juxt.pro -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is Clojure right for me?
I modularize my Clojure systems using Jig: https://github.com/juxt/jig - it's one of many possible approaches. On 27 December 2013 15:23, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote: On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli How do you decompose large systems in Clojure? I'm curious as to why you think only OOP allows you to decompose large systems? Between namespaces, protocols, multimethods, ad hoc hierarchies, and higher order functions, Clojure has a lot of tools for organizing code... I've never claimed that OOP is the only way to decompose large systems, but since Clojure doesn't support OOP and many languages are multi-paradigm nowadays, I was wondering how you modularize systems in a language which is purely functional. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/zwhpqptqV1A/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/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: How do I serve clojure pages with nginx
Here's an article I wrote that takes you through the full process of running nginx and and a Clojure web app. https://juxt.pro/articles/manual-clojure-deployment.html On Tuesday, December 17, 2013 12:44:34 PM UTC, Zeynel wrote: I've set up a home server with ubuntu and nginx and I can serve static pages. Now I want to add clojure but I am not sure what I need to do. I asked the same question in StackOverflow but for some reason it is voted to be closed: http://stackoverflow.com/questions/20632987/how-to-serve-clojure-pages-with-nginx Can you please direct me to documentation where I can read about this? Some issues that I don't understand are: how do I tell nginx that I am using clojure? Where do I install clojure, in the server? Where do I create the clojure files? Thanks. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is Clojure right for me?
Hi Massimiliano. The absence of a well-established framework for web development in Clojure is not a sign of its immaturity (rather the opposite). Web frameworks can give you some increased productivity to begin with, but as soon as you need to do something that isn't naturally supported by your chosen web framework you're in trouble, and that's when productivity drops off a cliff as you struggle to bend the web framework to your requirements. For example, you choose a web framework with good REST support, then find out later you need to add web sockets. I've written and deployed about a dozen serious web applications using Clojure. My opinion is the best strategy that guarantees long-term productivity is to build your system from a set of smaller components that you choose 'a la carte'. That way, if your requirements change you can swap in and out other components as you need to. I would guess that the vast majority of Clojure web applications are written this way, which is why you don't see widescale adoption of a particular web 'framework' by the Clojure community. Instead, Clojure developers pick from a set of constituent parts: Jetty, http-kit, Ring, Compojure, Hiccup, Enlive, Stencil, Liberator, domina, dommy, C2, Om, shameless-plugbidi/shameless-plug, and so on and so on. The fact that these components all fit together so well is one of the truly outstanding features of the Clojure platform. Few languages come close to this level of integration, which is why they actively curate frameworks. Investing time in Clojure is both pleasurable and productive. It's a question of whether you want 'short-term' productivity to meet a particular project goal (choose a web framework), or sustainable productivity to deliver value to your users over the longer term (choose to learn, understand and utilize a set of components from the wide pool that the Clojure community has created). Regards, Malcolm On Wednesday, December 25, 2013 9:06:20 PM UTC, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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] Jig
This is a good question, but not so much one for Jig as for Stuart's workflow pattern on which Jig's based. Generally, I write my Clojure bottom-up, so that functions that do work against database connections and the like, take these as parameters, and not the whole system map. This leads to the situation where callers to these functions are doing stuff to extract the necessary values from the system map in order to pass them as parameters. Also, some functions have to take a lot of parameters. So at certain times I feel it's often easier to pass down the whole system map. This seems in violation of http://en.wikipedia.org/wiki/Principle_of_least_privilege - however, it's much better to pass state in to a function as a parameter, than have that function pull in state from vars that are scattered around various name-spaces. This also has a benefit to testing - it's possible to construct mock system map to test functions. On the plus side, there is some precedent here. Ring handlers take large request structures, Liberator and Pedestal handlers take similar large 'context' parameters. Datomic's query takes a whole database as a parameter! There is good support in Clojure for handling larger structures, such as clojure.walk, de-structuring, and so on. This would be a good time to mention Strucjure https://github.com/jamii/strucjure on which Jamie Brandon gave a great talk earlier this week in London. A common pattern in Strucjure is to use a tree walk and match on parts of the structure to drive processing. On Thursday, November 7, 2013 5:13:49 AM UTC, julius wrote: Another question, using jig, the connection/db/cache/storage will be everywhere in our code as a parameter of functions, is it flexible? ,currently I prefer to managing those side effect at one place but will not spread out to our other core functions. Thanks On Saturday, October 12, 2013 12:23:41 AM UTC+8, Malcolm Sparks wrote: A few months ago, Stuart Sierra blogged about the workflow he follows for building Clojure applications. One of the great pleasures of working with a dynamic language is being able to build a system while simultaneously interacting with it. -- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded Since then I've been using this workflow for my own projects, and found it to be amazingly effective. I've added some extra features, and the result is Jig, which builds on Stuart's work in the following ways :- - Multiple components can each contribute to the 'system' map - Components are started in dependency order - Components are specified and configured in a config (edn) file - Jig can host 'plain old' Leiningen projects - Jig will even 'reload' them too e.g. if their project.clj dependencies change. - Jig can host multiple projects simultaneously There's a small but growing list of optional re-usable components that provide extra functionality :- - Pedestal services support. Jig provides the system map and 'url-for' function in the service context. - Nginx cache purging on reload - Git pull prior reload - Reload via JMX - nREPL - Stencil cache purging - Firefox remote control support for 'browser refresh on reload' I know others are working on similar designs. I'd be interested to hear what people think and whether this is useful. Thanks, Malcolm PS: Jig can be found here: https://github.com/juxt/jig -- -- 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] Jig
Hi Tim,
It's interesting you're thinking about browser-connected repls. Today I
added clojurescript support to Jig, it's pushed to master but I haven't
documented the config options yet, but below is an example. Nothing fancy
like crossovers yet, it's basically a thin wrapper over ClojureScript's
compiler, the config options map directly to the options given to the
compiler.
:cljs-builder
{:jig/component jig.cljs/Builder
:jig/project ../my-proj/project.clj
:source-path ../my-proj/src-cljs
:output-dir ../my-proj/target/js
:output-to ../my-proj/target/js/main.js
:source-map ../my-proj/target/js/main.js.map
:optimizations :simple
:pretty-print true
;; :clean-build true
}
Another built-in component can figure out, given the dependencies, what
files to serve and on which server to serve it from.
:cljs-server
{:jig/component jig.cljs/FileServer
:jig/dependencies [:cljs-builder :web]
:jig.web/context /js
}
which depends on some Ring or Pedestal routing and Jetty or other
webserver, but you're likely to have that configured already :-
:server
{:jig/component jig.web.server/Component
:io.pedestal.service.http/port 8000
:io.pedestal.service.http/type :jetty
}
:web
{:jig/component jig.web.app/Component
:jig/dependencies [:server]
:jig/scheme :http
:jig/hostname localhost
:jig.web/server :server
}
That's it really. I think Jig makes an ideal platform for building and
serving clojurescript, in comparison to Leiningen plugins. Firstly, there's
no JVM start-up cost, the point of Jig is to keep the JVM running all the
time, so there's no need for the once/auto service that lein-cljsbuild
offers. Secondly, serving the resulting Javascript files is straight
forward, and built in, so no 'lein ring server' requirement either.. With
Leiningen, you either have to build routes to the javascript into your own
app, or run lein ring server, but then Leiningen doesn't make it easy to
run multiple services concurrently. Thirdly, there's no file-system
polling, and services that depend on the clojurescript compilation can be
started as soon as the compilation is complete.
One thing that lein-cljsbuild does really well is multiple build configs.
I've decided to use a single build configuration, to keep implementation
easier and a direct mapping to the clojurescript compiler, but of course
you can add different builds by just adding (differently configured)
components to the Jig config. This would benefit from being able to
initialize and start components in parallel, where possible. Unlike
cljsbuild, Jig components are started serially, in reverse dependency
order. Does anyone know of existing algorithms that can walk a dependency
tree in parallel?
Feel free to take Jig in different directions though, I'm just letting you
know my current thoughts. The single REPL to multiple projects idea might
have to be rethought - it seems the prevailing wind is in the direction of
multiple REPL connections per editor/IDE.
On Thursday, 7 November 2013 01:09:53 UTC, frye wrote:
Too right.
Yes, wrt the multi-project / classpath thing, running isolated test for a
particular project is only one aspect. I also have an eye to running a i)
browser-connected repl and ii) debugger for a particular project. So those
things, along with iii) running tests, make very high, the attractiveness
of having that isolation.
I'll try to put those in github issues. And also pick at the problem
myself when I get some cycles. I think it would add a powerful feature to
the tool. Anyways... :)
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Tue, Nov 5, 2013 at 4:33 AM, Malcolm Sparks mal...@juxt.projavascript:
wrote:
Hi Tim,
The tests in JUXT accounting are using clojure.core.test. I'm fairly sure
Midje's :autotest feature does something dynamic to determine the tests to
run and that may not work with Jig's classloading approach. For example, if
something uses (System/getProperty java.class.path) it will just get the
Jig source directories because, for external projects, Jig must load these
using a child class-loader. I need to spend some time with Midje to work
out what it's doing.
Having multiple lein projects loaded in the same JVM, and integrated with
each other, is not a common Clojure mode of usage today. However, the
Immutant team (and others) have done a lot of the groundwork and I think
the various caveats I've listed on Jig's README.md about 'external
projects' are going to be ironed out over time as these issues become
better understood. I expect that Brian never saw this as a use-case.
In the absence of a mailing list right now, please log any issues you see
as GitHub issues and I'll do my best to fix them.
Thanks again for sending in this really useful feedback.
Regards,
Malcolm
On Monday, 4 November 2013 02:53:47 UTC
Re: [ANN] Jig
Hi Tim,
Thanks for the great feedback, it's really useful.
I've tried to keep the config so that it works out-of-the-box for examples,
but is possible to point at other configurations without mutating the Jig
repo itself. But I see there's more refinements needed.
If you look in jig/src/user.clj you'll see a (config) function - that tries
a number of locations in order to find a config file. For example, it looks
for a .jig/config.clj file before looking in jig/config/config.clj.
Regards,
Malcolm
On Sunday, 3 November 2013 00:18:17 UTC, frye wrote:
Ok, I actually got the compojure example working. I just had to remove the
*config/console.edn* and *config/default.edn* files in my jig. They must
be disrupting the config that I put in. So that's my only feedback so far.
Ok, this is looking really good. Great work :)
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Sat, Nov 2, 2013 at 7:05 PM, Timothy Washington
twas...@gmail.comjavascript:
wrote:
Hey Malcolm,
*A)* Ok, so just playing around with jig some more. I'm looking to get
working *Compojure* and *Pedestal* examples.
*B)* I started with a raw `*git clone g...@github.com:juxt/jig.git*`.
Then in that directory, I ran the commands in blue.
*C)* Now, I run my environment in a Virtual Machine. So when using the
browser to try and go to each of the url end points, I got an *HTTP 404*,
*Not Found* error for all of these URLs. Ie, Compojure and Pedestal
were running, giving me HTTP responses. They just weren't giving me the
advertised endpoints, only 404s. This corresponded errors I was
experiencing when I tried to stitch in one of my simple compojure handlers
in a separate jig. There's probably some small config I'm missing, before
this becomes reeeally useful. Can't wait :)
- http://172.16.210.128:8091/server
- http://172.16.210.128:8001/readme
- http://172.16.210.128:8001
$ *lein repl*
nREPL server started on port 59398 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Welcome to Jig!
(go) -- start the system
(reset)-- reset the system
(refresh) -- recover if a reset fails due to a compilation error
(menu) -- show this menu again
Jig user *(go)*
INFO jig.system - Starting the system
INFO jig.system - Starting component ':test-ring-handler'
INFO jig.system - Starting component ':compojure'
INFO jig.system - Starting component ':jetty'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8091*
INFO jig.system - Starting component ':console/server'
INFO org.eclipse.jetty.server.Server - jetty-8.1.9.v20130131
INFO o.e.jetty.server.AbstractConnector - *Started
SelectChannelConnector@0.0.0.0:8001*
INFO jig.system - Starting component ':console/web'
INFO jig.system - Starting component ':console/readme'
:ready
Jig user INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /web*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /web}
INFO i.p.s.http.impl.servlet-interceptor - {:line 362, :in
:interceptor-service-fn, :context {:servlet #FnServlet
io.pedestal.service.http.servlet.FnServlet@606acc48, :servlet-config
#Config org.eclipse.jetty.servlet.ServletHolder$Config@19017f49,
:servlet-response #Response HTTP/1.1 200
, :servlet-request #Request (*GET /readme*)@1536124838
org.eclipse.jetty.server.Request@5b8f67a6}}
INFO io.pedestal.service.http - {:line 58, :msg GET /readme}
Tim Washington
Interruptsoftware.ca http://interruptsoftware.ca/ /
Bkeeping.comhttp://bkeeping.com/
On Sun, Oct 27, 2013 at 4:39 AM, Chris Zheng z...@caudate.mejavascript:
wrote:
Thanks Malcom,
Even something really simple like showing your current project setup
would be really good for me to get going.
On 21/10/2013, at 15:57, Malcolm Sparks mal...@juxt.pro javascript:
wrote:
Hi Chris, yes I will try to do something like that very soon.
On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote:
Would it be possible to put up a video of a typical workflow example
with pedestal. It's
Re: [ANN] Jig
Hi Tim, The tests in JUXT accounting are using clojure.core.test. I'm fairly sure Midje's :autotest feature does something dynamic to determine the tests to run and that may not work with Jig's classloading approach. For example, if something uses (System/getProperty java.class.path) it will just get the Jig source directories because, for external projects, Jig must load these using a child class-loader. I need to spend some time with Midje to work out what it's doing. Having multiple lein projects loaded in the same JVM, and integrated with each other, is not a common Clojure mode of usage today. However, the Immutant team (and others) have done a lot of the groundwork and I think the various caveats I've listed on Jig's README.md about 'external projects' are going to be ironed out over time as these issues become better understood. I expect that Brian never saw this as a use-case. In the absence of a mailing list right now, please log any issues you see as GitHub issues and I'll do my best to fix them. Thanks again for sending in this really useful feedback. Regards, Malcolm On Monday, 4 November 2013 02:53:47 UTC, frye wrote: Ok, some more feedback for Jig. *A)* Testing - Let's say I have a multi-project jig, with dependencies across projects. There doesn't seem to be a way to run tests (midje :autotest) for a specific project. I tried creating a Midje component (see https://www.refheap.com/20442). But when I *i)* put this into config.edn, and *ii)* thread through my local project component, *iii)* this only prints out the classpath directories under the *jig* project. I'll want to be in the Classpath context of the project that's being passed in. That way, I can :autotest for that project. Or perhaps there's another way to run and autorun tests for a particular project. I noticed that Juxt-Accounting https://github.com/juxt/juxt-accounting has a test suite. *B)* Ok, so there's just that and removing the *config/console.edn* and * config/default.edn* files when writing your jig. *C)* And a raw *git clone g...@github.com:juxt/jig.git*, then *lein repl*, then * (go)*, doesn't give working URLs ( http://:8091/readme , http://:8001/server, etc ) Let me know if you want me to log these as bugs, feature requests, etc. Very excited about the kind of leverage that this project can yield. Loving this tool. Thanks. Tim Washington Interruptsoftware.ca http://interruptsoftware.ca/ / Bkeeping.comhttp://bkeeping.com/ On Sat, Nov 2, 2013 at 8:18 PM, Timothy Washington twas...@gmail.comjavascript: wrote: Ok, I actually got the compojure example working. I just had to remove the *config/console.edn* and *config/default.edn* files in my jig. They must be disrupting the config that I put in. So that's my only feedback so far. Ok, this is looking really good. Great work :) Tim Washington Interruptsoftware.ca http://interruptsoftware.ca/ / Bkeeping.comhttp://bkeeping.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Jig
Hi Tim,
I've just pushed Jig 1.2.0 to https://github.com/juxt/jig.
This release adds support for Ring and Compojure, which many people have
asked for, including proper examples of using both Ring/Compojure and
Pedestal services. There are numerous other components included (Git pull,
JMX, nginx) to support an automated continuous deployment process.
As you pointed out, there were missing details in my own work branches, so
the packaged examples should hopefully make things clearer.
Thanks for the feedback on using Jig, it is much appreciated, and please
let me know if you still need some help with the specifics.
Regards,
Malcolm
On Monday, 21 October 2013 21:14:32 UTC+1, frye wrote:
Hey Malcolm,
So since you guys just have Pedestal set up at the moment, I've started
there.
*My Repos *
You can see my project jig
herehttps://github.com/stefonweblog/stefon-jig/blob/master/config/config.clj.
It connects to
commonhttps://github.com/stefonweblog/stefon-webui-common/blob/master/src/stefon_webui_common/core.clj
,
compojurehttps://github.com/stefonweblog/stefon-compojure/blob/master/src/stefon_compojure/core.clj
(not
yet configured), and
pedestal-servicehttps://github.com/stefonweblog/stefon-pedestal-service/blob/master/src/stefon_pedestal_service/service.clj
component.
I'm trying to get the Pedestal portions working. Now, I haven't yet been
able to stitch together routes using the Pedestal :juxtweb/service
component you have. The :server component runs fine, when executing (go).
But the handlers don't seem to be attached. Do I need a separate
:jig/projects entry in my config?
{
:jig/components
{
;; ===
:server {:jig/component jig.web.server/Component
:io.pedestal.service.http/port 8000
:io.pedestal.service.http/type :jetty}
:juxtweb/web {:jig/component jig.web.app/Component
:jig/dependencies [:server]
:jig/scheme :http
:jig/hostname localhost
:jig.web/server :server}
;; ===
:stefon-webui-common {:jig/component stefon-webui-common.core/Component
:jig/project ../stefon-webui-common/project.clj}
:stefon-compojure {:jig/component stefon-compojure.core/Component
:jig/project ../stefon-compojure/project.clj
:jig/dependencies [:server
:stefon-webui-common]}
:stefon-pedestal {:jig/component stefon-pedestal-service.service/Component
:jig/project ../stefon-pedestal-service/project.clj
:jig/dependencies [:juxtweb/web
:stefon-webui-common]
:jig.web/app-name :juxtweb/web}
}}
*Juxt's Cloned Repos *
So I tried cloning your example repos to see working example code. But
there's a few things that went awry.
*A)* I had to rename the cloned repo for the referencing in
jig/config/config.clj to work (:jig/project
../accounting/project.clj).
~/Projects/trial/*JIG*$ ls -la
accounting/ *;; had to `mv juxt-accounting accounting` *
jig/
juxtweb/
*B)* Also, you've hard-coded an accounts db file to your hard drive
*java.io.FileNotFoundException:
/home/malcolm/Dropbox.private/JUXT/accounts.edn*
Tim Washington
Interruptsoftware.ca / Bkeeping.com
On Mon, Oct 21, 2013 at 3:57 AM, Malcolm Sparks mal...@juxt.projavascript:
wrote:
Hi Tim,
Good to hear you're finding Jig useful.
There isn't any explicit support for Ring in Jig yet, it's just Pedestal
services right now. The separation of jig.web.server and jig.web.app into 2
components is to allow multiple 'virtual hosts' to share the same Jetty
server, if necessary.
It's a third component, usually your own, that actually adds routes to a
virtual host. See the ReadmeComponent in
examples/docsite/src/examples/docsite/core.clj
herehttps://github.com/juxt/jig/blob/master/examples/docsite/src/examples/docsite/core.clj#L75.
It adds routes in its init phase.
The idea is that other components can be contribute routes in the same
way, so you have the option of breaking up a website into modules.
The nice thing about Pedestal services is that hyperlinks can be
generated using the url-for functionality it provides. If you use this
feature consistently, you can treat the jig.web.app as an anchor on which
to hook multiple applications and configure the URL tree accordingly. I'm
intrigued by this url-for feature and wanted to experiment with it with Jig.
Since Compojure doesn't have this automatic ability to create links from
handler vars, it's likely you'll want to set it up manually. Here's a
suggestion for how to do this:
1. Create a Ring server component.
2. In the init phase, add an empty vector called :routes. Other
components can depend on this one
Re: [ANN] Jig
Hi Tim,
Good to hear you're finding Jig useful.
There isn't any explicit support for Ring in Jig yet, it's just Pedestal
services right now. The separation of jig.web.server and jig.web.app into 2
components is to allow multiple 'virtual hosts' to share the same Jetty
server, if necessary.
It's a third component, usually your own, that actually adds routes to a
virtual host. See the ReadmeComponent in
examples/docsite/src/examples/docsite/core.clj
herehttps://github.com/juxt/jig/blob/master/examples/docsite/src/examples/docsite/core.clj#L75.
It adds routes in its init phase.
The idea is that other components can be contribute routes in the same way,
so you have the option of breaking up a website into modules.
The nice thing about Pedestal services is that hyperlinks can be generated
using the url-for functionality it provides. If you use this feature
consistently, you can treat the jig.web.app as an anchor on which to hook
multiple applications and configure the URL tree accordingly. I'm intrigued
by this url-for feature and wanted to experiment with it with Jig.
Since Compojure doesn't have this automatic ability to create links from
handler vars, it's likely you'll want to set it up manually. Here's a
suggestion for how to do this:
1. Create a Ring server component.
2. In the init phase, add an empty vector called :routes. Other components
can depend on this one, and in their init phase, they concat their routes
to this vector.
3. Then, in its start phase, the Ring server component composes the routes
together (using Compojure's routes function) and creates and starts the
server, placing the server in the system map so that it can be found and
stopped in its stop phase.
Remember that you don't need to use any reloading tricks described by
Ringhttps://github.com/ring-clojure/ring/wiki/Interactive-Development#iii-manually,
such as passing a var to run-jetty rather than the handler itself. Nor do
you need :reload and any file status detection.
What I really like about Stuart's workflow is that it allows you to do away
with these 'dev versus prod' modes, you just code everything in 'prod' mode
(i.e. there is only one mode) and let the reset handle the dev reload. This
makes code simpler and ensures you are developing and testing what the
users get, not a development 'version' that approximates to it.
Regards,
Malcolm
On Monday, October 21, 2013 1:41:43 AM UTC+1, frye wrote:
Also, is there a Google Group for Jig? I'm playing around with it, can see
the potential, and already have some questions. Anyways, in the meantime,
I'll keep digging. I'm finding jig really useful so far.
*A)* As taken from the example, I'm using the Jetty :server
componenthttps://github.com/juxt/jig/blob/master/config/config.clj#L6.
I'm trying to figure out how to pass in my Compojure route
handlerhttps://github.com/weavejester/compojure-example/blob/master/src/compojure/example/routes.clj
(also
seehttp://weavejester.github.io/compojure/compojure.handler.html#var-site)
to
jetty. This is how its done
manuallyhttps://github.com/ring-clojure/ring/wiki/Interactive-Development#iii-manually.
But obviously, I need to fit that into the jig framework.
:server {:jig/component jig.web.server/Component ;; how do I pass in
my Compojure route handler ?
:io.pedestal.service.http/port 8000
:io.pedestal.service.http/type :jetty
}
*B)* Same thing with Pedestal. I want to be able to pass in my app's
routing table. But I don't quite grok how to do that, from the examples (
here https://github.com/juxt/jig/blob/master/config/config.clj#L28 and
here https://github.com/juxt/jig/blob/master/src/jig/web/app.clj).
:juxtweb/web {:jig/component jig.web.app/Component;; how do I pass in
my routing table of handlers ?
:jig/dependencies [:server]
:jig/scheme :http
:jig/hostname localhost
:jig.web/server :server
}
Thanks
Tim Washington
Interruptsoftware.ca / Bkeeping.com
On Thu, Oct 17, 2013 at 7:30 PM, zcaudate z...@caudate.me
javascript:wrote:
Would it be possible to put up a video of a typical workflow example with
pedestal. It's quite difficult for me to piece everything together just by
reading the documentation.
Chris
--
--
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,
Re: [ANN] Jig
Hi Chris, yes I will try to do something like that very soon. On Friday, October 18, 2013 12:30:20 AM UTC+1, zcaudate wrote: Would it be possible to put up a video of a typical workflow example with pedestal. It's quite difficult for me to piece everything together just by reading the documentation. Chris -- -- 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] Jig
Hi Tim,
Thanks for the feedback.
A. By default, nrepl-jack-in will invoke lein from the directory of the
project that owns the file in the current Emacs buffer. You need to start
Jig from its own project directory, not the project directory of your own
application. Normally I load up Jig's project.clj into an Emacs buffer, run
nrepl-jack-in from there, and then type (go) in the repl buffer that
appears. Alternatively you can type 'lein repl' from the Jig repo directory.
B. This is my mistake. An earlier version of jig used :components while the
current version uses :jig/components. I forgot to update the
sample.config.edn file. This is now fixed on master.
Everything else you've done looks OK to me.
I keep my own working config for stuff I'm currently running in Jig on a
branch (juxtweb), treat it as a working example until I have documented
this area more fully:
https://github.com/juxt/jig/blob/juxtweb/config/config.clj
Regards,
Malcolm
On Monday, 14 October 2013 18:07:38 UTC+1, frye wrote:
This looks really cool. A few things.
*A)* Looks like I have to run nrepl in the jig project directory. I'm
finding that emacs also has to be started in the same jig directory. Then
all of my code editing has to be referenced from that directory (ie: *C-x
C-f ../my-project/my-file.clj*). If I try to run emacs in my-project,
then *M-x repl*, I get the below error. Is there a way around this?
... in *Messages*
Connecting to nREPL on 127.0.0.1:4555...
open-network-stream: make client process failed: connection refused,
:name, nrepl, :buffer, *nrepl-connection*, :host, 127.0.0.1, :service,
4555, :nowait, nil
... in emacs' minibuffer line
*make client process failed: connection refused, :name, nrepl, :buffer,
*nrepl-connection*, :host, 127.0.0.1, :service, 4555, :nowait, nil *
*B)* I'm trying to wire up an external project, but getting a
NullPointerException when calling *(go)*. I'm following the
usagehttps://github.com/juxt/jig#usageinstructions, and guide for external
projects https://github.com/juxt/jig#external-projects. Is there
something obvious that I'm missing?
~/Projects/jig$ lein repl
nREPL server started on port 33095 on host 127.0.0.1
REPL-y 0.2.1
Clojure 1.5.1
Welcome to Jig!
(go) -- start the system
(reset)-- reset the system
(refresh) -- recover if a reset fails due to a compilation error
(menu) -- show this menu again
*Jig user (go)*
*NullPointerException clojure.core/val (core.clj:1489)*
Jig user (pst *e)
*NullPointerException *
*clojure.core/val (core.clj:1489)*
*loom.graph/build-graph/build--1546 (graph.clj:411)*
*clojure.core.protocols/fn--6037 (protocols.clj:127)*
*clojure.core.protocols/fn--6005/G--6000--6014 (protocols.clj:19)*
*clojure.core.protocols/seq-reduce (protocols.clj:31)*
*clojure.core.protocols/fn--6028 (protocols.clj:48)*
*clojure.core.protocols/fn--5979/G--5974--5992 (protocols.clj:13)*
*clojure.core/reduce (core.clj:6177)*
*loom.graph/build-graph (graph.clj:425)*
*clojure.core/apply (core.clj:619)*
*loom.graph/digraph (graph.clj:437)*
*jig.system/get-digraph (system.clj:87)*
nil
*fig.1 - shell error output *
{:components
{:recordo {:jig/component org.recordo.core/Component
:jig/project ../recordo/project.clj}}}
*fig.2 - jig/config/config.edn*
(ns recordo.core
(:import (jig Lifecycle)))
;; A Jig Component
(deftype Component [config]
Lifecycle
(init [_ system] system)
(start [_ system] system)
(stop [_ system] system))
*fig.3 - recordo/src/recordo/core.clj; ... recordo's project.clj has no
mention of **jig***
Cheers - great work.
Tim Washington
Interruptsoftware.ca / Bkeeping.com
On Fri, Oct 11, 2013 at 12:23 PM, Malcolm Sparks mal...@juxt.projavascript:
wrote:
A few months ago, Stuart Sierra blogged about the workflow he follows for
building Clojure applications.
One of the great pleasures of working with a dynamic language is being
able to build a system while simultaneously interacting with it.
-- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded
Since then I've been using this workflow for my own projects, and found
it to be amazingly effective.
I've added some extra features, and the result is Jig, which builds on
Stuart's work in the following ways :-
- Multiple components can each contribute to the 'system' map
- Components are started in dependency order
- Components are specified and configured in a config (edn) file
- Jig can host 'plain old' Leiningen projects - Jig will even
'reload' them too e.g. if their project.clj dependencies change.
- Jig can host multiple projects simultaneously
There's a small but growing list of optional re-usable components that
provide extra functionality :-
- Pedestal services support. Jig provides
Re: [ANN] Jig
On Sunday, 13 October 2013 01:21:40 UTC+1, Manuel Paccagnella wrote: Looks very interesting, thanks for sharing! BTW, documentation is impressive and quite comprehensive. On a related note: I've spotted a couple of typos in your README.md so far. Do you accept pull requests for small fixes like these? Yes please! -- -- 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.
[ANN] Jig
A few months ago, Stuart Sierra blogged about the workflow he follows for building Clojure applications. One of the great pleasures of working with a dynamic language is being able to build a system while simultaneously interacting with it. -- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded Since then I've been using this workflow for my own projects, and found it to be amazingly effective. I've added some extra features, and the result is Jig, which builds on Stuart's work in the following ways :- - Multiple components can each contribute to the 'system' map - Components are started in dependency order - Components are specified and configured in a config (edn) file - Jig can host 'plain old' Leiningen projects - Jig will even 'reload' them too e.g. if their project.clj dependencies change. - Jig can host multiple projects simultaneously There's a small but growing list of optional re-usable components that provide extra functionality :- - Pedestal services support. Jig provides the system map and 'url-for' function in the service context. - Nginx cache purging on reload - Git pull prior reload - Reload via JMX - nREPL - Stencil cache purging - Firefox remote control support for 'browser refresh on reload' I know others are working on similar designs. I'd be interested to hear what people think and whether this is useful. Thanks, Malcolm PS: Jig can be found here: https://github.com/juxt/jig -- -- 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: [GSoC] Clojure refactoring library and integration in Counterclockwise
Michael, There are some pre-existing libraries that could give you a headstart in this work :- tools.reader - can help you parse Clojure source - https://github.com/clojure/tools.reader tools.namespace can help you parse and manage graphs of namespaces - https://github.com/clojure/tools.namespace tools.analyzer can help you resolve symbols - https://github.com/clojure/jvm.tools.analyzer kibit - can help you detect non-idiomatic code - https://github.com/jonase/kibit Each of these is in active development but you should consider using them in their current state if you can. Regards, Malcolm On Thursday, 18 April 2013 07:52:57 UTC+1, Mikera wrote: On Tuesday, 9 April 2013 00:05:35 UTC+8, michael holzer wrote: And now to the part that will be hopefully of broader interest for every Clojure user: What do you expect from a refactoring library or from an IDE providing refactoring tools? There are a bunch of operations that would be very useful to support: rename var, fix namespace aliases etc. all the usual stuff. But more important than the actual refactoring operations are IMHO the warnings that the IDE provides. Refactoring activity often causes you to break previously true assumptions (e.g. changing the arity of a function by adding a new parameter, or changing the type of a parameter). Automatically detecting these and providing a warning would be a huge boost to productivity: Otherwise you will only detect the problem when something fails at runtime / test time and you might get left with a particularly nasty stack trace to debug. I wrote a bit more on this topic in an old blog post you may find interesting: http://clojurefun.wordpress.com/2012/09/06/something-i-still-love-about-java/ Apart from that, I think there is some interesting Clojure specific refactoring you might do, e.g. warn on unidiomatic style and offer conversion to a better alternative. I'm thinking of things like: (let [a (some-condition)] (if a (do ...))) = (when-let [a (some-condition)] ..) -- -- 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: Full stack Clojure web/REST framework - is there any mileage in it?
The Clojure tradition of mixing-and-matching small libraries rather than relying on large frameworks like Spring did not emerge by accident. The Java language itself causes library authors to create their own types thereby creating an impedance mismatch with other libraries. Spring (and similar frameworks) have evolved to address these issues, using clever design patterns such as interface adaptation. In contrast, Clojure libraries simply use common data structures (maps, sequences, sets) and Clojure itself has all the functions to convert between them where necessary. The result is that *Clojure libraries integrate with each other relatively seamlessly without the need for frameworks like Spring*. In other words, the very existence of Spring and other 'compendium' frameworks in the Java world is evidence that a lot of work is required to get Java libraries to work together. The absence of equivalents in the Clojure world is something that we should be very happy about. When you choose a compendium framework, you have to work with whatever libraries have been chosen for you by the framework provider, and hope that the doors you want to walk through are unlocked prior to your arrival. All too often they are not. I've long felt that large platforms like Spring, Eclipse and even the JDK itself are a trade-off between the benefits of ease-of-use with the *sacrifice of future innovation* - platforms give incumbent libraries a *premature monopoly* on a functional area, thereby stifling competition from a potential worthy successor library. What I like about the Clojure eco-system is that, to a large extent, no such monopolies have emerged, there is a truer meritocracy because it is possible for libraries to emerge that provide a better or alternative approach to existing ones - so Ring, Aleph, Hiccup, Enlive, Compojure, Moustache and Liberator (to name but a few) can all peacefully co-exist. Innovative new libraries crop up all the time - so quickly it's almost hard to keep up! In which case, we shouldn't confuse frameworks with simple collections of libraries that some curator has verified work together. This is akin to the function that GNU/Linux distributions perform and there is definite value, especially for beginners, in the community shaping these collections. On Friday, 11 January 2013 16:52:05 UTC, 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
Re: Parsing Clojure code in Clojure?
Jozef, sjacket turns out to be better suited for my purposes because tools.reader (blind) is just a reader and throws away formatting and comments, since I want the source intact Christophe's parser (within sjacket) is ideal, so thanks for the tip! Ideally a future tools.reader would have the option to retain formatting and comments, even those these are 'not so homoiconic'. I see the capability to use Clojure to manage (and manipulate) Clojure source code to be a huge advantage when Clojure source bases become larger - the problems you run into with large Clojure code-bases are different from Java ones, but there all the same. Regards, Malcolm On Thursday, December 27, 2012 10:45:26 PM UTC, Jozef Wagner wrote: This may also help https://github.com/cgrand/sjacket On Thursday, December 27, 2012 9:32:10 PM UTC+1, Malcolm Sparks wrote: Thanks David, that was just the library I was looking for :) On 27 Dec 2012 20:22, David Nolen dnolen...@gmail.com wrote: https://github.com/Bronsa/blind This library is on its way to becoming a part of contrib as tools.reader David On Thu, Dec 27, 2012 at 3:17 PM, Malcolm Sparks mal...@congreve.comwrote: Hi, I need to parse Clojure code for purposes of code-insights, web presentation with hyperlinks between symbols, potential re-factoring, dead namespace illumination, visualization and inspection of increasingly large Clojure code-bases, code-style and compliance violation monitoring, that kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- 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 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 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
Parsing Clojure code in Clojure?
Hi, I need to parse Clojure code for purposes of code-insights, web presentation with hyperlinks between symbols, potential re-factoring, dead namespace illumination, visualization and inspection of increasingly large Clojure code-bases, code-style and compliance violation monitoring, that kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- 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: Parsing Clojure code in Clojure?
Thanks David, that was just the library I was looking for :) On 27 Dec 2012 20:22, David Nolen dnolen.li...@gmail.com wrote: https://github.com/Bronsa/blind This library is on its way to becoming a part of contrib as tools.reader David On Thu, Dec 27, 2012 at 3:17 PM, Malcolm Sparks malc...@congreve.comwrote: Hi, I need to parse Clojure code for purposes of code-insights, web presentation with hyperlinks between symbols, potential re-factoring, dead namespace illumination, visualization and inspection of increasingly large Clojure code-bases, code-style and compliance violation monitoring, that kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- 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 -- 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: Attractive examples of function-generating functions
On Wednesday, August 8, 2012 7:48:23 PM UTC+3, Brian Marick wrote: I'm looking for medium-scale examples of using function-generating functions. Brian, when I saw this I was reminded of ring middleware - eg. http://jgre.org/2010/10/04/ring-middleware/ -- 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
