Re: [ANN] org.clojure/tools.cli 0.4.1
Thanks, Sean.
Any chance you could update the API documentation
here: http://clojure.github.io/tools.cli/index.html
On Sunday, September 23, 2018 at 5:18:44 AM UTC+2, Sean Corfield wrote:
>
> Tools for working with command line arguments.
> https://github.com/clojure/tools.cli clj -Sdeps '{:deps
> {org.clojure/tools.cli {:mvn/version "0.4.1"}}}'
> Boot/Leiningen: [org.clojure/tools.cli "0.4.1"] This is a minor update
> that introduces new options :update-fn and :default-fn that make it easier
> to work with non-idempotent command line options (such as
> incrementing/counting options) and addresses a problem raised in
> https://dev.clojure.org/jira/browse/TCLI-90 (poor interaction between the
> existing :assoc-fn and :default options).
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You 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] 2016 State of Clojure Community Survey
On Tuesday, December 13, 2016 at 2:00:10 AM UTC+1, Mike Rodriguez wrote: > > Uh oh. I should have asked. I ranked my priorities in the exact opposite > order since I thought 1 was lowest. I did too. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure.spec - Why should you use and when
Hi Rickesh Take a look at this: http://clojure.org/about/spec -Patrick On Sunday, December 11, 2016 at 5:30:19 PM UTC+1, Rickesh Bedia wrote: > > Hello, > > I have recently watched Rich Hickeys talk at Cojure Conj 2016 ( > https://www.youtube.com/watch?v=oyLBGkS5ICk - here's the link in case > anyone missed it) and although it was very interesting, I didn't really > understand the point in Clojure.Spec or when you'd use it. It seemed like > most of the ideas, such as conform, valid etc, had similar functions in > Clojure already. > > I have only been learning clojure for around 3 months now so maybe this is > due to lack of programming/Clojure experience. > > 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: clojure.spec and the rest of clojure
Hi For your first question, have a look at this thread: https://groups.google.com/forum/#!topic/clojure/d_3V9MfLZmY - Patrick On Monday, June 13, 2016 at 8:18:30 AM UTC+2, Philip Markgraf wrote: > > Rich's session on the Cognicast brought up interesting questions for me. > > - Is Clojure.spec being applied within clojure.core and other parts of the > language? > - Has the test.check capability led to the discovery of bugs in > clojure.core and other parts of the language? > - Does anyone (else) anticipate that test.check testing of clojure.core > and other libraries _will_ lead to bug discoveries. > > I am guessing that spreading clojure.spec across the historic code base is > a non-trivial effort. Is it something that will be receiving focus from the > greater team in the coming months? It does seem like a worthwhile effort. > > 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: Simple memory usage tuning for clojure
Well, Tim, there's an idea for material for your Pivotshare videos: how to use YourKit efficiently. I'd watch. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: Ted Dziuba: The S in REST
On Wednesday, October 14, 2015 at 5:49:06 AM UTC+2, James Reeves wrote: > > Of course, the difficulty with this architecture is that few databases > have fast, immutable snapshots built in, so you'd have to get a little > creative with your database design. > Which, I guess, is where Datomic would fit in perfectly :-) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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.
Ted Dziuba: The S in REST
Hi everyone Has anyone read and given any thoughts to the ideas about immutability and REST by Ted Dizuba here: http://teddziuba.github.io/2014/08/18/the-s-in-rest/ Has anyone done anything resembling this? I think the ideas sounds intriguing. Best regards, Patrick -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: Immediate streaming of shell cmd stdout to a browser
Could it be that the client does not support "streaming" the result and instead waits until the server finishes the request? I don't think the browser or standard AJAX requests let you stream the result. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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.
When to use (ensue) ?
I believe it is to avoid write skew. Check this Wikipedia page: http://en.m.wikipedia.org/wiki/Snapshot_isolation -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: Is it possible to find the number of cores
http://stackoverflow.com/questions/4759570/finding-number-of-cores-in-java On Saturday, April 12, 2014 4:43:56 PM UTC+2, Cecil Westerhof wrote: I am experimenting with concurrent programming. Is it possible to determine how many cores there are on a system? Because it is in the case I am working on at the moment not profitable to use more threads as there are cores. (That slows the program down.) Can I find out the number of cores of the system where the program is running. Preferable system independent. Is there also a possibility to get the load of a system? When the load is low, I could start more threads as when the load is high. -- Cecil Westerhof -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: Is Clojure right for me?
Maybe it would be helpful to define what exactly you mean by OOP. Use this list: http://www.paulgraham.com/reesoo.html Clojure supports some of the constructs that people typically relate to OOP. Decomposing large systems: How do you decompose large systems with OOP? By using classes and objects? I don't believe that classes and objects tell you much about how to structure systems (comprised of multiple subsystems). It tells you more about how to view the software you are writing at a small scale, and it tells you how to build a mental image of your programs. In any case, you can use established principles in Clojure programming that transcends language paradigms, e.g., hiding implementation details, creating well-defined interfaces and data structures, separating concerns (making things simple, as they say in the Clojure community). If you are hoping to find a feature set in Clojure that matches what you are already familiar with, you may end up disappointed. Is Clojure the right language for you? It probably depends mostly on personal taste and willingness to change perspective. Best regards, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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] Slamhound 1.5.0 + screencast + Vim plugin
Great work! Regarding the screencast: I would be very interested to hear about your Clojure development setup with Vim, especially the plugins and configuration you are using. I see you are using some sort of split view with Vim on top and a REPL at the bottom. Is that GNU screen split in two or something? Best regards, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: 2013 State of Clojure ClojureScript survey results
This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. Of course clojure is a relatively new language, with a much smaller number of users than javascript, python, and ruby, so I expect the libraries to be less complete. What I don't expect is clojure users to report that the libraries are just great. Clojure libraries are very weak compared to other modern languages. Don't you think it counts that you can easily use the underlying platform's facilities? If you are using ClojureScript with nodejs, you can just use the path functions present there. If you are using Clojure on the JVM, you have an equivalent option. This may even be the explanation that you feel Clojure libraries are 70 % implemented, because it is so easy to use what is already available. I don't think it is always feasible or a good idea to reimplement the platform's facilities just to make them look more Clojuresque. Furthermore, I don't believe that you can even consider it unidiomatic to use your platform through Clojure's interop. Remember, one of Clojure's value proposition is exactly that: the ability to reuse the libraries already available on the host platform. Best regards, Patrick -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You 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: Call for masters thesis ideas (possibly related to Clojure)
On Dec 19, 1:52 am, ajay gopalakrishnan ajgop...@gmail.com wrote: Put *Comparative performance evaluation of Java threads for embedded applications**: Linux thread vs. Green thread Your Google search skills are obviously beyond ours. :) I've found it now. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Call for masters thesis ideas (possibly related to Clojure)
I want to thank you all for your suggestions, the clojure community is really great! On Dec 18, 1:35 pm, Patrick Kristiansen patrick.kristian...@gmail.com wrote: Hi We're two students that have been working with concurrent programming languages (Erlang and Clojure), and while both languages are very interesting, we would like to work on something related to Clojure in our masters thesis. I once asked on #clojure for ideas, and Rich Hickey suggested looking into predicate dispatch and it is one idea that we are considering. We have also considered working on distributed Clojure, but I don't know if there is already an effort going on in that regard? Do you have any other suggestions? We'd be really thankful for any suggestions. Thanks in advance. -Patrick -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Call for masters thesis ideas (possibly related to Clojure)
Hi We're two students that have been working with concurrent programming languages (Erlang and Clojure), and while both languages are very interesting, we would like to work on something related to Clojure in our masters thesis. I once asked on #clojure for ideas, and Rich Hickey suggested looking into predicate dispatch and it is one idea that we are considering. We have also considered working on distributed Clojure, but I don't know if there is already an effort going on in that regard? Do you have any other suggestions? We'd be really thankful for any suggestions. Thanks in advance. -Patrick -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Call for masters thesis ideas (possibly related to Clojure)
On Dec 18, 11:06 pm, Joost jo...@zeekat.nl wrote: Erm, what's your master? I'll assume CS. Well it's software engineering, but close enough :). I should have mentioned that. Personally, I'm interested in whether complete thread abstraction that makes threads as light-weight as possible, but also the only way to do concurrency (like Erlang provides with its processes) is really the best way to model concurrent programs. I'm over 95% sure that native threads really are not the best way to model in-process concurrency for most programs, simply because of all the overhead that you incur especially when dealing with massively concurrent long- running thead-like-things - since you both know erlang, you will know what I'm talking about - that sort of approach really doesn't work in clojure, that's why clojure uses thread pools for agents etc. But maybe a new and lightweight in-kernel thread model is an interesing subject? Just asking :) Thanks for your suggestion. It's an interesting idea, and we've been considering something along those lines. I don't know if Erlang's processes are even more lightweight than green threads. According to Wikipedia [1], Linux actually performs really well in terms of context switching OS threads compared to green threads. But I can't find the paper Wikipedia cites, and it seems not to be downloadable from ACM [2]. In any case, we will take this suggestion into consideration. [1] http://en.wikipedia.org/wiki/Green_threads#Performance [2] http://portal.acm.org/citation.cfm?id=603551 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
