[ANN] Clojure 1.9.0-alpha20
Are there any plans to make the ## reader macro extensible in the future? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: remote - DSL for clj-http/cljs-http
Are you tired of writing the same clj-http/cljs-https boilerplate? Looking for an easy way to express an endpoint or a service API? Then remote is the library for you! Github: https://github.com/outpace/remote Leiningen: [com.outpace/remote 0.3.1] This library has been closed source up until now and by popular demand has been made available to the public. On behalf of the Outpace staff and myself we hope you or your team find this library useful. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
On Saturday, April 11, 2015 at 8:40:07 AM UTC-7, kovas boguta wrote: On Sat, Apr 11, 2015 at 10:46 AM, Malcolm Sparks mal...@juxt.pro 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. I'm on board with most of this post (and the Bidi approach in particular), I'm not sure consensus is necessary but I'll throw in my 2 cents. - Please, no more defroute etc macros - Routing should be composable. I want to take some routes and just plug them in at some level of my existing hierarchy. - Middleware should be decoupled from the routes as much as possible. The process for associating middleware to the request should be parallel/complementary to resolving the resource. Maybe middleware is not the best concept to begin with. I'm definitely in agreement that the approach Bidi and Silk have taken is much better than what exists on master in Secretary. Most of the undesirable aspects pointed out about Secretary have largely been resolved on the 2.0.0 branch for Secretary. The other desirable qualities found in Silk (unsure about Bidi) have been in existence in Secretary for sometime but the library was not oriented properly to make those features idiomatic. I do not agree that defroute etc macros should be eliminated from the picture. There is nothing inherently wrong with authoring and/or encouraging their use. It is only an issue when those macros are the only way to use a library effectively. People enjoy using DSL's (until they hit a wall with them) and for small to medium scale projects they are completely appropriate and just as effective as the it's just data style of routing for getting shit done. I will also say the same about middleware. Although I do not like the middleware pattern I do not believe it is worth throwing out the window just because it is not the best concept. It is a familiar pattern and sometimes that familiarity is worth avoiding the friction of learning a something else for some individuals and teams. tl;dr retaining features that people enjoy using and are familiar with is fine so long as there is a composable API underneath it that can be used alternatively. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Too many words written on referential transparency in Clojure and Haskell
Speaking of definitions of equality: Writing a university project jvm to llvm 'compiler', I found myself designing a type in Haskell whose Ord and Eq instances 'naturally' got defined in such a way that less than AND equal to made sense. I doubt anyone's sanity except mine survived the project. Joel On Wed, Apr 22, 2015 at 6:25 PM, Maik Schünemann maikschuenem...@gmail.com wrote: Andy Fingerhut andy.finger...@gmail.com writes: Dave, you say seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. I think I would instead say: seq *is* a pure function, even though it violates the property of x equals y implies f(x) equals f(y). There is nothing impure about the definition of seq on sets. I would say that it is the way equals is defined on hash sets, intentionally ignoring internal implementation details that are visible to seq, that leads to the violation of that property. I have updated my article with a Conclusion section since yesterday. I have copied it below for those that have already read the article and want to see only the new stuff: In hindsight after writing this, it now seems clear to me that if one wants to maintain the property x is equal to y implies f(x) is equal to f(y) for all functions f, then it is pretty important to be clear on what equal means. As a silly example, if one gets to define their own equals for lists, and you decide to define lists as equal if they contain the same number of items, e.g. the list (1 2 3) is equal to the list (4 5 6) because they both have 3 items, then you are easily going to violate the property. another example is that in clojure '(2) is equal to [2] - and this is a good thing, but (conj '(2) 3) is not equal to (conj [2] 3). so I agree that the property x = y = f(x) = f(y) is not reasonable for normal equality. It could be for pure functions and identical? Example 3 highlights this point: one can create implementations of data structures using only pure functions, and a 'reasonable' definition of equality, where the property can be violated. The root of this issue is: sometimes reasonable definitions of equality regard two values as equal, intentionally ignoring internal implementation details of the data structure, but those differences ignored by equal can be made observable by other functions you implement on the data structure (like `seq` / `toList`). Andy On Wed, Apr 22, 2015 at 1:22 AM, Dave Sann daves...@gmail.com wrote: x is equal to y to imply f(x) is equal to f(y) - can only be true where a function is really based only on its arguments. I hadn't considered this before - while it seems simple, it is also a bit subtle. for example: seq on a set cannot be pure unless you were to provide an argument to explicitly specify which order the items should be in. If you do not do this, the order is defined either by some random interaction of the of the data and function implementations - that you thought was irrelevant - or has to be literally picked at random by the implementation. The former of these will appear to be pure until you hit the special cases. I speculate that only functions that retain or reduce the information content of their inputs can be pure. So if you rearrange or filter or map they can be pure. But if you *implicitly* add new information - as (seq set) does - then they cannot be. Dave On Wednesday, 22 April 2015 15:28:30 UTC+10, Andy Fingerhut wrote: One thing I was surprised by in my investigation was the lengths that some people are willing to go to in order to avoid such things. Some people seem to *really* want the property x is equal to y to imply f(x) is equal to f(y) for all functions, without exception, and consider it a bug if a single function violates that property. I'm personally on the side of violating it if there is no good way to keep it true for a particular function, preferably with documentation if you are aware that you are not preserving it. Andy On Tue, Apr 21, 2015 at 8:32 PM, Dave Sann dave...@gmail.com wrote: Just to expand on this slightly - seq applied to a set must introduce an order that is not present in the set. This order in principle comes from nowhere in the data. But it does in practice come from some arbitrary decisions in the implementation. Maybe this was andy's point. On Wednesday, 22 April 2015 13:18:43 UTC+10, Dave Sann wrote: Agree it's an interesting writeup. I think that the behaviour of seq should be entirely expected though. Sets have no ordering (logically) so turning them into an ordered sequence should be considered to be an entirely arbitrary operation (unless specific guarantees are provided). The fact that the implementations sometimes maintain an order should not be used or relied upon at all. a seq
Re: State of Clojure/ClojureScript 2014 survey results
On Thursday, October 23, 2014 8:59:21 AM UTC-7, Alex Miller wrote: I've published links to the State of Clojure and ClojureScript 2014 survey results here: http://blog.cognitect.com/blog/2014/10/20/results-of-2014-state-of-clojure-and-clojurescript-survey That page links to some reports with graphs where you can also export the raw data. I also have links to broken out answers from each of the open text questions for easier consumption. Those are redundant, but perhaps useful. I have not had the time to do any analysis or commentary on these yet. Of particular interest in a few questions are comparisons with prior years which are also linked from the post. Big thanks to everyone that participated - it's invaluable to get this snapshot of the community every year, especially as we grow. Alex I missed the survey but I'm curious; why was there no response bubble for Error Messages in the What has been most frustrating... section. It is apparent from scanning the responses debugging and error messages are a source of pain for many developers. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
I'm in agreement that Silk is a step in the right direction. I've reached out to Dom and I think we can learn a lot from each other and work together to improve the routing story in Clojure overall. There are some really good things in secretary. What do you think about them? Splat, regex, format matchers. protocol based render function for multiple arity unmatching. this is really great. These are definitely nice things and I'm willing to bet Silk would be capable of supporting some of them. It's obvious to me to that if we can iron out the details with Silk, Secretary could built on top of it as a higher level interface while at the same time taking advantage of what Silk has to offer. It might mean some breaking changes in Secretary but those were already slated anyway. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Dom, We’re actually well aware of many of the flaws you have pointed out with Secretary. In fact, we even have open issues for some of them. While I value all of these features that Secretary lacks, I think that last one, impurity, is the most significant... Mutation is always possible, but uncontrolled mutation is frowned upon and intentionally difficult It is not as if we don’t understand the benefits of immutability or know Clojure idioms. There’s no need to school anyone. We're not n00bs here. :-) When I became a committer to the library I did what I could to improve what was already there. Personally, I do not like the overly complex macro that we have nor do I like the global state. These are just implementation details and it wouldn’t require too much effort to switch to something that’s immutable with a minimum amount of breaking change. We already have several vanilla functions for adding/removing routes that could easily be made stateless. The three of us (myself, Gianni, and Joel) have been busy and just haven’t had the chance to fix it. Anyway, you’ve done a great job enumerating your reasons for writing Silk and flaws about Secretary; some of it is accurate, some of it is misguided. I’m not going to return fire by addressing them because I don’t think it will make much of a difference. Really, what we need to do is work together. We can continue this discussion elsewhere. Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
Bidirectional routes are indeed especially important to render and dispatch routes in Om etc. In secretary its a bit awkward since you have to write stuff like (defroute front-page / [] :front-page) and then a separate thingie for matching the keywords back to the routes. We have written several Om applications at work and this style of routing has never been a source of problems. The `defroute` macros does , perhaps unfortunately, provide the dual concern of adding a route to the global routes (which we plan to remove) and, optionally, giving you a route generator function if you name it (which we'll probably keep). We added this additional option because we felt that these two concerns came up frequently enough in the same context that it should just be convenient to do them at the same time. That is to say, every time we created a route we would have a function for generating a url to go with it. On the other hand secretary will probably serve non-React apps well with its dispatch actions when you dont have React lifecycle methods. I think this observation is a bit misguided. We have actually found Secretary to be solid in practice and that it works *very* well with Om and React. If you interpret route changes as a top level state transition this becomes easy to recognize. Each of our routing functions returns all of the data necessary to transition the app to the next state such as route parameters, view name, etc. Since secretary/dispatch! returns the result of the routing function, we can pass that data to a transition function which handles the actual mutation of the global application state. Each view name is mapped to a component which then receives the application state, so and so forth. This allows us to treat each of our main views as if they were pages (except much better, of course). This actually fits in with the lifecycle perfectly because the mounting/unmounting for a view component can be thought of as visiting and leaving a page. It works out nicely for situations like route and query parameter changes. tl;dr an Om and Secretary combination does work. In fact, our routes.cljs (where we defroute) and history.cljs (where we dispatch!) are files we rarely edit because this design works without much fuss. To recap the pattern for this looks like: (Google History) hash change token → dispatch! → data → transition! (Om) In conclusion, I would argue that the choices you make about how you manipulate your application state will have more consequences than the routing library you choose. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Awesome work. It's fantastic to see a library that's interested in targeting both the front-end and the back-end. This is the type of attitude I would love to see more often in the Clojure community. OTOH, it would have been awesome to have heard your thoughts WRT the concept of isomorphic routing on the Secretary issue tracker. You said you couldn't find something suitable, why didn't you complain or suggest a patch? We would have been happy to have supported your endeavor in making that possible and your ideas. In fact, we would have been willing to make breaking changes for them! Many of us want this! Originally, several people - myself included - were interested in seeing Clout be the library that everyone used both on the client and on the server. Unfortunately, James never merged the pull requests (two of them) for ClojureScript support. AFAICT it was because he wasn't clear on the role it would serve. James is also a busy man. :-) I'm not trying to call you out; the work you have done is fantastic (there's already a few things I'd like to steal!). Rather, I am trying to bring up a more important issue within our community WRT this topic: routing. We now have at least 4 libraries designed for this task (most of them targeting the server). We should not burden the community with dozens of choices. Instead we should enrich the community by working together to improve it. Fewer, well designed choices surely outweigh many okay solutions. So enough talk. Personally, I would love to work together on the issue of an isomorphic router. Secretary is a well known choice for the client and I think together we could make it better by supporting the server. We have three core team members on Secretary, and speaking for the team, I think we would love to bring an end to this saturation of routers in the ClojureScript world. Would you be interested in joining our team and help us work toward this goal? I don't mean to put you on the spot publicly but this is, partly, a public NIH issue and a tweet won't hold this. Email me privately if you desire. :-) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
Edit: s/\(routers in the Clojure\)Script/\1 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: ClojureScript 0.0-2227
On Thursday, May 22, 2014 8:18:06 AM UTC-7, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2227 Leiningen dependency information: [org.clojure/clojurescript 0.0-2227] Enhancements * optimized case * CLJS-802: Add :pseudo-names compiler option * CLJS-795: 10X performance enchancement for multimethods * CLJS-801: str macro emits unoptimizable js code * CLJS-656: search classpath for goog-style JavaScript dependencies Fixes - * CLJS-792: Implement IReduce on PersistentArrayMap * CLJS-804: Binding *print-length* breaks str * CLJS-775: Fix cljs.reader cljs.reader parses radix form of int literals * CLJS-805: add-watch returns map of watch fns instead of watched reference * CLJS-787: cljs.reader does not read blank string as nil * CLJS-784: Fix *Map.-conj for map-entry seqs, that don't implement INext * CLJS-784: make conj on maps behave as it does in Clojure * CLJS-793: fix memoize (non-truthy values don't get cached) * CLJS-800: PersistentQueueSeq extended to IPrintWithWriter Awesome! Don't forget to update the README! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Garden 1.1.7
Garden, a library for authoring stylesheets in Clojure and ClojureScript, is now 1.1.7. ADDED: Support for :preamble IMPROVED: Support for meta data in garden.def/* macros https://github.com/noprompt/garden -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] core.async (and more) video tutorials
Zippers might be another good topic. They ship with Clojure and are a bit mystical to folks who are curious but don't know how to get started. On Wednesday, May 21, 2014 3:32:55 PM UTC-7, tbc++ wrote: From time to time I get asked to do more writing on core.async, and I've come to the realization that try as I might, I'm not a writer. However I recently started a set of video tutorials I'm making available today. The videos average about 12min in length and focus on a single topic. Currently I have 5 videos on core.async completed and two on logic programming. I plan on expanding both series over time. My plans are to release 2-3 videos a week but that may change over time. At any rate, the videos are available here ( https://tbaldridge.pivotshare.com/). Yes, there is a small charge for the majority of the videos, but think of it as a way to prod me to make more tutorials. Thanks! And hopefully this will be useful to some. Timothy Baldridge -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Garden, Thorn - Looking for contributors
I've answered this question numerous times and am convinced I need to write a blog post so I can just drop a link. In general the biggest win is that you can use Clojure and all of the facilities therein to write more sophisticated stylesheets. Large CSS codebases are notoriously hard to manage and require a lot of discipline to get right. If you're not writing a lot of CSS it isn't necessarily a big win. On Tuesday, March 25, 2014 5:42:45 PM UTC-7, Daniel wrote: I wonder what is so bad about pure CSS. Don't get me wrong - I do appreciate projects like these. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Garden, Thorn - Looking for contributors
Thanks! I'll be in touch. On Tuesday, March 25, 2014 1:54:23 PM UTC-7, Alan Moore wrote: Joel, Count me in... You can contact me offline at kahunamoore a/t coopsource d/o\t org Thanks for this library! Alan On Tuesday, March 25, 2014 12:33:15 PM UTC-7, Julien wrote: Hi Joel, thanks for your great work on garden! Definitively helping me every day. Can you share what you have in mind regarding CSSOM integration? It certainly opens cool perspective and I'm curious how you see it fit with garden. I would be interested in giving you a hand here. Maybe a github issue would help start discussions? Julien Le samedi 22 mars 2014 22:41:04 UTC-3, Joel Holdbrooks a écrit : Greetings everyone, About a year ago I began working on Garden and in the short time the library has been around it's grown a bit. Although many folks seem to be interested in it, there's certainly not as much adoption of the library as I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be the default choices for many people writing web applications in Clojure. This is something I'd like to change... but I need *your* help! No, no. Put down the phone. Don't look for a KickStarter URL. It's nothing like that. How you can help Garden I'm looking for individuals who are interested in the following: - improving the compiler code - improving/extending existing API's - building an interface to the CSSOM I'm also open to good 'ol fashioned suggestions, pain points you've experienced using the library, or flat out letting me know what it would take to get you to choose Garden over the alternatives for your next project. How you can help Thorn Thorn is very young project and has no official release yet. So what is it? At the moment it's the beginnings of a Sass Parse Tree transformer; something that will take CSS/SCSS/Sass code and give you Garden code. There's a lot of fabulous libraries available in Sass and I'm sure it's a big factor when choosing how to go about CSS generation. I'm looking for individuals who are interested in the following: - accurately transforming CSS/SCSS/Sass to real Clojure code targeting Garden - accurately transforming Less to real Clojure code targeting Garden Why? I deeply believe that being able to author CSS in Clojure or ClojureScript is a key piece to having an extremely compelling story for web application development in Clojure. Being able to *program* CSS and not just *preprocess* is a big advantage over existing tools. Being able to use all of Clojure everywhere has astounding possibilities. If any of this sounds interesting to you please get in contact with me or reply here. I will also be in San Francisco tomorrow until Tuesday for Clojure/West if you'd like to discuss these items in person. Truly, Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Garden, Thorn - Looking for contributors
Greetings everyone, About a year ago I began working on Garden and in the short time the library has been around it's grown a bit. Although many folks seem to be interested in it, there's certainly not as much adoption of the library as I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be the default choices for many people writing web applications in Clojure. This is something I'd like to change... but I need *your* help! No, no. Put down the phone. Don't look for a KickStarter URL. It's nothing like that. How you can help Garden I'm looking for individuals who are interested in the following: - improving the compiler code - improving/extending existing API's - building an interface to the CSSOM I'm also open to good 'ol fashioned suggestions, pain points you've experienced using the library, or flat out letting me know what it would take to get you to choose Garden over the alternatives for your next project. How you can help Thorn Thorn is very young project and has no official release yet. So what is it? At the moment it's the beginnings of a Sass Parse Tree transformer; something that will take CSS/SCSS/Sass code and give you Garden code. There's a lot of fabulous libraries available in Sass and I'm sure it's a big factor when choosing how to go about CSS generation. I'm looking for individuals who are interested in the following: - accurately transforming CSS/SCSS/Sass to real Clojure code targeting Garden - accurately transforming Less to real Clojure code targeting Garden Why? I deeply believe that being able to author CSS in Clojure or ClojureScript is a key piece to having an extremely compelling story for web application development in Clojure. Being able to *program* CSS and not just *preprocess* is a big advantage over existing tools. Being able to use all of Clojure everywhere has astounding possibilities. If any of this sounds interesting to you please get in contact with me or reply here. I will also be in San Francisco tomorrow until Tuesday for Clojure/West if you'd like to discuss these items in person. Truly, Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CLJS Advanced Compilation JS Libraries lacking externs
This is brilliant. Thanks for sharing! On Friday, March 14, 2014 5:39:06 PM UTC-7, David Nolen wrote: I've written up an explanation how to make this work http://swannodette.github.io/2014/03/14/externs-got-you-down/ David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CLJS Advanced Compilation JS Libraries lacking externs
I notice you mention: For some JavaScript libraries there is an acceptable workaround Under what circumstances would this not be acceptable? On Friday, March 14, 2014 5:39:06 PM UTC-7, David Nolen wrote: I've written up an explanation how to make this work http://swannodette.github.io/2014/03/14/externs-got-you-down/ David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN: lein-garden 0.1.6
lein-garden the plugin for automatically compiling Garden stylesheets has been updated to version 0.1.6. https://github.com/noprompt/lein-garden This release fixes a bug where an unnecessary exception would be thrown for valid identifiers. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ankha (Om data inspector)
Ankha is a generic data inspector for use with Om. You can use it to interactively view your application's state or any other supported data structure (see README). Learn more here: https://github.com/noprompt/ankha Comments, suggestions, and patches welcome. Expect more features to come. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: om-sync
I'm interested in this thread, it does seem however that DerbyJS is farther ahead in this type of work though. I was looking for a similar JVM stack, but not sure how to put it together as well. Atmosphere seems like it fits for the basic communication even including pubsub. Derby updates the view through OT (operational transforms), with types for both JSON and for Text. The code could be rewritten to work in Clojure using core.async, etc. I'm not sure how it does views/authorization though, or how does OT work with undo? DerbyJS also seems to have a relatively pluggable system, compared to say, Meteor, but pluggable takes more work and tends to make things more generic. J On Thursday, February 20, 2014 3:19:55 PM UTC-6, Alexander Hudek wrote: (Dave and I work together). I suspect it will be easy to come to a reasonable license. My own preferences would be EPL or MIT, and EPL only because it's common in the community. Beyond that, something like chord isn't actually the big problem in a scheme like this. The real issue is ensuring that data replication is reliable. Here are the main pain points we've identified so far: 1. Updating a view on the client should update the source data. This is called the view update problem and is fantastically difficult to solve. There are lots of publications on this (e.g. http://www.ijcte.org/papers/278-D038.pdf). I would recommend that we punt on the problem for the near term and settle for explicit update/insert/delete actions. 2. SQL, keystore (nosql), datalog (datomic). We are approaching this from the SQL perspective. You would define and name a view on the server along with it's sql. Clients would then be able to register to have a view be mapped to an atom and kept up-to-date. Presumably a keystore can be treated conceptually as a single table. I haven't thought about what a view would mean for datomic, nor how to keep one up-to-date. 3. Keeping the views up-to-date. This is the hardest part. Here we want all the client views to be automatically updated, and to be consistent with the source data. There can be some amount of time lag between when the source data is updated and when the view is updated. We've worked out some ways to do this for a subset of SQL queries (including joins). It does require that queries are given in something like honeysql though. To compute update deltas for views you need to do some manipulation of the original query. The other part of this is making sure that view delta updates arrive in the right order. This becomes especially important when you have a multi-server setup (e.g. high availability or load balancing). It's the same problem that all the distributed databases need to solve. The only reasonable solution we've thought of is to linearize the updates via a single write transactor mechanism. This would likely also need to be pluggable: some people will want something simple such as a thread in a single server, others will need something heavier such as a service sitting on an internal node with a traditional tcp/ip interface. This doesn't seem ideal, but I don't know of any better way at the moment. I'm not sure that things like vector clocks would work for all data sources. 3.5 Pluggable communications layer. This is where chord fits. But it could also be handled by amqp, browserchannel, or other things. It's reasonable to use core.async as part of the pluggable interface. 4. Error handling, recovery, security. The security aspect definitely needs to be a pluggable component. On Thursday, February 20, 2014 1:52:19 AM UTC-5, Mikera wrote: On Thursday, 20 February 2014 13:56:29 UTC+8, David Della Costa wrote: It's not clear to me that the server side should be tied to Om specifically. It seems like the requirement is more to have a server component that can pass messages / state changes in a generic way to clients (probably using core.async channels, with the ability to use websockets etc. as the underlying transport). This server component would be useful for all kinds of clients (not just Om, not just Clojurescript, maybe even other server systems). I've hacked some stuff together that does this kind of thing for specific projects, but it would be nice to get a solid standard library in the ecosystem for this. We have a concrete need for a system like this and in fact already have a prototype in production (which uses browserchannel as opposed to websockets, but these should be interchangeable) with ampq messaging and http wrapped in core.async and Om on the front-end, but we are working through some issues relating to scaling while providing eventual consistency across a number of web front-ends. The end goal is essentially materialized views in the client. We would also be very interested in working with other folks to provide something with general applicability to
Re: pretty-exception middleware for ring
This is another fantastic idea. I'd definitely love to expand on this technique. Great work! On Thursday, February 13, 2014 8:39:58 AM UTC-8, bob wrote: Hey, a simple exception middle-ware for ring, maybe useful for some,maybe none. it catch exceptions and print, meanwhile the source code produced the exception will be print as well. - The demo will stay here (click me)http://red-raiseup.rhcloud.com/notes/abc . - The source code is herehttps://github.com/weejulius/raiseup/blob/master/src/ring/middleware/pretty_exception.clj . -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: hooks on namespace required/loaded
I know we talked a bit about this in IRC but this is a hack you could use to slurp the file's contents into a string in that file: (ns foo.core (:refer-clojure :exclude [slurp])) (defmacro slurp [file] (clojure.core/slurp file)) ;; In CLJS (ns bar.core (:require [foo.core :include-macros true :refer [slurp]])) ;; This is possible because we can evaluate *Clojure* code at compile time. (def project-clj (slurp project.clj)) From there you could then use read-string, or what have you, and examine the contents. Here's a link to the gist for reference: https://gist.github.com/noprompt/9086232. On Tuesday, February 18, 2014 8:32:05 PM UTC-8, t x wrote: Hi, Although solutions not involving cljx are perfectly fine, I'm using cljx -- so solutions that involves hooking into cljx are perfectly fine too. I have my own poor-man's lint / type checker (with different objectives from core.typed). I want a certain function (call it CHECKER) to be called every time a namespace has been required / loaded / reloaded Every time I require/load/reload a namespace, I want the following to happen: (CHECKER ... source code of the namesapce) i.e. something like (CHECKER (read-string namesapce-just-loaded.clj)) Then, if CHECKER throws an exception, it should be a compile error. If CHECKER prints stuff out, it should go into the lein repl stdout, and if CHECKER doesn't do anything, it's assumed that the namespace passed the check. Is there a minimal example somewhere of how this works? (i.e. something as stupid as: this example calls a function, which just prints out the name of all functions defined would be extremely helpful). 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: [ANN] Clojure 1.6.0-beta1
That’s fair. On February 15, 2014 at 1:02:43 PM, Alex Miller (a...@puredanger.com) wrote: truthy? = identity falsey? = not -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/tseJgAi3HC4/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] Clojure 1.6.0-beta1
Actually, truthy? = boolean. Anyway, throw everything I said in the trash. :-) No more sleepy posts to the ML from me. On February 15, 2014 at 1:02:43 PM, Alex Miller (a...@puredanger.com) wrote: truthy? = identity falsey? = not -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/tseJgAi3HC4/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: Om 0.4.0
On Friday, February 14, 2014 5:00:10 AM UTC-8, Tatu Tarvainen wrote: Btw, I seem to get the following compiler errors after upgrading om from 0.3.6 to 0.4.0 (clojurescript version is 0.0-2138) WARNING: Use of undeclared Var om.core/specify! at line 570 out\om\core.cljs WARNING: Use of undeclared Var om.core/_ at line 572 out\om\core.cljs WARNING: Use of undeclared Var om.core/tx-data at line 572 out\om\core.cljs WARNING: Use of undeclared Var om.core/root-cursor at line 572 out\om\core.cljs WARNING: Use of undeclared Var om.core/tx-data at line 574 out\om\core.cljs WARNING: Use of undeclared Var om.core/root-cursor at line 574 out\om\core.cljs WARNING: Wrong number of args (2) passed to om.core/-notify at line 572 out\om\core.cljs You might want to try running lein cljsbuild clean. Normally, those sorts of messages appear whenever I forget to clean and rebuild after upgrading dependencies. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Clojure 1.6.0-beta1
As an addendum to my last comment, *not-nil?* would also be a good candidate. That really doesn't leave room for doubt. This: (some? false) ;; = true Would confuse me. On the other hand this: (not-nil? false) ;; = true Would not. There's really no need to complicate the naming story here. It's also easy to remember! On Friday, February 14, 2014 3:25:36 PM UTC-8, Alex Miller wrote: On Friday, February 14, 2014 2:27:49 PM UTC-6, DomKM wrote: Great changes! I have a question about #5. 5) New some operations Many conditional functions rely on logical truth (where falsey values are nil or false). Sometimes it is useful to have functions that rely on not nilness instead. These functions have been added to support these cases [CLJ-1343]: * some? - same as (not (nil? x)) * if-some - like if-let, but checks (not (nil? test)) instead of test * when-some - like when-let, but checks (not (nil? test)) instead of test It seems inconsistent to have some mean two very different things within the same namespace, especially since the prior uses of some (`some`, `some-fn`, etc.) are more in keeping with its primary definition of having to do with amount (and operate on seqs or variadic arguments) while the new functions have to do with existence (and operate on any single value). Why not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`? Or, if not-nil is too unwieldy then what about exists (`exists?`, `if-exists`, `when-exists`)? Are these names up for discussion? Hey Dom et al, The names of these functions were chosen by Rich. There was already some name overloading of some even before these new functions with some (truthy) and some-/some- (not nil). The new functions keep with the latter meaning. Many other names were considered, including everything I've seen someone mention (-not-nil, exists, nnil, etc). As far as I know these names are final, however, I will relay all of the feedback I've seen here, on #clojure, and on Twitter to Rich for consideration. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] garden-watch
The idea to watch edn or garden files was a consideration of lein-garden but decided against it because, personally, I felt it was giving up a lot. However, some folks may prefer this approach and, hopefully, it suits them just as well. On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote: Hey Dave, Thanks for that heads up. I originally wanted auto-compiling for *HAML*and *SCSS*. But then thought why, when I could just use edn with *Hiccup* and *Garden*. Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. So *i)* I had to do that work anyways. Then I spent 20 mins replicating the functionality for Garden. Also I think lein-garden tracks edn style definitions, inlined in your existing Clojure code, whereas *ii)* I wanted a separate directory watcher on edn files (no namespaces needed). But there's nothing that says that functionality in garden-watch couldn't be collapsed into lein-garden. It's pretty straightforward code. Tim Washington Interruptsoftware.com http://interruptsoftware.com On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann dave...@gmail.com javascript: wrote: FYI, I think lein garden does this already. is there a particular difference? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com javascript:wrote: Looks cool. I'll be sure to check it out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] garden-watch
Clojure. On Feb 5, 2014, at 8:42 PM, Timothy Washington twash...@gmail.com wrote: Ok, that's fine. Definitely good to have both ways to tackle the problem. But I'm curious. What do you feel is being given up by watching garden files? Thanks Tim Washington Interruptsoftware.com On Wed, Feb 5, 2014 at 11:04 PM, Joel Holdbrooks cjholdbro...@gmail.com wrote: The idea to watch edn or garden files was a consideration of lein-garden but decided against it because, personally, I felt it was giving up a lot. However, some folks may prefer this approach and, hopefully, it suits them just as well. On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote: Hey Dave, Thanks for that heads up. I originally wanted auto-compiling for HAML and SCSS. But then thought why, when I could just use edn with Hiccup and Garden. Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. So i) I had to do that work anyways. Then I spent 20 mins replicating the functionality for Garden. Also I think lein-garden tracks edn style definitions, inlined in your existing Clojure code, whereas ii) I wanted a separate directory watcher on edn files (no namespaces needed). But there's nothing that says that functionality in garden-watch couldn't be collapsed into lein-garden. It's pretty straightforward code. Tim Washington Interruptsoftware.com On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann dave...@gmail.com wrote: FYI, I think lein garden does this already. is there a particular difference? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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/GyKBpfEFkqg/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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Check which project.clj? You posted a link to lien-garden. Am I missing something here? On Wednesday, February 5, 2014 8:29:35 PM UTC-8, Atamert Ölçgen wrote: I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks cjhold...@gmail.comjavascript: wrote: Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Oh, hey, thanks. I didn't catch that. Great copy/paste fail, eh. Maybe next time post an issue to the Github. :-) On Feb 5, 2014, at 8:29 PM, Atamert Ölçgen mu...@muhuk.com wrote: I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks cjholdbro...@gmail.com wrote: Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/FWeIIO2ToGQ/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] clj-refactor.el 0.10.0
Slam dunk! Looking forward to trying this out.
On Thursday, January 30, 2014 5:13:36 AM UTC-8, Magnar Sveen wrote:
clj-refactor.el
Since the last update, there's been lots of activity for
clj-refactor.elhttps://github.com/magnars/clj-refactor.el
. Alex Baranosky https://github.com/AlexBaranosky and Lars
Andersenhttps://github.com/expez have
joined the team, and here are the new features:
More let refactorings
Starting with:
(defn handle-request
(let [body (find-body abc)]
{:status 200
:body body}))
With the cursor in front of 200, I do cljr-move-to-let:
(defn handle-request
(let [body (find-body abc)
X 200]
{:status X
:body body}))
Again I have two cursors where the Xes are, so I type out the name, and
press enter:
(defn handle-request
(let [body (find-body abc)
status 200]
{:status status
:body body}))
Pretty handy. And it works with if-let and when-let too.
*Thread first all, thread last all, unwind all*
Convenience functions to thread all the way down, or unwind the entire
threading macro.
Cycling Privacy
Given this function:
(defn add [a b]
(+ a b))
I do cljr-cycle-privacy:
(defn- add [a b]
(+ a b))
I do cljr-cycle-privacy again to return to the original:
(defn add [a b]
(+ a b))
Given this def:
(def config
docs
{:env staging})
I do cljr-cycle-privacy:
(def ^:private config
docs
{:env staging})
I do cljr-cycle-privacy again to return to the original:
(def config
docs
{:env staging})
https://github.com/magnars/clj-refactor.el#cycling-collection-typeCycling
Collection Type
Given this collection:
(:a 1 :b 2)
I do cljr-cycle-coll to return:
{:a 1 :b 2}
... and then 3 more times:
[:a 1 :b 2]#{:a 1 :b 2}(:a 1 :b 2)
https://github.com/magnars/clj-refactor.el#cycling-between-strings-and-keywordsCycling
Between Strings and Keywords
Given this string:
refactor
I do cljr-cycle-stringlike to return:
:refactor
... and then 3 more times:
refactor:refactorrefactor
Thanks to Jay Fields https://github.com/jaycfields and
emacs-livehttps://github.com/overtone/emacs-live for
these cycling features. Good idea!
Destructuring keys
Given this:
(defn- render-recommendation [rec]
(list [:h3 (:title rec)]
[:p (:by rec)]
[:p (:blurb rec)
(render-link (:link rec))]))
I place the cursor on rec inside [rec] and do cljr-destructure-keys:
(defn- render-recommendation [{:keys [title by blurb link]}]
(list [:h3 title]
[:p by]
[:p blurb
(render-link link)]))
If rec had still been in use, it would have added an :as clause.
For now this feature is limited to top-level symbols in a let form. PR
welcome.
https://github.com/magnars/clj-refactor.el#stop-referringStop referring
Given this:
(ns cljr.core
(:require [my.lib :as lib :refer [a b]]))
(+ (a 1) (b 2))
I place cursor on my.lib and do cljr-stop-referring:
(ns cljr.core
(:require [my.lib :as lib]))
(+ (lib/a 1) (lib/b 2))
https://github.com/magnars/clj-refactor.el#optional-setupEven more
There's also
- cljr-sort-ns to sort the namespace
- cljr-replace-use to replace old :use statements with new :refer
:all statements.
- cljr-add-declaration to declare the defn you're in.
So, clj-refactor.el still knows nothing about your code. At some point we
want to piggyback on an nrepl-connection to do the tricky parts of
refactoring, but for now we're happy to make life a little easier.
Hope you enjoy!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clj-refactor.el 0.10.0
Slam dunk! Looking forward to trying this 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.
ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
lein-describe Have you ever be involved in a Clojure project and wondered how are these dependencies used? or what do these plugins do?. This plugin can help you answer those questions. lein-describe provides detailed information about Clojure project dependencies and plugins. With a single command you can get a glance at dependency descriptions, licenses, and more. https://github.com/noprompt/lein-describe#usageUsage Put [lein-describe 0.1.0] into the :plugins vector of your :user profilehttps://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md . https://github.com/noprompt/lein-describe#exampleExample $ cd /path/to/clojure/project $ lein describe PROJECT DEPENDENCIES: Dependency: [com.cemerick/piggieback 0.1.2] Description: Adding support for running ClojureScript REPLs over nREPL. URL: http://github.com/cemerick/piggieback License(s): Eclipse Public License (http://www.eclipse.org/legal/epl-v10.html) Dependencies: [org.clojure/clojure 1.5.1] [org.clojure/tools.nrepl 0.2.3] [org.clojure/clojurescript 0.0-2014] [clojure-complete 0.2.3] ... PLUGIN DEPENDENCIES: Dependency: [com.cemerick/austin 0.1.3] Description: The ClojureScript browser-repl, rebuilt stronger, faster, easier. URL: http://github.com/cemerick/austin License(s): Eclipse Public License (http://www.eclipse.org/legal/epl-v10.html) Dependencies: [org.clojure/clojure 1.5.1] [org.clojure/clojurescript 0.0-2014] [com.cemerick/piggieback 0.1.2] [org.clojure/tools.nrepl 0.2.3] [clojure-complete 0.2.3] ... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Contributors needed for Rouge (Clojure on Ruby)
As a suffix to my last reply; if Hy were capable of delivering acceptable truthy semantics and persistent data structures, I might recommend it. On Saturday, January 4, 2014 9:44:08 AM UTC-8, g vim wrote: On 04/01/2014 17:28, gaz jones wrote: Why not just use Ruby or (my preference) Python? Both are great for quick CLI apps / scripts. Best tool for the job, and all that? A Clojure layer on top of Ruby means less context switching which works better for me as the Lisp mindset is very different from Ruby or Python. However, I just looked at the Rouge docs and very little seems to have been implemented so maybe it's dying. If so, I'll go with Hy which looks much more mature. gvim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: AnNN: ClojureScript 0.0-2120
Woohoo! Yes! Thank you! On Friday, December 13, 2013 7:15:40 AM UTC-8, David Nolen wrote: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2120 Leiningen dependency information: [org.clojure/clojurescript 0.0-2120] Enhancements: * inline source map information available to REPLs, enabled in browser REPL * #js data literal support added * :include-macros true and :refer-macros [syms ...] allowed in :require * make-array now inlined into dense array, much faster PHM perf * CLJS-673: support *print-level* * expose Google Closure Compiler defines under :closure-defines * expose Google Closure Compiler warnings configuration under :closure-warnings Changes: * latest Closure Compiler dependency * CLJS-690: add sequence sorted * CLJS-709: optimize cljs-js for sequential collection to array * CLJS-699: letfn fns not optimized Bug fixes: * CLJS-724: Range -first bug * CLJS-725: fix broken optimizations around IndexedSeq * fix broken behavior of #uuid and #inst data literals * CLJS-697: top-level symbol reference doesn't get an automatically inserted ns-name * CLJS-692: cannot access properties on imported GClosure constructors * CLJS-480: reader/*data-readers* bound inconsistently -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Import dbpedia data into neo4j using clojure
I'm not certain where the Transient error is coming from but as far as
Neo4J is concerned have you considered using the neocons library to help
you with your import? It provides a decent wrapper for working with Neo4J
and perhaps it will spare you some headache. IIRC it does batch inserts.
Have a look: https://github.com/michaelklishin/neocons
On Monday, December 2, 2013 2:11:53 AM UTC-8, Himakshi Mangal wrote:
Hi...
I am using clojure to import dbpedia data into neo4j.
Here's the code:
(ns opal.dbpedia
(:use [clojure.tools.logging :only [log]])
(:require [clojure.java.io :as io])
(:import [uk.ac.manchester.cs.owl.owlapi.turtle.parser TurtleParser]
[org.neo4j.unsafe.batchinsert BatchInserters]
[org.neo4j.graphdb DynamicRelationshipType]))
;; PARSING METHODS
(defn get-next-tuple
[parser]
(let [last-item (atom nil)
tuple (atom [])]
(while (and (not= . @last-item)
(not= @last-item))
(reset! last-item
(- parser
(.getNextToken)
(.toString)))
(swap! tuple conj @last-item))
(when-not (empty? (first @tuple)) ; .getNextToken returns once you
are out of data
@tuple)))
(defn seq-of-parser
[parser]
(if-let [next-tuple (get-next-tuple parser)]
(lazy-cat [next-tuple]
(seq-of-parser parser
(defn parse-file
[filename]
(seq-of-parser
(TurtleParser.
(io/input-stream filename
;; BATCH UPSERT METHODS
(def id-map (atom nil))
(defn insert-resource-node!
[inserter res]
(if-let [id (get @id-map res)]
; If the resource has aleady been added, just return the id.
id
; Otherwise, add the node for the node, and remember its id for later.
(let [id (.createNode inserter {resource res})]
(swap! id-map #(assoc! % res id))
id)))
(defn connect-resource-nodes!
[inserter node1 node2 label]
(let [relationship (DynamicRelationshipType/withName label)]
(.createRelationship inserter node1 node2 relationship nil)))
(defn insert-tuple!
[inserter tuple]
; Get the resource and label names out of the tuple.
(let [[resource-1 label resource-2 _ ] tuple
; Upsert the resource nodes.
node-1 (insert-resource-node! inserter resource-1)
node-2 (insert-resource-node! inserter resource-2)]
; Connect the nodes with an edge.
(connect-resource-nodes! inserter node-1 node-2 label)))
(defn -main [graph-path files]
(let [inserter (BatchInserters/inserter graph-path)]
(doseq [file files]
(log :debug (str Loading file: file))
(let [c (atom 0)]
(doseq [tuple (parse-file file)]
(if (= (mod @c 1) 0)
(log :debug (str file : @c)))
(swap! c inc)
(insert-tuple! inserter tuple
(log :debug Loading complete.)
(log :debug Shutting down.)
(.shutdown inserter)
(log :debug Shutdown complete!)))
I am getting the following errors:
IllegalAccessError Transient used by non-owner thread
clojure.lang.PersistentArrayMap$TransientArrayMap.ensureEditable
(PersistentArrayMap.java:449)
IllegalArgumentException No matching method found: createNode for class
org.neo4j.unsafe.batchinsert.BatchInserterImpl
clojure.lang.Reflector.invokeMatchingMethod
Can anyone please help me in this.. Am doing something wrong or am i
missing something.. I am completely new to clojure. Is there a working
example for this?
Please help..
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.
Releasing Caribou today: Open Source Clojure Web Ecosystem
This exactly the sort of project I've been hoping for to get others to take a serious look at using Clojure. While its unfortunate some developers will not look at a language until it has a comfortable entry point, it's a real barrier for adoption. Caribou looks like it has the potential to speak to these developers with familiar workflow tools. I look forward to sharing this with others whom I've tried to convince in the past. By the way the documentation is great. You guys nailed it! Bonus points for having a philosophy! :-) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Garden 1.0.0 released
Thanks James! The only thing I think is missing now are solid libraries (or ports of). With ClojureScript support there are some interesting applications/possibilities on the client side that I'm just beginning to explore. I would definitely be interested to see what people discover in that space. Unfortunately, I think it will be a while before others (Sass/Less users) see the benefits and potential of this approach to stylesheet programming. For that it would likely need some mentions from CSS thought leaders and, again, librarie. FWIW, team Simonides used Garden for our app in the Clojure Cup. We didn't do anything advanced but it spared us one less language! Joel On Oct 4, 2013, at 9:39, james borden jmbor...@gmail.com wrote: Nice Joel! Thanks for making css a function. I suggest that others check this library out. It is a very compelling clojure alternative to SASS/LESS. On Thursday, September 26, 2013 8:39:05 PM UTC-5, Joel Holdbrooks wrote: After nearly a month and a half of work, I'm extremely excited to finally announce the release of Garden 1.0.0! This new release contains several important bug fixes, new features, and of course breaking changes. Please be sure to see the ChangeLog for what has changed since the last release. This is critical for people who want to upgrade as there are some syntax changes and namespaces which are no longer included. In a nutshell the new version has: full ClojureScript support built-in @keyframes support the garden.core/css function (previously was a macro) the garden.core/style function for inline styling of HTML new compiler settings configurable automatic vendor prefixing A huge thank you goes out to Julien Eluard for making ClojureScript support a success. Also, I want to thank Rob Jens for spotting bugs and writing stylesheets with Garden against the development version. Without this kind of support, I don't think I'd be as happy as I am today. As always, I'm interested in hearing new ideas and getting feedback from the community. Sincerely, Joel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/hedoVJ1Ep88/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: Emacs font and theme for clojure
I've been using the noctilux-theme https://github.com/stafu/noctilux-theme with Oxygen Mono http://www.google.com/fonts/specimen/Oxygen+Mono or Liberation Mono http://www.fontsquirrel.com/fonts/Liberation-Mono. On Thursday, September 26, 2013 7:51:44 AM UTC-7, Murtaza Husain wrote: Hi, I was just cycling through the different themes in emacs. I was wondering what font and theme combination others are using ? Any recommendations for mac pro retina ? I like the solarized-dark theme, however the default font doesnt seem very good with it. Thanks, Murtaza -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Garden 1.0.0 released
After nearly a month and a half of work, I'm extremely excited to finally announce the release of Garden 1.0.0 https://github.com/noprompt/garden! This new release contains several important bug fixes, new features, and of course breaking changes. Please be sure to see the ChangeLoghttps://github.com/noprompt/garden/blob/master/ChangeLog.md#changes-between-010-beta6-and-100for what has changed since the last release. This is critical for people who want to upgrade as there are some syntax changes and namespaces which are no longer included. In a nutshell the new version has: - full ClojureScript support - built-in @keyframes support - the garden.core/css *function* (previously was a macro) - the garden.core/style function for inline styling of HTML - new compiler settings - configurable automatic vendor prefixing A huge thank you goes out to Julien Eluard for making ClojureScript support a success. Also, I want to thank Rob Jens for spotting bugs and writing stylesheets with Garden against the development version. Without this kind of support, I don't think I'd be as happy as I am today. As always, I'm interested in hearing new ideas and getting feedback from the community. Sincerely, Joel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] clojure-sql 0.1.0: relational algebra in clojure
This looks really nice Carlo! It'd be even better if it were on GitHub so I could star it :). But I'm definitely going to take a look at this when I'm in the SQL world again. On Wednesday, July 3, 2013 1:48:07 AM UTC-7, Carlo wrote: Hey guys! I've been working on a small library to make writing SQL queries a little bit easier. It's along the same lines as ClojureQL, but takes a different approach and compiles into quite different SQL in the end. At the moment it's quite immature, but it should be able to support any queries which can be expressed in relational algebra. There will be some SQL queries which can't be expressed in clojure-sql, but hopefully there won't be too many of those. A greater limitation is that at the moment the SQL generation is specific to the PostgresSQL database (although any contributions for other databases are welcome!). Dependency vector: [clojure-sql 0.1.0] Repository: https://bitbucket.org/czan/clojure-sql Clojars link: https://clojars.org/clojure-sql Let me know what you think! Carlo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Ayler - A simple namespace/documentation browser
This is really cool! Nice work! On Wednesday, September 11, 2013 8:35:31 AM UTC-7, babysnakes wrote: Hi As a clojure noob I constantly find myself browsing through various API docs to see what's available in a library. While this data is available in a REPL it's not easy to look for it if you don't know what you're looking for. I first saw a namespace browser concept in Relevance's labreplhttps://github.com/relevance/labrepl and I really liked the idea. I decided to create one as a learning project. So now I present to you Ayler https://github.com/babysnakes/ayler/wiki. It's a web based namespace browser that is external to your project and has the following features: - Requires minimal (or no) dependencies in your project. It operates by connecting to a running nreplhttps://github.com/clojure/tools.nrepl . - Displays all loaded namespaces. - Displays all public member for a selected namespace. - Displays docstring for selected namespace. - Displays the docstring and source of selected var. - Allows you to search and load any namespace from a list of all namespaces in your classpath (provided you've added required dependencies). I also have to point out the clj-ns-browserhttps://github.com/franks42/clj-ns-browser project. I borrowed a few features from it, but it's still much more advanced then Ayler. Since this is a learning project for me (both clojure and javascript) I'll appreciate some feedback. https://github.com/babysnakes/ayler/wiki Thanks -- Haim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Shodan: ClojureScript console API wrapper
Hi everyone, I put together a small library for wrapping the JavaScript console API available here: https://github.com/noprompt/shodan. This is nothing incredible but I decided to put it out there because I'm tired of copy/paste/writing the same console wrappers every time I do something in CLJS. Not everyone knows there is more to the console API than just *log*. There are methods for warning, message grouping, profiling and more. Shodan wraps all of these and provides a few macros around some things like message grouping and timing. Shodan works with both the browser and NodeJS. Thanks, Joel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Emacs Clojure mode : No syntax highlighting for #_
Definitely. I would agree a choice would be nice or even another font-lock group. There have been times where I forgot about a #_ somewhere in my code and spent a moment in confusion. Highlighting definitely would have been valuable. It would be cool if code following #_ were semi-transparent or something nifty like that. I think that's possible in the gui version of Emacs. On Thu, Aug 29, 2013 at 1:58 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/8/29 Joel Holdbrooks cjholdbro...@gmail.com: I would imagine it is intended since #_ is a reader macro. #_ is not intended for commenting. Rather, it instructs the Clojure Reader to ignore entirely the subsequent form. This is much different from the comment macro (which simply takes any number of arguments and returns nil) or the ; comment syntax. It might be a bit involved to have #_ and the subsequent form appear commented through clojure-mode's syntax highlighting. However, it would also incorrectly express the semantics of #_ which, arguably, is counter to the goal of syntax highlighting. Yet it is certainly better, given a dual choice, to present it as commented code. Counterclockwise does this since more than a year, and so far, nobody has complained. Cheers, -- Laurent On Wednesday, August 28, 2013 3:09:11 PM UTC-7, JvJ wrote: Although semicolons cause the text color to change in order to look commented-out, the #_ reader macro doesn't cause any such change. Is this intended, or is it a bug? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/b5ETVbGG8G8/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. -- Joel -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Emacs Clojure mode : No syntax highlighting for #_
I would imagine it is intended since *#_* is a reader macro. *#_* is not intended for commenting. Rather, it instructs the Clojure Reader to ignore entirely the subsequent form. This is much different from the *comment*macro (which simply takes any number of arguments and returns nil) or the *;* comment syntax. It might be a bit involved to have *#_* and the subsequent form appear commented through clojure-mode's syntax highlighting. However, it would also incorrectly express the semantics of *#_* which, arguably, is counter to the goal of syntax highlighting. On Wednesday, August 28, 2013 3:09:11 PM UTC-7, JvJ wrote: Although semicolons cause the text color to change in order to look commented-out, the #_ reader macro doesn't cause any such change. Is this intended, or is it a bug? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Searching for Regular Expressions in a file
You could use *line-seq* which, if I'm not mistaken, is lazy. Then do your regex search line by line lazily. On Monday, August 12, 2013 4:25:15 PM UTC-7, JvJ wrote: Is there a way to do a regex search over an entire file without loading the file into memory? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: YA regular expression tool
Thanks. This tool was really more or less for fun but I'd been thinking about it for a while. According to some benchmarks it appears the generated patterns are pretty fast. When I get some more time, I definitely want to see if converting the word trie to a DAWG and then to a regular expression will produce even better patterns. Of course, this means pattern construction will be slower. More or less I'd like some input on ways to improve the efficiency of the whole thing. On Tuesday, July 30, 2013 3:49:49 AM UTC-7, Mikera wrote: On Monday, 29 July 2013 21:20:49 UTC+1, Joel Holdbrooks wrote: I spent some time this weekend writing a little tool for generating regular expressions *from known inputs*. My goal is to produce regular expressions that backtrack as few times as possible along with a complete and total disregard for readability. :) The code for the tool is here https://github.com/noprompt/frak. Suggestions/ideas would be greatly appreciated. Nice - I like the fact that it has a very simple API that focuses on doing just one thing well! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Invalid token exception on a / operator
I've been stung by this too. One work around I use is *(:refer-clojure :exclude [/])* and *(:require [some.ns :refer [/])* in my *ns* form. Then refer to *clojure.core//* directly if needed. It's good to hear this will be fixed in 1.6. On Tuesday, July 30, 2013 5:26:23 AM UTC-7, Maik Schünemann wrote: Is / a valid clojure function name (valid, but not recommended)? I tought so because of clojure.core// in the repl there is also no problem with clojure.core//: clojure.core// ;=#core$_SLASH_ clojure.core$_SLASH_@6d996380 but if / is in another namespace, for example in core.matrix: clojure.core.matrix.operators// RuntimeException Invalid token: clojure.core.matrix.operators// clojure.lang.Util.runtimeException (Util.java:219) clearly this is an edge case, because / also separates namespaces but I think if clojure.core// is valid clojure.core.matrix.operators// should also be a valid token?! regards Maik Schünemann -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: changing a value in a vector of maps
This probably won't help with your garbage collection worries, but it's a
bit more flexible.
*(defn find-assoc-in [pred coll k v kvs]*
* (let [f #(if (pred %) (apply assoc % k v kvs) %)]*
*(into (empty coll) (map f coll*
On Tuesday, July 30, 2013 10:53:48 AM UTC-7, cej38 wrote:
Suppose I have a vector of maps (this could also be a vector of records)
(def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
and I want to go in an change the value of associated with :c when :a has
a value of 50, so that the final col of maps looks like
[{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
I came up with a function that does this:
(defn find-assoc-in
[k v mv]
(let [f #(if (= ((first k) %) (first v))
(assoc % (second k) (second v))
%)]
(map f mv)))
(find-assoc-in [:a :c] [50 3] aa)
The problem with this function is that it potentially does a lot
of unnecessary copying of elements that aren't changed, and thus has a lot
of garbage collection. I would like help coming up with something that
does much less garbage collection.
Will someone please point out a better way of doing this?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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.
YA regular expression tool
I spent some time this weekend writing a little tool for generating regular expressions *from known inputs*. My goal is to produce regular expressions that backtrack as few times as possible along with a complete and total disregard for readability. :) The code for the tool is here https://github.com/noprompt/frak. Suggestions/ideas would be greatly appreciated. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: T-shirts?
+1. I'd love this. On Sunday, July 28, 2013 3:22:21 PM UTC-7, Isaac Wagner wrote: There was a discussion a while ago about stickers which led to http://clojure.org/swag. Could we get some sanctioned T-shirts as well? There are a few Clojure shirts on Zazzle, but what I would be interested in is some black, grey, and white shirts with nothing but a big Clojure logo on the front and I would love to buy them in a way that supports Clojure. Isaac -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: New CSS library - Garden
Hi Steven,
I know that readability is a bit of an issue for some people. Unfortunately
there isn't much I can do other than point folks to the defrule macro and some
of the other suggestions I've made. As I work with the Garden I see problem
areas too and am working to find solutions that will make using the library
more palatable.
Speaking of defrule, and correct me if I'm missing something, but I think you
might be a bit confused about it's nature. You should think of defrule as a way
to create selector functions. I'll admit this was bad naming on my part and
I'll probably make an alias called defselector. Those selectors can be as
generic or precise as you like and possess the same semantics as normal vector
based Garden code but are more flexible (since they are functions). Also, they
should give you the indentation you are looking for.
(defrule a :a)
(defrule footer :footer)
(footer {:color red
:background-color blue}
(a {:color green}))
But if I have 3 elements with 3 children each, and each child has 3 children,
that's already 27 defrules I have to stick above it. That'll get pretty unruly
quick.
Only if you have 27 distinct elements that you have no intention of ever
reusing. Observe:
;; These forms are all semantically equivalent.
(footer {:color red
:background-color blue}
(a {:color green}))
[:footer {:color red
:background-color blue}
(a {:color green})]
(footer {:color red
:background-color blue}
[:a {:color green}])
;; This works too.
(defrule h1 :h1)
(defrule hover :hover)
(footer
(h1 {:font-weight normal}
(hover {:font-weight bold}))
(a {:text-decoration none}
(hover {:text-decoration underline})))
To make life easier I will add all known HTML selectors (via defrule) and make
some tweaks to it's behavior today. As of this moment most of the pseudo
classes have been implemented here.
I hope this helps clear things up. Again, if I'm not understanding you
correctly, please let me know.
Thanks,
Joel
On Jul 6, 2013, at 6:58 AM, Steven Degutis sbdegu...@gmail.com wrote:
So far, I really like Garden.
There's one thing though that's making it difficult. It's hard to see that
nested rules are nested.
;; hard to see nesting
[:footer {:color red
:background-color blue}
[:a {:color green}]]
;; much easier
(:footer {:color red
:background-color blue}
[:a {:color green}])
(That's a bad example because it's so short. In the real world, much longer
and deeper-nested rules show it clearer.)
Technically I'm using emacs with clojure-mode.el, which indents vectors by
only 1 char. But I don't think that's the problem. Normally it's good to
indent them by only 1 char, but there's no way to differentiate between
[:some [:random :data]], which should be indented like that, and a vector of
garden-rules which should be indented more obviously. So I don't think this
is something that changing our editors/plugins will fix.
One solution is to use defrule more often. But if I have 3 elements with 3
children each, and each child has 3 children, that's already 27 defrules I
have to stick above it. That'll get pretty unruly quick.
So I was thinking of just using a dummy macro like this:
(defmacro rule [ body] `[~@body])
(def footer
(rule :footer {:color red
:background-color blue}
(rule :a {:color green})))
But you can imagine my discomfort at writing/using a macro just to make
indentation easier.
Are there any better solutions to this?
-Steven
On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks cjholdbro...@gmail.com
wrote:
Nobel Clojurians,
I am pleased to announce the alpha version of Garden, a new library for
writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being too
simple or too complex.
Currently the list of notable features include:
Nestable rules
Nestable declarations (this my change)
A builtin set of tools for working with CSS unit values
Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
Output formatting options
What's planned for the near future:
The ability to use Clojure meta as a media query
A builtin set of tools for working with CSS color values
selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a look
at the project's repository. There is still quite a bit of ground to do cover
and any help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or send
pull requests. I would love nothing more than to see this library succeed
where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group
Re: New CSS library - Garden
Cool. I'm glad you like the library. Thanks for sharing your kind words and
thoughts. :)
I admit it's weird that it just vector-izes its arguments, and does nothing
else.
In that case I don't think you need a macro, just alias rule to vector and
you'll achieve the same end.
I think it should be part of the garden lib...
I don't think there would be any harm in adding this as an alias; I tend to do
a similar thing aliasing styles to list.
And abstracting really feels like it shouldn't be used to solve the problem of
indentation.
That's definitely not the only reason why defrule was added but it could be
used to address that problem which is why I brought it up. The beautiful thing
about programming stylesheets in Clojure is that we can come up with whatever
abstractions/techniques we like without being tied down by syntax. There's a
lot of potential there for some interesting ideas.
I've been experimenting with some ways of integrating it with compojure for
some Rails4-like asset-pipelining...
Some people are definitely looking for this. If you come up with something,
even a simple gist, please share it. I'm still loading/compiling stylesheets
manually. :P
Oh, I don't know if you saw this gist but there's also some interest in ideas
surrounding grid systems.
Thanks,
Joel
On Jul 6, 2013, at 7:41 PM, Steven Degutis sbdegu...@gmail.com wrote:
Right, I understand how defrule works. But I actually do have 27 [i.e. O(n)]
distinct rules, so it's not a feasible solution.
Because when I write CSS, I only style domain-specific class names (.cart,
.license), never mentioning the elements they just so happen to use at the
moment (h1, p, a). This lets me change the implementation quickly and easily.
And it makes it easier to write for other devices/sizes.
So really I only use defrule for the pseudo-selectors you just linked to
(hover, active, nth-child). Besides that I really have no use for it.
And abstracting really feels like it shouldn't be used to solve the problem
of indentation. Besides, like Dan Neumann mentioned in that Github Issue,
abstracting anything in my stylesheet too early can lead to wrong
abstractions that are difficult to revert. So right now I define an entire
section (header, footer, cart) as one big nested vector, nothing extracted.
Sure, I'll probably clean it up later, but only after I have more pages and
can see more patterns emerging clearly.
Although, I have abstracted one thing which I hope will turn out useful:
(def clearfix
[:
[::after {:clear both}]
[::before
::after {:display table :content ''}]])
Then you can embed it as a rule anywhere that you need to clear some floats:
[:.some-container-with-floats clearfix]
But as for indentation, so far I'm liking the rule macro more and more. I
admit it's weird that it just vector-izes its arguments, and does nothing
else. But the fact that it's a function call fixes the indentation problem
wonderfully.
I think it should be part of the garden lib, really. Although lately I've
renamed it to % so my eyes aren't drawn to the wrong thing when I'm
skimming my rules. It was ! for a while but that was weirder thanks to it
being right after a long skinny parenthese. But either way, these all make
nested rules much easier to visually scan.
Anyway I really love using Garden. Thanks for writing it!
I've been experimenting with some ways of integrating it with compojure for
some Rails4-like asset-pipelining (whatever that means), and it works
really well but the API is still a little raw. But if I come up with anything
good I'll try to share it.
-Steven
On Sat, Jul 6, 2013 at 8:52 PM, Joel Holdbrooks cjholdbro...@gmail.com
wrote:
Hi Steven,
I know that readability is a bit of an issue for some people. Unfortunately
there isn't much I can do other than point folks to the defrule macro and
some of the other suggestions I've made. As I work with the Garden I see
problem areas too and am working to find solutions that will make using the
library more palatable.
Speaking of defrule, and correct me if I'm missing something, but I think you
might be a bit confused about it's nature. You should think of defrule as a
way to create selector functions. I'll admit this was bad naming on my part
and I'll probably make an alias called defselector. Those selectors can be
as generic or precise as you like and possess the same semantics as normal
vector based Garden code but are more flexible (since they are functions).
Also, they should give you the indentation you are looking for.
(defrule a :a)
(defrule footer :footer)
(footer {:color red
:background-color blue}
(a {:color green}))
But if I have 3 elements with 3 children each, and each child has 3
children, that's already 27 defrules I have to stick above it. That'll get
pretty unruly quick.
Only if you have 27 distinct elements that you
Re: New CSS library - Garden
Rob,
Sorry for the late reply. I've been a bit distracted the past few days.
I'll try to address your thoughts as best I can.
*There could even be a grid protocol and fluid, responsive, fixed, mobile,
etc be implementations of it, or multi-methods, or maybe its an overkill.*
I don't think this is overkill. At the very least it's probably worth
exploring. While I was translating the semantic grid SCSS code to
Clojure, protocols did cross my mind. As I noted in the code comments there
are a handful of core functions you see in virtually every grid system;
well, in virtually every grid system I've ever seen. My instincts lead me
to believe experimenting with protocols would be a step in the right
direction.
*... image overlay ... that could be really nice since a lot of designers
still hand in photoshop illustrations that developers need to fit in*
We have the JVM at our disposal. I'm fairly certain this could be a simple
task although I'm not certain where one would start (probably Google).
*Do you plan on incorporating a grid framework/concept in Garden?
*
Yes, but I'm waiting until Garden is no longer in beta (which should only
be for another month or so). If you, or anyone reading this, would like to
share gists/concepts for a grid framework that would definitely help keep
the ball rolling. My main focus right now is making sure I've covered the
most important topics (ie. color, units, comments, compilation) so people
can feel confident and productive - especially if they're coming from Sass
or another alt-css language.
*...the pound signs are causing reader errors...
*
That's because I was using *data_readers.clj*. Have a look
*here*https://github.com/noprompt/garden/blob/master/dev/data_readers.clj.
I would definitely encourage anyone using Garden to employee this approach.
Regarding the new CSS grid spec and not holding my breath. I won't. It'll
probably be at least a year or two before we see something solidified and
even longer before it's a viable option. It's a good idea but it still
needs a ton of work.
Anyhow, thanks for sharing your ideas! I look forward to hearing more from
you.
Joel
On Thu, Jun 27, 2013 at 11:09 AM, Rob Jens rob.jentz...@gmail.com wrote:
P.p.s. the pound signs are causing reader errors (e.g. #px) in LightTable
so I changed those plus additionally added a little Jetty
https://gist.github.com/clojens/5878804
Cheers
Op dinsdag 9 april 2013 21:58:50 UTC+2 schreef Joel Holdbrooks het
volgende:
Nobel Clojurians,
I am pleased to announce the alpha version of
*Garden*https://github.com/noprompt/garden,
a new library for writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being
too simple or too complex.
Currently the list of notable features include:
- Nestable rules
- Nestable declarations (this my change)
- A builtin set of tools for working with CSS unit values
- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
- Output formatting options
What's planned for the near future:
- The ability to use Clojure meta as a media query
- A builtin set of tools for working with CSS color values
- selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a
look at the *project's repository* https://github.com/noprompt/garden.
There is still quite a bit of ground to do cover and any
help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or
send pull requests. I would love nothing more than to see this library
succeed where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from 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/xbFU2prTxlY/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.
--
Joel
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http
Re: New CSS library - Garden
Garden 0.1.0-beta5 is now available! The newest version includes functions
for working with *color* https://github.com/noprompt/garden#color and
performing generic
*arithmetic*https://github.com/noprompt/garden#arithemetic(ie. operators for
transparently adding numbers and units or numbers and
colors). All of the familiar Sass color functions have been added to the
library along with some new functions for generating triads, tetrads, and
other sets of colors. Essentially (almost) anything you can do with Sass
colors you can do in Garden just as conveniently. There are a few small
tweaks that need to be addressed around color transparency which will be
addressed in the near future. Check out the updated README at the project *home
page https://github.com/noprompt/garden* for more information.
The library is getting closer to being a viable alternative to other CSS
preprocessors (at least in my opinion). It's a slow burn but eventually
it'll get there!
Thanks to everyone for remaining interested in the project and please
continue to give me feedback.
On Tuesday, April 9, 2013 12:58:50 PM UTC-7, Joel Holdbrooks wrote:
Nobel Clojurians,
I am pleased to announce the alpha version of
*Garden*https://github.com/noprompt/garden,
a new library for writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being
too simple or too complex.
Currently the list of notable features include:
- Nestable rules
- Nestable declarations (this my change)
- A builtin set of tools for working with CSS unit values
- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
- Output formatting options
What's planned for the near future:
- The ability to use Clojure meta as a media query
- A builtin set of tools for working with CSS color values
- selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a
look at the *project's repository* https://github.com/noprompt/garden.
There is still quite a bit of ground to do cover and any
help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or send
pull requests. I would love nothing more than to see this library succeed
where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: New CSS library - Garden
Cool. I haven't seen this one before. Since it was fairly simple I
reimplemented it in Clojure with Garden. *Here's the
gist.*https://gist.github.com/noprompt/5873715
I took a functional approach using higher order functions. It could be a
little cleaner but then again *the arithmetic isn't all on one 168
character line
either*https://github.com/twigkit/semantic.gs/blob/master/stylesheets/scss/grid.scss#L63.
There are a few refactorings and nearly all of it is documented in a
literate programming style.
On Wednesday, June 26, 2013 5:41:56 AM UTC-7, Rob Jens wrote:
Hey Jeremy,
You might be interested, in case you hadn't heard of it yet, of the
Semantic Grid (http://semantic.gs) probably in particular their Stylus
version
https://github.com/twigkit/semantic.gs/blob/master/stylesheets/styl/grid.styl
but
depending on your taste/clarity might also wish to check out their grid in
Sass/SCSS.
Its math is quite elegant and simple.
Cheers,
Rob
Op woensdag 19 juni 2013 13:14:03 UTC+2 schreef JeremyS het volgende:
Hi Joel,
Thank for the interest ! You can also take a look at some code have done
around css unit types there https://github.com/JeremS/units. It's got
arithmetic for
units and a namespace dedicated to colors. In it you'll find conversions
between rgb en hsl (that I have taken from the color
libraryhttps://github.com/jolby/colors
)
and the implementation of SASS color helpers. May be you could adapt my
library to garden. From what I have seen Garden uses
protocols to compile different types into css and every unit (including
colors) I define is a record. So you might be able to extend my library
with Garden protocols and use it in garden without much effort. I'd be glad
to see that !
About higher order function I have thought about that and went back, my
first approach made for to complicated function (complected even). With the
actual implementation I can just define stuff like:
(def grid {}) ; grid spec with column, gutter...
(def width (partial grid/witdh grid))
(def push (partial grid/push grid))
and then :
(def side-style [:#side (width 4)
(push 1)])
for a side element spanning onto 4 columns and pushed off 1.
Regarding more advanced systems like Foundation I haven't spent much time
trying to implement them with my DSL.
To do so I need to up my CSS game because I am not yet well versed into
the art of responsive design and it will take me
a bit of time wrapping my head around the media queries involved. If I
try to got responsive, I might probably study
the Unsemantic http://unsemantic.com system from the creator of the
960 one I think.
Good luck with your work and don't hesitate on browsing my github, right
now most of the projects are oriented around CSS and there
might be some ideas there who knows !
On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:
Jeremy,
Looks good. I've been tinkering with grid systems on and off for the
past month or so. Have you thought of trying your hand at porting something
like the Foundation or Gumby grid system?
One thing I've discovered, and you might try this with your 960
implementation, is that using higher order functions can be very handy for
building them out. For example, a *make-grid* function which accepts a
map of configuration options and returns a function which takes a column
number and optional parameters for, say, push and pull. It's a nice way to
package things up.
I'm close to wrapping up a small colors framework for Garden which will
be available in the next beta (hopefully it won't be in beta much longer).
When I take it out of beta it'll probably include a Clojure flavored
implementation of either the grid system that ships with Bootstrap or
Foundation (including the mobile parts).
On the side I've been taking of advantage of Clojure to create a new
concept for a *layout* system. It's based on the font-size/line-height
ratio and allows for the construction of stylesheets such that the grid
system and typography are harmonious. IOW it's a fat pain in the ass, but I
don't think I could even fathom the idea of doing it in Sass.
TL;DR you have Clojure at your disposal! Though we're SOL on some very
nice Sass libraries, we can potentially do more and at a higher level!
Thanks for sharing! It's inspiring.
On Jun 18, 2013, at 4:41 AM, JeremyS jschof...@gmail.com wrote:
Hi Joel,
I have a quick and dirty implementation of a 960-ish grid
systemhttps://github.com/JeremS/cljss-gridusing a DSL similar to garden
If you want to take a look.
On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:
It's funny you should bring that up! I've actually been working on
extracting the grid system from Bootstrap and modular scale from
Foundation. But it's mostly been tinkering.
* I am sorely tempted to give this a try.*
Please do! If I come up
Packaging data_readers.clj with a Clojar
Tagged literals are really neat. The other day I discovered what seems to be a fairly good use case for them (see discussion herehttps://github.com/noprompt/garden/issues/5#issuecomment-19849334). At the time I wasn't sure if data_readers.clj could be packaged with a Clojar but it appears it can. While part of me finds this attractive, I wonder, is this a good idea? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to 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: New CSS library - Garden
Jeremy, Looks good. I've been tinkering with grid systems on and off for the past month or so. Have you thought of trying your hand at porting something like the Foundation or Gumby grid system? One thing I've discovered, and you might try this with your 960 implementation, is that using higher order functions can be very handy for building them out. For example, a make-grid function which accepts a map of configuration options and returns a function which takes a column number and optional parameters for, say, push and pull. It's a nice way to package things up. I'm close to wrapping up a small colors framework for Garden which will be available in the next beta (hopefully it won't be in beta much longer). When I take it out of beta it'll probably include a Clojure flavored implementation of either the grid system that ships with Bootstrap or Foundation (including the mobile parts). On the side I've been taking of advantage of Clojure to create a new concept for a layout system. It's based on the font-size/line-height ratio and allows for the construction of stylesheets such that the grid system and typography are harmonious. IOW it's a fat pain in the ass, but I don't think I could even fathom the idea of doing it in Sass. TL;DR you have Clojure at your disposal! Though we're SOL on some very nice Sass libraries, we can potentially do more and at a higher level! Thanks for sharing! It's inspiring. On Jun 18, 2013, at 4:41 AM, JeremyS jschoffen@gmail.com wrote: Hi Joel, I have a quick and dirty implementation of a 960-ish grid system using a DSL similar to garden If you want to take a look. On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote: It's funny you should bring that up! I've actually been working on extracting the grid system from Bootstrap and modular scale from Foundation. But it's mostly been tinkering. I am sorely tempted to give this a try. Please do! If I come up with something I'll be sure to share a Gist. On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach cli...@dreisbach.us wrote: One interesting thing you could do, given both Garden and ClojureScript, is package CSS frameworks like Twitter Bootstrap or Zurb Foundation as a Clojure library. I am sorely tempted to give this a try. On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks cjhold...@gmail.com wrote: Murtaza, Thanks for having a look at the library. I'll try to answer you questions as best as I can. How does Garden compare to other pre processors such as sass and less? There are some similarities with Garden and other CSS preprocessors. I've tried to bring over the ones I found most useful when using them. Nested selectors and declarations, parent selector references, and unit arithmetic are all currently available to stylesheet authors. The big difference and, in my opinion, the big win is you can build your stylesheets with regular Clojure. This gives you a lot of power and freedom you won't find anywhere else (AFAIK). To name just a few benefits: There's no file parsing or interpretation step. It's just data transformation. There's no need for any sort of special @mixin syntax or macros, you can use Clojure function. There's no need for an @include directive thanks to clojure namespaces. This can help you organize your stylesheet in ways (I think) are much cleaner and less surprising than SASS and other preprocessors. Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which, if you look closely, can be pretty random in some places. WIth regard to the third point, if you've ever tried using the SMACSS approach to stylesheet authoring with a preprocessor like SASS, you can end up with an explosion of files and tons of @include directives. It's not fun, it's hard to manage, and it's difficult to see where code is coming from - especially when using 3rd-party libraries. Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it? It does have one small dependency on java.net.URI but I need some time to think about whether or not it would be worth dropping. As far as using it from a ClojureScript project, what sort of use case are you considering? What is the workflow when using Garden? My experience using Garden is probably close to others at this point. It's kind of funny in that regard. I'm building a tool and at the same time am learning how to use it. Personally, I create a namespace for my core stylesheets and separate namespaces for things like utilities and so forth (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a call to function that compiles and saves the stylesheet at the bottom of the core stylesheets. Since I develop with Emacs and nREPL this means all I have to do is reload the file and the CSS is refreshed. It isn't the best approach
Re: unusual question: how do you get morale?(or moral support)
My life is mostly about music and playing with structure. Programming falls into the second category. Right now, I'm having difficulty getting a job since it's much more fun to play the violin and program than to apply for jobs. If I were to get a programming job where I were to do mundane tasks in a programming language I disliked, I would probably do it for the money. For a while, at least. On Tue, May 14, 2013 at 11:18 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Thanks a funny piece, although I'd debate his self-deserving description of best minds. People who cannot distinguish between important and well-paid are not the best minds. Phil Armando Blancas abm221...@gmail.com writes: Zack, you've probably come across this profile on Jeff Hammerbacher, but just in case. The best minds of my generation are thinking about how to make people click ads, he says. That sucks. http://www.businessweek.com/printer/articles/55578-this-tech-bubble-is-different On Monday, May 13, 2013 2:03:10 PM UTC-7, Zack Maril wrote: One of the reasons I program is because I'm furious. By most accepted metrics, I went to one of the best technical public high schools in the country. I was average there and I was taking graph theory and multivariable calculus as a senior my last semester. The smart kids though? They were doing real analysis, topology, and winning international competitions for mathematics and science. I'm just finishing up college now and I'm watching the geniuses from my high school go from MIT and Stanford to high frequency trading firms or work for places like palantir and facebook. They're using their gifts to remove liquidity from the markets[0], to help fight wars based on lies[1], and to maximize the amount of money they can sell my privacy for[2]. Most of them use programming to indirectly decrease the quality of my life. I'd love it if I could invest money without fear of the markets going crazy because of a tweet[3], if I could support the government without worrying about them killing innocent citizens[4], and if I could connect with my friends and family without worrying about my privacy being sold to the highest bidder. My former classmates are and will be using computers to indirectly prevent me from doing the above with any sort of peace of mind. It is infuriating. When I sit down to program, I now make a conscious effort to build tools that I can use in the future to fight against the trends above. I use Clojure because it's the language I've been able to get the most done in the shortest amount of time. If there were a language that let me do as much as fast, I'd drop Clojure like a rock and learn that. If I want to stem the negative effects the geniuses are having on my life, I'll need to use the best tools possible. That means constantly learning more powerful concepts and building better tools. I've been on a graph theory and network science kick lately because I noticed that google, palantir, and facebook got where they are by virtue of being really good at graph theory. The concepts are crazy powerful and provide immense power to the people who can successfully employ them. So, when I sit down to work on certain projects, the main motivating factor for me is that I'm furious that my classmates are worsening my life. There's a ton of work that I need to do before I can do anything about it though. I'm obviously on a futile crusade fueled by my youth and naiveté, but for the moment, that's why I program. -Zack [0] http://www.nanex.net/aqck2/4136.html [1] http://krugman.blogs.nytimes.com/2013/04/27/the-great-degrader/ [2] https://www.facebook.com/legal/terms [3] http://seekingalpha.com/article/1362731-obama-is-dead-tweet-makes-for-flash-crash [4] http://www.latimes.com/news/opinion/editorials/la-ed-drones-policy-obama-koh-20130513,0,4160911.story On Monday, May 13, 2013 11:35:33 PM UTC+4, Erlis Vidal wrote: Let me share this tale with you guys, hope you like it as much as I do: It is said that Socrates met a worker who asked: what are you doing good man? Don't you see I'm cutting a stone to earn my salary and so I can eat the worker replied. He moved on and later found another worker questioning the same way as the previous one, he replied I'm building a wall, continued Socrates finding their way to a third worker, also questioning, the answer was I'm building a beautiful palace On Mon, May 13, 2013 at 2:17 PM, Timothy Baldridge tbald...@gmail.com wrote: I doubt I'm unique in this area, but for me, programming is a drug. I have to code, or the ideas and thoughts build up in my mind. For me, actually writing down and implementing these is a stress relief. Just ask my parents when I was growing up, or my wife today. Keep me in a room without a computer for a week, and I'll start writing code on paper
Re: New CSS library - Garden
Murtaza, Thanks for having a look at the library. I'll try to answer you questions as best as I can. *How does Garden compare to other pre processors such as sass and less?* * * There are some similarities with Garden and other CSS preprocessors. I've tried to bring over the ones I found most useful when using them. Nested selectors and declarations, parent selector references, and unit arithmetic are all currently available to stylesheet authors. The big difference and, in my opinion, the big win is you can build your stylesheets with regular Clojure. This gives you a lot of power and freedom you won't find anywhere else (AFAIK). To name just a few benefits: - There's no file parsing or interpretation step. It's just data transformation. - There's no need for any sort of special *@mixin* syntax or macros, you can use Clojure function. - There's no need for an *@include* directive thanks to clojure namespaces. This can help you organize your stylesheet in ways (I think) are much cleaner and less surprising than SASS and other preprocessors. - Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which, if you look closely, can be pretty random in some places. WIth regard to the third point, if you've ever tried using the SMACSS approach to stylesheet authoring with a preprocessor like SASS, you can end up with an explosion of files and tons of *@include* directives. It's not fun, it's hard to manage, and it's difficult to see where code is coming from - especially when using 3rd-party libraries. *Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it?* * * It does have one small dependency on java.net.URI but I need some time to think about whether or not it would be worth dropping. As far as using it from a ClojureScript project, what sort of use case are you considering? *What is the workflow when using Garden?* * * My experience using Garden is probably close to others at this point. It's kind of funny in that regard. I'm building a tool and at the same time am learning how to use it. Personally, I create a namespace for my core stylesheets and separate namespaces for things like utilities and so forth (ie. *(ns me.css (:require [me.css.button :as button])*) . Then I have a call to function that compiles and saves the stylesheet at the bottom of the core stylesheets. Since I develop with Emacs and nREPL this means all I have to do is reload the file and the CSS is refreshed. It isn't the best approach, but Garden is still very young and I haven't thought about how a standardize the build process. But I would definitely be open to any thoughts regarding that. A Leiningen plugin would be awesome! I hope these answers are helpful. Please continue to experiment with the library and express your thoughts! Thanks, Joel On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain murtaza.hus...@sevenolives.com wrote: Joel, Thanks for the lib. Its great and I plan to use it in my projects. How does Garden compare to other pre processors such as sass and less ? Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it? What is the workflow when using Garden ? If I am using Sass, I would create a .scss file, and the sass daemon would watch over any changes to the file and compile it to .css. As I understand garden is generating css when called with the fn/macro (css [...]). Would it make sense to have a similar workflow like above; where a leiningen plugin watches for any .garden files and compiles them to .css files ? Or is there a better workflow that I am missing? Thanks, Murtaza On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote: As of today, Garden is officially out of alpha and in to beta! The library now sports media querieshttps://github.com/noprompt/garden#media-queries (via meta data) and parent selector referenceshttps://github.com/noprompt/garden#parent-selector-references (ie. hover). With these new features it is now possible to build more sophisticated stylesheets bringing us a step closer to having a viable CSS alternative in Clojure. Over the course of the next few weeks, I plan to continue improving the library by adding missing features and functions to make the library as powerful as possible when it's release as 0.1.0 stable. Now more than ever, I would like to encourage others in the community to reach out with suggestions and code review. This my first real Clojure library and after only six months with the language I'm sure it could benefit greatly from both of these things. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send
Re: New CSS library - Garden
It's funny you should bring that up! I've actually been working on extracting the grid system from Bootstrap and modular scale from Foundation. But it's mostly been tinkering. * I am sorely tempted to give this a try.* Please do! If I come up with something I'll be sure to share a Gist. On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach clin...@dreisbach.uswrote: One interesting thing you could do, given both Garden and ClojureScript, is package CSS frameworks like Twitter Bootstrap or Zurb Foundation as a Clojure library. I am sorely tempted to give this a try. On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks cjholdbro...@gmail.com wrote: Murtaza, Thanks for having a look at the library. I'll try to answer you questions as best as I can. How does Garden compare to other pre processors such as sass and less? There are some similarities with Garden and other CSS preprocessors. I've tried to bring over the ones I found most useful when using them. Nested selectors and declarations, parent selector references, and unit arithmetic are all currently available to stylesheet authors. The big difference and, in my opinion, the big win is you can build your stylesheets with regular Clojure. This gives you a lot of power and freedom you won't find anywhere else (AFAIK). To name just a few benefits: There's no file parsing or interpretation step. It's just data transformation. There's no need for any sort of special @mixin syntax or macros, you can use Clojure function. There's no need for an @include directive thanks to clojure namespaces. This can help you organize your stylesheet in ways (I think) are much cleaner and less surprising than SASS and other preprocessors. Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which, if you look closely, can be pretty random in some places. WIth regard to the third point, if you've ever tried using the SMACSS approach to stylesheet authoring with a preprocessor like SASS, you can end up with an explosion of files and tons of @include directives. It's not fun, it's hard to manage, and it's difficult to see where code is coming from - especially when using 3rd-party libraries. Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it? It does have one small dependency on java.net.URI but I need some time to think about whether or not it would be worth dropping. As far as using it from a ClojureScript project, what sort of use case are you considering? What is the workflow when using Garden? My experience using Garden is probably close to others at this point. It's kind of funny in that regard. I'm building a tool and at the same time am learning how to use it. Personally, I create a namespace for my core stylesheets and separate namespaces for things like utilities and so forth (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a call to function that compiles and saves the stylesheet at the bottom of the core stylesheets. Since I develop with Emacs and nREPL this means all I have to do is reload the file and the CSS is refreshed. It isn't the best approach, but Garden is still very young and I haven't thought about how a standardize the build process. But I would definitely be open to any thoughts regarding that. A Leiningen plugin would be awesome! I hope these answers are helpful. Please continue to experiment with the library and express your thoughts! Thanks, Joel On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain murtaza.hus...@sevenolives.com wrote: Joel, Thanks for the lib. Its great and I plan to use it in my projects. How does Garden compare to other pre processors such as sass and less ? Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it? What is the workflow when using Garden ? If I am using Sass, I would create a .scss file, and the sass daemon would watch over any changes to the file and compile it to .css. As I understand garden is generating css when called with the fn/macro (css [...]). Would it make sense to have a similar workflow like above; where a leiningen plugin watches for any .garden files and compiles them to .css files ? Or is there a better workflow that I am missing? Thanks, Murtaza On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote: As of today, Garden is officially out of alpha and in to beta! The library now sports media queries (via meta data) and parent selector references (ie. hover). With these new features it is now possible to build more sophisticated stylesheets bringing us a step closer to having a viable CSS alternative in Clojure. Over the course of the next few weeks, I plan to continue improving the library by adding missing
Re: New CSS library - Garden
As of today, Garden is officially out of alpha and in to beta!
The library now sports media
querieshttps://github.com/noprompt/garden#media-queries(via meta data) and
parent
selector
referenceshttps://github.com/noprompt/garden#parent-selector-references(ie.
hover). With these new features it is now possible to build more
sophisticated stylesheets bringing us a step closer to having a viable CSS
alternative in Clojure.
Over the course of the next few weeks, I plan to continue improving the
library by adding missing features and functions to make the library as
powerful as possible when it's release as 0.1.0 stable.
Now more than ever, I would like to encourage others in the community to
reach out with suggestions and code review. This my first real Clojure
library and after only six months with the language I'm sure it could
benefit greatly from both of these things.
On Tuesday, April 9, 2013 12:58:50 PM UTC-7, Joel Holdbrooks wrote:
Nobel Clojurians,
I am pleased to announce the alpha version of
*Garden*https://github.com/noprompt/garden,
a new library for writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being
too simple or too complex.
Currently the list of notable features include:
- Nestable rules
- Nestable declarations (this my change)
- A builtin set of tools for working with CSS unit values
- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
- Output formatting options
What's planned for the near future:
- The ability to use Clojure meta as a media query
- A builtin set of tools for working with CSS color values
- selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a
look at the *project's repository* https://github.com/noprompt/garden.
There is still quite a bit of ground to do cover and any
help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or send
pull requests. I would love nothing more than to see this library succeed
where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: New CSS library - Garden
As of today, Garden is officially out of alpha and in to beta! The library now sports media querieshttps://github.com/noprompt/garden#media-queries (via meta data) and parent selector referenceshttps://github.com/noprompt/garden#parent-selector-references (ie. hover). With these new features it is now possible to build more sophisticated stylesheets bringing us a step closer to having a viable CSS alternative in Clojure. Over the course of the next few weeks, I plan to continue improving the library by adding missing features and functions to make the library as powerful as possible when it's release as 0.1.0 stable. Now more than ever, I would like to encourage others in the community to reach out with suggestions and code review. This my first real Clojure library and after only six months with the language I'm sure it could benefit greatly from both of these things. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: New CSS library - Garden
Awesome. Yes, please do! Also, feel free to suggest ideas for features. I'm focusing on media queries and prefixed selectors this week, but I'd love to see if anyone has good ideas surrounding attribute and child selectors. Right now the best we can do is input[type=\text\] and ul li which is, well, pretty nasty. Thanks for trying it out! On Wednesday, April 10, 2013 12:37:49 PM UTC-7, Dan Neumann wrote: Good stuff! I'm using it in my hobby apps while I continue to cut my teeth on Clojure's web development toolkit. I'll definitely communicate any problems/improvements I spot as I try to scratch my own itch. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.
New CSS library - Garden
Nobel Clojurians,
I am pleased to announce the alpha version of
*Garden*https://github.com/noprompt/garden,
a new library for writing CSS in Clojure.
The project weds the best ideas from Hiccup, gaka, and cssgen and aims to
provide a clean and conventional way to author stylesheets without being
too simple or too complex.
Currently the list of notable features include:
- Nestable rules
- Nestable declarations (this my change)
- A builtin set of tools for working with CSS unit values
- Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
- Output formatting options
What's planned for the near future:
- The ability to use Clojure meta as a media query
- A builtin set of tools for working with CSS color values
- selector syntax for nested rules
For those of you who are interested in this sort of thing, please have a
look at the *project's repository* https://github.com/noprompt/garden.
There is still quite a bit of ground to do cover and any
help/criticism/contribution would be greatly appreciated.
Please feel free to offer suggestions, ask questions, open issues, or send
pull requests. I would love nothing more than to see this library succeed
where other's have not.
Truly,
Joel Holdbrooks (aka noprompt)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Standard alias for partial?
Only case I can see where it doesn't work. user= (def % partial) #'user/% user= (map #(% + %) [1 2 3]) ;trying to use #(% + %) instead of #(partial + %) ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn user/eval2/fn--3 (NO_SOURCE_FILE:2) ; (Also: my first post in this group. :)) On Tue, Jun 19, 2012 at 8:41 PM, Jay Fields j...@jayfields.com wrote: uh, it's going to do what you expect... user= (def % partial) #'user/% user= (map #(inc %) [1 2 3]) (2 3 4) On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar(); jimpil1...@gmail.com wrote: On 19/06/12 19:32, Timothy Baldridge wrote: That works until you try to use the shorthand for anonymous functions: (map #(inc %) [1 2 3]) ; what's this going to do? Timothy Thank you! :-) 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Standard alias for partial?
I propose using ☃. I don't think it has any other uses yet. ;) On Tue, Jun 19, 2012 at 8:57 PM, Joel Ericson kasett...@gmail.com wrote: Only case I can see where it doesn't work. user= (def % partial) #'user/% user= (map #(% + %) [1 2 3]) ;trying to use #(% + %) instead of #(partial + %) ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn user/eval2/fn--3 (NO_SOURCE_FILE:2) ; (Also: my first post in this group. :)) On Tue, Jun 19, 2012 at 8:41 PM, Jay Fields j...@jayfields.com wrote: uh, it's going to do what you expect... user= (def % partial) #'user/% user= (map #(inc %) [1 2 3]) (2 3 4) On Tue, Jun 19, 2012 at 2:33 PM, Jim - FooBar(); jimpil1...@gmail.com wrote: On 19/06/12 19:32, Timothy Baldridge wrote: That works until you try to use the shorthand for anonymous functions: (map #(inc %) [1 2 3]) ; what's this going to do? Timothy Thank you! :-) 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
unchecked-int returning long?
Hi everyone, I've noticed some unexpected behaviour with the unchecked-int function - I think it's a bug, but I'm not entirely sure I've correctly understood the purpose of the function. (type (unchecked-int 0x)) shows long instead of int. This isn't what I would have expected, either from the name, documentation or source code. Interestingly, (type (int (unchecked-int 0x))) also shows java.lang.long instead of int. Using (unchecked-int 0x) as an argument to call a java function requiring an int causes an IllegalArgumentException. In addition, the unchecked casting functions do not currently appear on the clojure.org documentation cheat sheet. Thanks, Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please try the alphas and betas!
Worth pointing out that the Clojure team don't have to do this necessarily - a motivated person could set up a CI server that monitors pre-release SNAPSHOTS on one side, and takes code snippets/lein projects/gists/test-is packages on the other? On Sun, Oct 30, 2011 at 4:04 PM, Colin Yates colin.ya...@gmail.com wrote: Whacky idea - is there a way for people to submit snippets which are run as part of the CI process? -- [what were the skies like when you were young?] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Is there a reader setting support BigDecimal by default?
On Tue, Oct 18, 2011 at 3:47 PM, Tassilo Horn tass...@member.fsf.org wrote: Scott Hickey jscotthic...@gmail.com writes: And usually, you should refrain from using floating points at all, no matter if BigDecimal or Double. I thought BigDecimal with was not a floating point in the traditional sense (ie., subject to all of the usual rounding horror, unless you ask it to be)? That is, you can do decimal calculations exactly using it. -- [what were the skies like when you were young?] -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Fully qualified keywords in clojurescript vs. clojure
I've been playing around with clojurescript and have come across some differences in how clojure and clojurescript treat fully qualified namespaces. It seems that clojurescript always places fully qualified keywords in the user namespace: (ns testns) (pr-str kw: ::kwtest ns: (namespace ::kwtest)) == (kw: :user/kwtest ns: user) while in clojure: (ns testns) (pr-str kw: ::kwtest ns: (namespace ::kwtest)) == (kw: :testns/kwtest ns: testns) So, am I doing something wrong? Is this a bug or expected behavior for clojurescript? Thanks, Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Tail Calls and Continuations in Clojure
On Fri, 15 Jul 2011, Joel Dice wrote: On Fri, 15 Jul 2011, George Jahad wrote: very cool Joel! I'd also be interested in start up time of avian vs. hotspot, i.e. does avian make it viable to use clojure for short, quick scripts? Possibly. By default, Avian is noticeably slower to start up than Hotspot, at least when using OpenJDK's class library. The boot process for that library touches a lot of code in a lot of classes, and Hotspot has several performance advantages to make quick work of it. On the other hand, Avian can also be built to use its own class library, which allows much faster startup. Unfortunately, it doesn't currently have all the classes needed to support Clojure, and I haven't checked to see how much would need to be added to make it work. Avian also supports ahead-of-time compilation from Java bytecode to native machine code, so it would be possible to create an executable with all the OpenJDK and Clojure classes precompiled, thereby bypassing the need for JIT compilation at runtime except for dynamically-loaded classes. That would be faster, but I'm not sure by how much. The ideal approach in terms of startup time would be to add whatever classes needed to Avian's class library to support Clojure, use ProGuard to shrink and optimize the combination of clojure.jar and the system class library, and precompile the result into native code. I might take a stab at that if I have time. I went ahead and pursued this. The upshot is that I can get Avian to run a minimal Clojure script (containing just (println hello, world!)) over twice as fast as Hotspot by precompiling clojure.jar to native code. These are the results on my 2.2GHz Xeon: $ time java -jar ~/p/clojure-1.2.1/clojure.jar hello.clj hello, world! real0m0.858s user0m1.004s sys 0m0.040s $ time ./build/clojure hello.clj hello, world! real0m0.303s user0m0.264s sys 0m0.036s It turned out using OpenJDK's class library was not really the bottleneck, which is good because Avian's built-in library would need to be augmented significantly to run Clojure itself. The main challenge is that Clojure touches a lot of code on startup, which works the JIT compiler hard. Hotspot is better at this because it uses a high-performance interpreter by default and doesn't JIT compile methods until/unless it's deemed a win. Avian's not so smart; it has to compile each method before it can be run. This makes Clojure a good test case for profiling Avian's compiler, though, and I was able to cut startup time for the JIT build by about 60% with a few judicious optimizations. Then I moved on to an ahead-of-time (AOT) compiled build, which further reduced startup time to to result above. Ultimately, though, I don't think this is enough of an improvement to make Clojure viable for short, quick scripts. 300ms is a long time for printing hello, world. I wonder how feasible it would be to make Clojure rely more heavily on lazy initialization so there isn't as much code to be run at startup for simple scripts. That's what I suspect needs to be done to improve startup time on any VM. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Tail Calls and Continuations in Clojure
On Sun, 17 Jul 2011, Phil Hagelberg wrote: I tried Leiningen on Avian and it caused Maven's dependency injection framework to choke, which is not terribly surprising. Perhaps once we've ported it over to Aether it will fare better. My goal is for Avian to be able to run anything HotSpot can when using OpenJDK's class library, so I'll investigate this and fix it if I can. FWIW, it handles Spring's dependency injection just fine, at least as far as I've tested it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[no subject]
Hi all, I thought I'd share the results of a fun little excercise I did this morning: running Clojure on a VM with native support for tail call optimization and first class continuations. Any Schemers on this list will probably appreciate it. The VM in question is Avian (http://oss.readytalk.com/avian/), built with optional tail call and continuation features enabled and using the OpenJDK class library. It's not nearly as fast or sophisticated as e.g. Hotspot, but it has some features that make it interesting for running non-Java languages. I'm using the latest commit from the Git repository. For example, here's what happens if you recurse too deeply using Hotspot: $ java -cp clojure.jar clojure.main Clojure 1.2.1 user= ((fn this [n] (if (= n 100) n (this (+ n 1 0) java.lang.StackOverflowError (NO_SOURCE_FILE:0) user= With Avian, there is no overflow, and we also get to play with continuations: $ ../avian/build/linux-x86_64-tails-continuations-openjdk-src/avian -Xmx512m -cp clojure.jar clojure.main Clojure 1.2.1 user= ((fn this [n] (if (= n 100) n (this (+ n 1 0) 100 user= (defn call-cc [function] (avian.Continuations/callWithCurrentContinuation (reify avian.CallbackReceiver (receive [_ continuation] (function (fn [result] (.handleResult continuation result))) #'user/call-cc user= (call-cc (fn [continuation] (continuation hello, world!))) hello, world! user= For more information about how continuations work in Avian, please see http://oss.readytalk.com/avian/javadoc/avian/Continuations.html. Anyway, I think this is an interesting experiment since it shows that if/when tail call and continuation support are integrated into the JVM officially (http://openjdk.java.net/projects/mlvm/), Clojure could benefit with few or no modifications. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Tail Calls and Continuations in Clojure
(sorry about the lack of subject in my original post; I've added one to this email) On Fri, 15 Jul 2011, George Jahad wrote: very cool Joel! I'd also be interested in start up time of avian vs. hotspot, i.e. does avian make it viable to use clojure for short, quick scripts? Possibly. By default, Avian is noticeably slower to start up than Hotspot, at least when using OpenJDK's class library. The boot process for that library touches a lot of code in a lot of classes, and Hotspot has several performance advantages to make quick work of it. On the other hand, Avian can also be built to use its own class library, which allows much faster startup. Unfortunately, it doesn't currently have all the classes needed to support Clojure, and I haven't checked to see how much would need to be added to make it work. Avian also supports ahead-of-time compilation from Java bytecode to native machine code, so it would be possible to create an executable with all the OpenJDK and Clojure classes precompiled, thereby bypassing the need for JIT compilation at runtime except for dynamically-loaded classes. That would be faster, but I'm not sure by how much. The ideal approach in terms of startup time would be to add whatever classes needed to Avian's class library to support Clojure, use ProGuard to shrink and optimize the combination of clojure.jar and the system class library, and precompile the result into native code. I might take a stab at that if I have time. On Jul 15, 11:59 am, Joel Dice joel.d...@gmail.com wrote: Hi all, I thought I'd share the results of a fun little excercise I did this morning: running Clojure on a VM with native support for tail call optimization and first class continuations. Any Schemers on this list will probably appreciate it. The VM in question is Avian (http://oss.readytalk.com/avian/), built with optional tail call and continuation features enabled and using the OpenJDK class library. It's not nearly as fast or sophisticated as e.g. Hotspot, but it has some features that make it interesting for running non-Java languages. I'm using the latest commit from the Git repository. For example, here's what happens if you recurse too deeply using Hotspot: $ java -cp clojure.jar clojure.main Clojure 1.2.1 user= ((fn this [n] (if (= n 100) n (this (+ n 1 0) java.lang.StackOverflowError (NO_SOURCE_FILE:0) user= With Avian, there is no overflow, and we also get to play with continuations: $ ../avian/build/linux-x86_64-tails-continuations-openjdk-src/avian -Xmx512m -cp clojure.jar clojure.main Clojure 1.2.1 user= ((fn this [n] (if (= n 100) n (this (+ n 1 0) 100 user= (defn call-cc [function] (avian.Continuations/callWithCurrentContinuation (reify avian.CallbackReceiver (receive [_ continuation] (function (fn [result] (.handleResult continuation result))) #'user/call-cc user= (call-cc (fn [continuation] (continuation hello, world!))) hello, world! user= For more information about how continuations work in Avian, please seehttp://oss.readytalk.com/avian/javadoc/avian/Continuations.html. Anyway, I think this is an interesting experiment since it shows that if/when tail call and continuation support are integrated into the JVM officially (http://openjdk.java.net/projects/mlvm/), Clojure could benefit with few or no modifications. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: RIncater
Hi, I'm the original author of RIncanter, and I apologize for its current state. Edmund has tracked down the biggest current problem with loading the native lib portion of the package: it builds a library with a hard-coded path to the R libs (which may not be correct). I talked to Edmund a couple weeks ago, and I was originally thinking I'd grab the latest JRI source and fire up some VM's for each platform and build the native libs for each of the major platforms and update clojars. Now I'm thinking that's not the best way to move forward. I was looking at how they set things up for the ruby/JRI project (https://github.com/sundbp/rri/tree/master/lib/rri)- and they just use the JRI native libs path as installed via CRAN. I think that is a more standard way to set things up, and more reliable from a maintenance standpoint. So, now I just need to figure out how to do something similar with leiningen/clojars. Basically, we need to figure out how to launch the jvm with the LD_LOAD_PATH (or equiv) set to where R installs the JRI native libs. Anyone know how we can do that with leiningen? --Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: sharing multiple jogl opengl contexts in clojure
On Apr 20, 4:46 pm, Josh Stratton strattonbra...@gmail.com wrote: But I can't seem to call createGLPbuffer w/o getting an exception. SNIP/ Caused by: java.lang.IllegalArgumentException: No matching method: createGLPbuffer This one is because the createGLPbuffer method is not static; you need to have created a GLDrawableFactory first using getFactory(): (.createGLPbuffer (GLDrawableFactory/getFactory (GLProfile/ getDefault)) nil nil 1 1 nil) The GLCapabilities argument needs to be set, otherwise you'll get a NullPointerException at this point. The simplest invocation I could come up with that returned a GLPbufferImpl was this: (let [profile (GLProfile/getDefault)] (.createGLPbuffer (GLDrawableFactory/getFactory profile) (GLCapabilities. profile) nil 1 1 nil)) You can take it from here with different profiles, capabilities, choosers etc. J PS I'm using Clojure 1.1 and JOGL 2.0. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: sharing multiple jogl opengl contexts in clojure
Right now it seems calling (.getContext (new GLCanvas)) returns nil Right. The context doesn't get set at construction, but will be set by the time the canvas gets passed to any of the GLEventListener methods. The Javadoc mentions that the underlying context may need to get created and destroyed multiple times as components get added and removed, but it seems to imply that the GLContext object itself provides a stable handle to whatever the current underlying context is. So you might be able to share them. Another possibility though is that you don't *need* to share them... and looking at what's in the one I get back, I notice that it has AWT window handles in its members, so maybe that's not intended after all. I'm curious in general how an OpenGL program should properly be written when dealing with multiple windows. So am I, now :) J -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: sharing multiple jogl opengl contexts in clojure
Further, from the JOGL user guide: In the JSR-231 abstractions, a context is always associated with exactly one drawable. I guess that answers that question. So, while we certainly might want to share some of our GLish state between windows, the Context is not the right vehicle... J -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
primitive arrays, am I reading this right?
Hi all,
(There is an old thread on a similar topic to this, but I seem to be
unable to reply to the group about it, only to the author).
I've been using Clojure this last week, and in general enjoying it
very much. There have been a small number of jarring moments though,
to do with Java interop, so I thought I'd check in with my questions.
The main one comes from having a (third-party) Java class that has
methods a bit like this:
class C {
public void floatMethod(float f) { /* ... */ }
public void floatArrayMethod (float[] argv, int flags) { /* ...
*/ }
}
The argument unboxing that Clojure does with method calls means that
this worked fine:
(.floatMethod (C.) (float 1))
So, lulled into a false sense of knowing what was going on, I tried
this:
(.floatArraymethod (C.) (into-array [(float 1) (float 2)]) 0)
..and got a ClassCastException. The right method gets found,
presumably just by arity, but the array that gets passed has type
java.lang.Float[] (which I would have known had I RTFM properly).
It turns out that the unboxing doesn't extend to array types. Which I
can understand as a design decision, though it would certainly be nice
and sugary otherwise. However, it leaves me doing things like this:
(def floatarray (make-array Float/TYPE 2))
(for [i (range (alength floatarray))] (aset floatarray i (float ([1 2]
i
Aside from the misuse of 'for' (which then needs to be iterated to
cause the side-effects), what am I missing here? Hints on idiomatic
Clojure as well as my primitives question are most welcome.
J
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: primitive arrays, am I reading this right?
Did you try (into-array Float/TYPE [(float 1.0) (float 2.0)])? I'm not sure it works, though. I haven't much done with primitives up to now. Aha. It does work. The key bit of information being that there was another way to call into-array (which I actually speculated about being a good addition - next time I have that thought, I'll bash it straight into the REPL and see if someone else has had it too). The page I had been looking at (http://clojure.org/java_interop#Java %20Interop-Arrays-%28into-array%20coll%29) didn't mention a way of specifying the element type explicitly with into-array, which was exactly what I needed :) And the happy clojure experiences continue... thanks very much. J PS Clojure 1.1 seems happy to make floats from [1.0 2.0], hurrah. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Any Clojure job out there?
On Apr 18, 11:23 pm, Steven Shaw stes...@gmail.com wrote: You could see each of those jobs saying Java Developer as a potential Clojure job :). In particular, I'd be thinking that places who use Hadoop (and similar things) would be the kind of jobs to look at, with a view to bringing your new favourite language in through the back door. J -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
The end goal
I'll know that this problem is solved when the Setup and Getting Started sections of the main Getting Started page resemble this: - For debian and Ubuntu users: apt-get install clojure For Fedora and CentOS users: yum install clojure For other distributions: wget XXX.tgz tar xvzf XXX.tgz ./XXX/install.sh source /etc/profile Now run the REPL: clj - This implies several things: - The clojure package is in the universe or equivalent repo for respective distros - The clojure package is a meta-package that pulls in all the basics needed for a useable clojure environment: - clojure-base (or whatever it is named as long as it's not 'clojure') - clojure-contrib - Java - documentation and examples - emacs config/example/integration - vim config/syntax highlight files, etc) - a default repl launcher with command line history and one that catches Ctrl-C - Clojure is a first class citizen on the system. It is installed to normal system locations, paths/classpaths are configured to work out of the box, the repl launcher is in /usr/bin (or at least in the system default path) Until Clojure is quite popular, distributions are unlikely to spend effort on packaging it, but Clojure won't become popular until it is packaged well for popular distributions (this is a typical problem actually). This means that the Clojure community will have to have people who know and are willing to endure the tedium of distro packaging. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
I love clojure but I think it's unnecessary it doesn't ship with a simple clj and a clj.bat script out of the box, yeah it's easy to run it with jvm, but who want to type java -server -Djava.ext.dirs=./lib:/opt/bin/lib -cp ~/.emacs.d/lisp-packages/swank-clojure jline.ConsoleRunner clojure.lang.Repl every time they need a repl? sure, command completion, but come on? It's not exactly making life simple. (I know with 1.1 it's not clojure.lang.Repl any more but still lengthy and complicated, though now I use lein so I am happy). Every time I've started up with a clojure project I've had to spend a few hours fiddling with the environment, not that I don't do that with other languages, but it would be nice with an officially sanctioned solution for setting up a sane environment. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Montreal Clojure User Group
As a new Clojure user, I'm in as well. On Feb 22, 5:57 pm, Jeff Heon jfh...@gmail.com wrote: Okay, Google created: http://groups.google.ca/group/montreal-clojure-user-group -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure and OOP
You can work with java objects. But clojure itself is not object oriented, because it's functional, and object orientation requires state manipulation. Other lisps support object orientation, common-lisp for example. cheers, /J On Thu, Feb 11, 2010 at 1:46 PM, HB hubaghd...@gmail.com wrote: Hey, Since Clojure is a LISP dialect, does this mean that it doesn't support OOP? 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.comclojure%2bunsubscr...@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: A new lisper's question about a macro
On Mon, Jan 25, 2010 at 3:42 AM, Richard Newman holyg...@gmail.com wrote: The former is a lot clearer to read, as it uses standard Clojure datastructures. ... which offers other advantages beyond the human, such as (def page-names keys) user= (page-names foobar) (:page :posts :post) Power comes from algorithms × data structures, and hiding the data structures — whilst sometimes beneficial — reduces one's ability to leverage existing algorithms. Very true. Once I had started down the rabbit hole though I had to follow it to the end :-) - Joel Rosario. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: A new lisper's question about a macro
On Mon, Jan 25, 2010 at 3:09 AM, ataggart alex.tagg...@gmail.com wrote: (zipmap (map keyword (take-nth 2 ~params)) (map (comp var-get resolve) (take-nth 2 (next ~params Neat :-) Thanks! - Joel Rosario. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
A new lisper's question about a macro
Hi,
I was wondering whether there was an elegant way to make this macro do
more work:
(defmacro define-template [template-name template-params]
`(def ~template-name (apply merge (map (fn [[k# v#]]
{(keyword k#) (var-get
(resolve v#))})
(partition 2 2 '~template-params)
It's meant to be called like this:
(define-template some-template-name
page some-function-1
posts some-function-2
post some-function-3)
It defs a var called some-template-name bound to a map that looks like this:
{:page some-function-1
:posts some-function-2
:post some-function-3}
But I'm not sure I've written the macro as well as it could be done,
no doubt due my own ignorance. The mapping function call that the
macro emits will do quite a bit of work to create the map that I want.
I was thinking maybe there's more work that the macro can do during
the macro expansion phase.
If you need more context, please have a look at this code:
http://github.com/finalprefix/blog-in-15-minutes/blob/master/test/tests.clj
It's basically toy project to get to know clojure/macros/emacs/compojure better.
Thanks in advance for you thoughts!
Joel Rosario.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Probability Monad
On Fri, Jan 8, 2010 at 2:57 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: It's a bug. More specifically, a typo in a recent improvement. It is fixed now, so please try again with the current version - or in fact go back to an older version before December 28. Thanks! I pulled the latest clojure-contrib source, and my code works now. BTW, I suppose that instead of (domonad dist-m [a die b die] [+ a b]) you want (domonad dist-m [a die b die] (+ a b)) Whups. Yes, you're right, that's precisely what I meant to type! - Joel. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Having difficulties with compilation in slime, emacs and clojure-project
Hello, I have an emacs setup on OSX using elpa with the latest clojure-mode, swank-clojure, slime, slime-repl all from ELPA. When I upgraded to the latest swank-clojure in ELPA (swank-clojure-1.1.0), I began to get this error as well: Searching for program: no such file or directory, lisp I traced it back a bit, and found that the before advice on slime-read- interactive-args wasn't being called. It apparently wasn't activated. I evaluated the following form: (ad-activate 'slime-read-interactive-args) And now all seems to be working well. I'm not sure why this advice hasn't been activated. On the prior versions of swank-clojure, I didn't have this problem. Loading order issue maybe? Anyhow, try explicitly activating that advice and see if that fixes your problem. Cheers, Joel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Probability Monad
Hi,
I'm new to monads in clojure, and I'm loving them, they're really awesome!
But right now I need some help. Either I'm using dist-m wrong, or it's
a bug I've found.
It can be reproduced with:
clojure commit f4c58e3500b3668a0941ca21f9aa4f444de2c652
clojure-contrib commit 25fec5b5771408c30b802b67dc14a15043446a12
Both commits are for the master branch. These are the latest versions
of clojure and clojure-contrib sources that I just pulled this
morning.
This code doesn't work:
(use 'clojure.contrib.monads)
(use 'clojure.contrib.probabilities.finite-distributions)
(def die (uniform [1 2 3 4 5 6]))
(domonad dist-m
[a die
b die]
[+ a b])
The error that I get:
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.util.Map$Entry
[Thrown class java.lang.RuntimeException]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [CAUSE] Throw cause of this exception
Backtrace:
0: clojure.lang.LazySeq.sval(LazySeq.java:47)
1: clojure.lang.LazySeq.seq(LazySeq.java:56)
2: clojure.lang.RT.seq(RT.java:440)
3: clojure.core$seq__4245.invoke(core.clj:105)
4: clojure.core$reduce__4500.invoke(core.clj:657)
5:
clojure.contrib.probabilities.finite_distributions$fn__6616$m_bind_dist__6620.invoke(finite_distributions.clj:36)
6: user$eval__97.invoke(NO_SOURCE_FILE:1)
7: clojure.lang.Compiler.eval(Compiler.java:4642)
8: clojure.core$eval__5236.invoke(core.clj:2017)
9: swank.commands.basic$eval_region__22.invoke(basic.clj:40)
10: swank.commands.basic$eval_region__22.invoke(basic.clj:31)
11: swank.commands.basic$listener_eval__36.invoke(basic.clj:54)
12: clojure.lang.Var.invoke(Var.java:359)
13: user$eval__94.invoke(NO_SOURCE_FILE)
14: clojure.lang.Compiler.eval(Compiler.java:4642)
15: clojure.core$eval__5236.invoke(core.clj:2017)
16: swank.core$eval_in_emacs_package__249.invoke(core.clj:59)
17: swank.core$eval_for_emacs__326.invoke(core.clj:128)
18: clojure.lang.Var.invoke(Var.java:367)
19: clojure.lang.AFn.applyToHelper(AFn.java:179)
20: clojure.lang.Var.applyTo(Var.java:476)
21: clojure.core$apply__4370.invoke(core.clj:436)
22: swank.core$eval_from_control__252.invoke(core.clj:66)
23: swank.core$eval_loop__255.invoke(core.clj:71)
24: swank.core$spawn_repl_thread__387$fn__418$fn__420.invoke(core.clj:183)
25: clojure.lang.AFn.applyToHelper(AFn.java:171)
26: clojure.lang.AFn.applyTo(AFn.java:164)
27: clojure.core$apply__4370.invoke(core.clj:436)
28: swank.core$spawn_repl_thread__387$fn__418.doInvoke(core.clj:180)
29: clojure.lang.RestFn.invoke(RestFn.java:402)
30: clojure.lang.AFn.run(AFn.java:37)
31: java.lang.Thread.run(Thread.java:619)
If I'm using dist-m correctly, I figured the reason might be that
m-bind uses merge-with to merge a collection of vectors, whereas
merge-with works with maps..?
I tried (merge-with + [:a 1] [:b 1]) and got a similar error:
clojure.lang.Keyword cannot be cast to java.util.Map$Entry
[Thrown class java.lang.ClassCastException]
Restarts:
0: [ABORT] Return to SLIME's top level.
Backtrace:
0: clojure.core$key__4739.invoke(core.clj:1036)
1: clojure.core$merge_with__5186$merge_entry__5188.invoke(core.clj:1932)
2: clojure.lang.ArrayChunk.reduce(ArrayChunk.java:50)
3: clojure.core$reduce__4500.invoke(core.clj:666)
4: clojure.core$merge_with__5186$merge2__5191.invoke(core.clj:1937)
5: clojure.core$reduce__4500.invoke(core.clj:668)
6: clojure.core$reduce__4500.invoke(core.clj:659)
7: clojure.core$merge_with__5186.doInvoke(core.clj:1938)
8: clojure.lang.RestFn.invoke(RestFn.java:443)
9: user$eval__140.invoke(NO_SOURCE_FILE:1)
snip
I modified dist-m to evaluate a map instead of a vector, like this:
(defmonad dist2-m
[m-result (fn m-result-dist [v]
{v 1})
m-bind (fn m-bind-dist [mv f]
(reduce (partial merge-with +)
(for [[x p] mv [y q] (f x)]
{y (* q p)})))
])
And now this code:
(domonad dist2-m
[a die
b die]
(+ a b))
yields:
{2 1/36, 3 1/18, 4 1/12, 5 1/9, 6 5/36, 7 1/6, 8 5/36, 9 1/9, 10 1/12,
11 1/18, 12 1/36}
as expected.
Perhaps there's something I'm missing here?
Thanks,
Joel Rosario.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ANN: Web application framework (beta)
Not every web application has to scale. I think that continuation based stuff rocks for adminstration interfaces. The main benefit with continuation based stuff, is that it's possible to build something that is more application like, so that one can avoid building wizards, and having to split up stuff into separate steps. Another good approach for managing state is to build the application in javascript. On Mon, Nov 30, 2009 at 5:09 AM, Jim Powers j...@casapowers.com wrote: This does indeed look cool, but here's the problem I have with all of the continuation-style web-frameworks: they do not scale. This is to say in a web-server farm setting you need a workable stickiness approach since you always have to be routed back to the machine with the continuation you need. So: - In the case of machine or process failure all state information is lost. - It is pretty easy to wind up with a very unbalanced web farm as due to the randomness of user activity it is possible to have all of your active users load-balanced onto only a few machines. - If you force-ably load balance based on session count you can easily under-utilize your web farm. - Since one of the benefits of continuation-based web frameworks is the amount and richness of the data that can be transferred between pages, but this (potentially lots of data) coupled with the problems listed above, can become a serious problem under certain (potentially not-predictable) circumstances. Clearly what would be desired is portable continuations that can be loaded on any machine and/or duplicated/replicated for failure cases. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: roll call of production use?
I have written a production web app with compojure. It was a very nice experience. First project I have pulled of totally TDD and the functional aspect of clojure really makes tests so much easier and more truthful, although there sometimes seems to sneak in some exceptions I didn't expect from the java side. It was a small ad campaign site with some SMS functionality, with web pages formatted for mobile phones. Really nice to be able to just wrap our java libs for sending SMS and device recognition. The compojure HTML generator is fantastic, extremely powerful and easy to use. I am amazed how compact the end code is. I deployed a war file on tomcat 5.5. The app is stable and very fast. One thing I would have liked to have was to start swank-server from the war to provide an easy way to do hot updates and inspection, but I ran into some problem with *1 etc not being defined so I gave up on that. I prefer to deploy a war because I did not want to write my own init.d script and bug test that. Overall - a very nice experience. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Help with xml-seq
Thanks! This is actually kinda close to a solution that I've just
managed to come up with, though mine is somehow twice as long :).
Correct me if I'm wrong, but this could eat up the stack when parsing
a large document? I'm totally fine with it for my current needs,
though I'm curious to see a solution that doesn't.
Thanks again!
-Joel
On Dec 1, 1:03 am, Chouser [EMAIL PROTECTED] wrote:
On Sun, Nov 30, 2008 at 5:12 PM, Joel L [EMAIL PROTECTED] wrote:
I've hit a wall trying to work with tree like data structures,
specifically the xml-seq. I want to translate clojure.xml's xml
representation into something close to compojure's html data
structure.
eg:
{:tag :div :attrs {:class foo}
:content
[{:tag :h1 :attrs nil :content [Title]}
{:tag :p :attrs nil :content [Test]}]}
-
[:div {:class foo} [:h1 Title] [:p Test]]
This has not been deeply tested:
(defn f [{:keys [tag attrs content] :as other}]
(if tag
(vec (concat [tag]
(when attrs [attrs])
(when-let [s (map f content)] (vec s
other))
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
London, UK (Canadian expat) On Oct 17, 8:05 pm, Stewart Griffin [EMAIL PROTECTED] wrote: Birmingham, UK too :) On 17/10/2008, Barry [EMAIL PROTECTED] wrote: Birmingham, UK Barry On Oct 17, 10:27 am, Rastislav Kassak [EMAIL PROTECTED] wrote: Hello Clojurians, I think after 1st year of Clojure life it's good to check how far has Clojure spread all over the world. So wherever are you come from, be proud and say it. I'm from Slovakia. :) RK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
