New Lambda - the functional freelancing hub
I am willing to invite freelancers and those who are seeking for additional hands to register on New Lambda - the functional freelancing hub. As a Clojure shop ourselves, we are starting with Clojure community and so far have received good amount of feedback from first participants. We are on very early stage and testing a lot of things, yet communications, automatic invoicing, escrow protection, payments and other essentials are there, more to come. All countries are covered! Announcement: https://newlambda.com/blog/registration-open Website: https://newlambda.com Should you encounter any issues, or have any questions, please message me here or s...@newlambda.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Customizable project .cpcache path
Currently user cache is customizable via CLJ_CACHE or CLJ_CONFIG (and XDG_..) environment variables, but inside project dir the path is set by the following code in clojure tools bash script: # Determine whether to use user or project cache if [[ -f deps.edn ]]; then cache_dir=.cpcache else cache_dir="$user_cache_dir" fi Which is not always desirable in deployments when project dir is not writeable (e.g. application code is not in home directory) Is it reasonable to add something like CLJ_PROJECT_CACHE or there is a reason to keep it static? 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(Script) web apps in 2018
For me, pedestal as a backend. UI - om.next for complex projects, reagent for simpler. I prefer remixing smaller basic building blocks to "ambitious libraries" like replikativ or even re-frame. Datomic is ideal for most business cases except when its license is somehow incompatible or the architecture should be open to the wider audience. Also honoring Lindy effect prevents a lot of troubles: older libs are less likely to go extinct. Works actually for any domain https://en.wikipedia.org/wiki/Lindy_effect Stan https://immute.co On Monday, September 17, 2018 at 12:27:17 PM UTC+3, Tom Locke wrote: > > Hi all, > > I'm a reasonably experienced ClojureScript developer, finally starting to > think about the server side of a web app I've been working on for some > time. I was wondering if anyone could offer some pointers for libraries > worth looking at. What would you be building on top of if you were starting > a web app in 2018? > > It's a single page app. I've already committed to Reagent on the client. > Will very likely go with Dataomic as the DB. The rest is open for now. > > I realise there is no "right answer" to such a question. All I'm after > here is to take the pulse of the community - "take a look at so-and-so", > "such and such is becoming a de-facto standard", "a few people got burned > with thingumy"... > > I think there are two distinct sub-questions here. First off one is going > to need a general server-side library e.g. Luminus (more a collection of > libraries), and then there is the much bigger question of keeping data in > sync across multiple clients/servers. Here we get into the vast topic of > distributed systems, full of deep, open questions, but I'm hoping for > advice for the working programmer : ) > > Of particular interest would be whether people feel any of the more > ambitious libraries (e.g. Replikative) are worth relying on for a serious > project, or are people generally still rolling their own, RPC style. > > Thanks very much, in advance! > > Tom > > -- You 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: Calling conform from within a macro
Thanks a million! On Wed, Nov 22, 2017 at 15:59 Alex Miller <a...@puredanger.com> wrote: > Your example does work, but it returns the conformed value [a b c] out of > the macro, which the compiler then tries to evaluate. So the exception is > coming downstream. > > See: > > user=> (macroexpand '(test-macro a b c)) > [a b c] > > > > On Wednesday, November 22, 2017 at 1:08:22 AM UTC-6, Stanislav Yurin wrote: >> >> Hi, >> Please help me understand following behavior. >> Speccing macro via fdef and calling explain within a macro works, but >> conform tries to resolve all symbols. >> How to correctly conform macro body from within a macro? >> >> Longer example: >> >> This works: >> >> (spec/def ::test-spec (spec/* any?)) >> >> (spec/fdef test-macro >> :args ::test-spec >> :ret any?) >> >> (defmacro test-macro [& body] >> (println body)) >> >> (test-macro a b c) >> (a b c) >> => nil >> >> >> >> >> This works: >> >> (defmacro test-macro [& body] >> (spec/explain ::test-spec body)) >> >> >> (test-macro a b c) >> Success! >> => nil >> >> >> This doesn't: >> >> >> >> (defmacro test-macro [& body] >> (spec/conform ::test-spec body)) >> >> >> >> (test-macro a b c) >> CompilerException java.lang.RuntimeException: Unable to resolve symbol: >> a in this context >> >> >> >> >> Stanislav. >> >> -- > You 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/ixISA42ucVE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- S. -- You 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.
Calling conform from within a macro
Hi, Please help me understand following behavior. Speccing macro via fdef and calling explain within a macro works, but conform tries to resolve all symbols. How to correctly conform macro body from within a macro? Longer example: This works: (spec/def ::test-spec (spec/* any?)) (spec/fdef test-macro :args ::test-spec :ret any?) (defmacro test-macro [& body] (println body)) (test-macro a b c) (a b c) => nil This works: (defmacro test-macro [& body] (spec/explain ::test-spec body)) (test-macro a b c) Success! => nil This doesn't: (defmacro test-macro [& body] (spec/conform ::test-spec body)) (test-macro a b c) CompilerException java.lang.RuntimeException: Unable to resolve symbol: a in this context Stanislav. -- You 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: diehard 0.1.0, a Clojure wrapper for Failsafe
Thank you.
Also recently made a use of your https://github.com/sunng87/slacker lib -
really interesting approach.
On Thursday, June 30, 2016 at 6:08:27 PM UTC+3, Sun Ning wrote:
>
> Hi all,
>
> Just to announce the first release of diehard[1], a clojure wrapper over
> the Failsafe[2] library, which deals retry stuff for you.
>
> Diehard allows you to set retry criteria for any block a clojure code,
> like:
>
> (diehard/with-retry {:retry-on IOException}
> (http/get "https://google.com;))
>
> The first release only has retry supported, more to come in next few
> versions.
>
> [1]: https://github.com/sunng87/diehard/
> [2]: https://github.com/jhalterman/failsafe
>
>
--
You 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: Opinion on core.async vs callbacks in abstract APIs?
As for the core.async, I think it is too personal and has too much raw power, to be all that restricted in some logical bottleneck upon results return from the third-party lib. Not counting the fact it is a (a) dependency that (b) changes fast. On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote: Greetings I imagine most of us here would rather use core.async channels over callbacks in their application code, particularly with more complicated applications. But is it okay/preferable for Clojure libraries to force their users to use core.async channels as part of an API (an event channel, for example)? As much as I love core.async, I can't help but wonder whether sticking with callbacks for an API isn't a simpler/better design strategy. It's easy enough to drop messages on a channel in a callback, and this let's users opt-in. But if one expects core.async channels are what most would prefer anyway, is it okay to foist them upon everyone? As a follow up, does your opinion on the matter change if implementations of an API become simpler using core.async channels? Looking forward to your thoughts :-) Chris Small PS I'm asking because I'm working on a physical computing API ( https://github.com/clj-bots/pin-ctrl) and debating between using channels vs callbacks for the edge detection functionality (if you're not familiar, edge detection let's you asynchronously handle changes in pin state, such as button pushes). If you're interested in this question as it applies specifically to this application, feel free to join the discussion on our gitter channel: https://gitter.im/clj-bots/chat -- You 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: Opinion on core.async vs callbacks in abstract APIs?
I think returning futures for asynchronous calls is a good tradition in Clojure world. Better than callbacks because you are leaving the threading model choice in the hands of the caller, which is a good thing. On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote: Greetings I imagine most of us here would rather use core.async channels over callbacks in their application code, particularly with more complicated applications. But is it okay/preferable for Clojure libraries to force their users to use core.async channels as part of an API (an event channel, for example)? As much as I love core.async, I can't help but wonder whether sticking with callbacks for an API isn't a simpler/better design strategy. It's easy enough to drop messages on a channel in a callback, and this let's users opt-in. But if one expects core.async channels are what most would prefer anyway, is it okay to foist them upon everyone? As a follow up, does your opinion on the matter change if implementations of an API become simpler using core.async channels? Looking forward to your thoughts :-) Chris Small PS I'm asking because I'm working on a physical computing API ( https://github.com/clj-bots/pin-ctrl) and debating between using channels vs callbacks for the edge detection functionality (if you're not familiar, edge detection let's you asynchronously handle changes in pin state, such as button pushes). If you're interested in this question as it applies specifically to this application, feel free to join the discussion on our gitter channel: https://gitter.im/clj-bots/chat -- You 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: Opinion on core.async vs callbacks in abstract APIs?
Why so? With a callback, someone should be waiting somewhere too, until callback is fired. Why not expose this choice to user. E.g. I am often waiting for the future in the (thread ..) and returning the result to the channel, but again, I like this to be my choice, because there are so much ways of doing this. On Tuesday, June 2, 2015 at 8:04:38 AM UTC+3, tbc++ wrote: The problem with futures is that you can't attach callbacks to them, you can only block a thread waiting on them. So futures interface quite poorly with async libraries, hence the reason core.async was created in the first place. Core.async is a dependency, but it's hardly one that changes fast. The last breaking change was about a year and a half ago (Jan 2014). Besides that, all changes are additional opt-in features. That's a lot less change than most libraries in the Clojure ecosystem. Timothy On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin jus...@gmail.com javascript: wrote: As for the core.async, I think it is too personal and has too much raw power, to be all that restricted in some logical bottleneck upon results return from the third-party lib. Not counting the fact it is a (a) dependency that (b) changes fast. On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small wrote: Greetings I imagine most of us here would rather use core.async channels over callbacks in their application code, particularly with more complicated applications. But is it okay/preferable for Clojure libraries to force their users to use core.async channels as part of an API (an event channel, for example)? As much as I love core.async, I can't help but wonder whether sticking with callbacks for an API isn't a simpler/better design strategy. It's easy enough to drop messages on a channel in a callback, and this let's users opt-in. But if one expects core.async channels are what most would prefer anyway, is it okay to foist them upon everyone? As a follow up, does your opinion on the matter change if implementations of an API become simpler using core.async channels? Looking forward to your thoughts :-) Chris Small PS I'm asking because I'm working on a physical computing API ( https://github.com/clj-bots/pin-ctrl) and debating between using channels vs callbacks for the edge detection functionality (if you're not familiar, edge detection let's you asynchronously handle changes in pin state, such as button pushes). If you're interested in this question as it applies specifically to this application, feel free to join the discussion on our gitter channel: https://gitter.im/clj-bots/chat -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure needs a web framework with more momentum
Colin, Indeed, there is no ready-made shopping cart for Clojure (from what I know). Recently I was making the personal project site, and was also seeking for that, with no luck. Until I have realized that the shopping cart is just two data tables and (optional) user auth system (buddy worked for me). On Sunday, May 3, 2015 at 11:40:33 PM UTC+3, Colin Fleming wrote: A shopping cart. All the available Java ones require a J2EE stack. On 3 May 2015 at 21:49, Sven Richter sve...@googlemail.com javascript: wrote: Hi, Am Sonntag, 3. Mai 2015 11:38:14 UTC+2 schrieb g vim: On 03/05/2015 05:24, Sean Corfield wrote: On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg mark.en...@gmail.com mailto:mark.en...@gmail.com wrote: Clojure is great for creating new, disruptive web models, but what's the easiest path to creating something that can be done trivially with, say, Drupal or Django? The question tho' is why you'd want to use Clojure for something that is already trivially solved with free packaged software for widely used scripting languages where cheap, plentiful developers are falling over themselves to help... :) Clojure doesn't have to be the solution for every problem. It certainly doesn't need to be the solution for low-value problems... Forgive me if that sounds a little elitist. What if I want to do what Django can do but in Clojure? If Clojure is a better option there should be something which can do more than Django. If my only choice is library composition by definition it doesn't do what Django does well, ie. a fully-structured setup out of the box with a predictable, best of breed set of technologies. There are many businesses, large and small, who will only go with a well-established web framework with a vibrant community. Sadly, Clojure's preference for protecting its niche means it will never be an option for these opportunities, hence its poor showing in job listings. Do we, as a community, want to be paid for what we do? Again I am missing some exact requests on what can be done in django that cannot be done in clojure? This by no means an offense, I am just curious about your experiences. Best Regards, Sven -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure needs a web framework with more momentum
A bit strange approach. Where are ring, compojure, or maybe .. om? Also, most of the time you do not need any complex framework to build a basic webservice with Clojure. Say, Luminus and Caribou are too complex for me, hence too restrictive. After writing sufficient amount of fairly good Clojure code, super rapid web-service mocking skills come to you as a bonus. On Saturday, May 2, 2015 at 11:43:53 PM UTC+3, g vim wrote: I recently did some research into web frameworks on Github. Here's what I found: FRAMEWORK LANG CONTRIBUTORS COMMITS LuminusClojure28678 CaribouClojure 2275 BeegoGolang991522 PhoenixElixir 1241949 YesodHaskell 1303722 LaravelPHP2684421 PlayScala 4176085 SymfonyPHP113020914 RailsRuby 269151000 One could conclude from this that the Clojure community isn't that interested in web development but the last Clojure survey suggests otherwise. Clojure's library composition approach to everything only goes so far with large web applications, as Aaron Bedra reminded us in March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower means less momentum and more bugs. Furthermore, I have a hunch that Clojure's poor adoption as indicated by Indeed.com maybe due to this immaturity in the web framework sphere. Why is it that Elixir, with a much smaller community and lifespan than Clojure's, has managed to put 4 times as much mindshare into its main web framework when its module output, as measured by modulecounts.com, is a tiny fraction of Clojure's? 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/d/optout.
Re: Explicitly document return values in some core.async functions?
Thanks, this is perfectly reasonable! On Wednesday, April 22, 2015 at 4:35:17 PM UTC+3, Stuart Sierra wrote: core.async is still technically alpha, so everything is potentially subject to change. Rich H. wrote[1] most of those core.async functions, and he tends to treat the docstring as the only contract for future releases. If you want to be safe, make a unit test in your app that specifically tests any undocumented properties of public functions, so you can see if and when they change. [1]: https://github.com/clojure/core.async/blame/d8047c0b0ec13788c1092f579f03733ee635c493/src/main/clojure/clojure/core/async.clj#L455 –S On Wednesday, April 22, 2015 at 11:26:11 AM UTC+1, Stanislav Yurin wrote: Hello, There are functions like 'pipe' and 'tap' that are returning back receiving channel parameter, but this behavior is not explicitly documented. Should we rely on this feature or this may be changed in future? Thanks. Stanislav. -- You 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.
Explicitly document return values in some core.async functions?
Hello, There are functions like 'pipe' and 'tap' that are returning back receiving channel parameter, but this behavior is not explicitly documented. Should we rely on this feature or this may be changed in future? Thanks. Stanislav. -- You 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] projars.com
Hi Joshua, Your answer is very much appreciated. My hypothesis right now is that highly successful /open source/ projects, already having profit or not, can usually take care of themselves. As well as hardly any established software company needs a broker. But examples on everyone's lips are very very small part of real ecosystem. Something like 0.1%, and that could be very optimistic. What is of particular interest for me is other 99.9%, first of all because I myself have belonged to that part for a long time, have seen hundreds of active and abandoned projects of various quality, completeness and success. To say in general, one does not need to have incredibly large user base to make her living, neither to be the github, blogging and tutorial blockbuster. Take a walk from any street around the corner and count small businesses down there. Probably a half dozen. Probably you see and hear them for the first time. But they are still there, as well as another pack around the next corner. Currently I am looking to such services as Codecanyon, Binpress as an example of what could be done, or, to be more precise, as an evidence that something could be done. What license types can work out for Clojure and similar communities, that is the good subject for experimenting. I am no prophet, and, as you can see, the best I can do right now is to ask questions and make assumptions. Thanks again for you attention. Stanislav. On Thursday, November 28, 2013 11:40:57 PM UTC+2, Joshua Ballanco wrote: On Thursday, November 28, 2013 at 12:10, Stanislav Yurin wrote: Hello, Clojure community. I have been following the Clojure path for nearly two years now, and have really great pleasure using it in my personal and job projects, watching the community delivering a lot of great things, most of that I have yet to taste. For some time I was incubating an idea of introducing the infrastructure which may help regular developers like myself and businesses make some income from what we are creating on daily basis, and improve the creations further. In short, on top of every open greatness, it is good to have options. The last thing I am willing to do is to build something no one needs, so I have decided to evaluate an idea. The idea is simple: introducing the commercial option to the great ecosystem we already have. Proposed http://projars.com concept is similar to well-organised clojars/leiningen/maven content delivery system but with commercial products in mind. I have put the small introduction on the site, please feel free to subscribe on site if you are interested, discuss, throw the stones in my direction etc. Again, the link is http://projars.com Any feedback will help a lot. Hi Stanislav, It’s an interesting idea to be sure. I think that, as open source and software in general “eat the world”, there will definitely be room for interesting new ways for people to be able to contribute to the community while still putting a roof over their heads and food on their tables. Soliciting donations/tips is one model. Crowd funding is another. However, in both cases I think there is an outlier effect at play where a few people will do very well, but most will never reach sustainability. On the other hand, there are some models that I’ve seen work very well for different people: * Premium features: a project where a large chunk of the functionality is available as open source, but some critical piece (usually related to scale) is only available to paying customers. Successful projects I’ve seen work this model include Phusion Passenger, Riak, Sidekiq, and Datomic. The quite obvious difficulty with this model is that you need to have a pre-existing product, probably a fairly sizable one, before people are willing to pay for premium features. * Feature bounties: an open source project where financial backers may pay some sum to have their pet features prioritized over others. LuaJIT, famously, has been completely financed via this model. The difficulty with this model is that you probably need to have a fairly well established reputation and project before just anyone is willing to pay you for a feature (also known as: we can’t all be Mike Pall). * Commercial dual licensing: if you release an open source project under the GPL, many commercial organizations won’t use it. However, as the author of an open source project, you are free to sell these commercial organizations a copy of the software under different licensing terms. This way the open source community can benefit, and the corporate lawyers can be kept happy at the same time. This is probably best recognized as MySQL’s model, but I know of others (including Glencoe Software, my current employer) who have made this work. The difficulty here is that, since you’d be providing the same source
[ANN] projars.com
Hello, Clojure community. I have been following the Clojure path for nearly two years now, and have really great pleasure using it in my personal and job projects, watching the community delivering a lot of great things, most of that I have yet to taste. For some time I was incubating an idea of introducing the infrastructure which may help regular developers like myself and businesses make some income from what we are creating on daily basis, and improve the creations further. In short, on top of every open greatness, it is good to have options. The last thing I am willing to do is to build something no one needs, so I have decided to evaluate an idea. The idea is simple: introducing the commercial option to the great ecosystem we already have. Proposed http://projars.com concept is similar to well-organised clojars/leiningen/maven content delivery system but with commercial products in mind. I have put the small introduction on the site, please feel free to subscribe on site if you are interested, discuss, throw the stones in my direction etc. Again, the link is http://projars.com Any feedback will help a lot. Stanislav. -- -- You 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] projars.com
Hi, Thanks Bastien, Josh, I think we have yet to find an example of such kind of swallowing, if any exists. On contrary, we even have plenty of examples when commercial projects turned FOSS, not talking about peaceful coexistence of openness and alternative licensing schemes. And it is often a question of personal freedom for many, after all (let me begin with myself). On Thursday, November 28, 2013 12:53:22 PM UTC+2, Bastien Guerry wrote: Hi Stanislav, Stanislav Yurin jus...@gmail.com javascript: writes: In short, on top of every open greatness, it is good to have options. Indeed. The last thing I am willing to do is to build something no one needs, so I have decided to evaluate an idea. The idea is simple: introducing the commercial option to the great ecosystem we already have. Proposed http://projars.com concept is similar to well-organised clojars/leiningen/maven content delivery system but with commercial products in mind. I've nothing against such a move, as long as it does not swallow some of the free software code out there. But I guess it won't. I'm working on a website where people will be able to ask donations more easily for their FLOSS achievements and future projects, I'd love to see both directions (more commercial options and more crowdfunded FLOSS libraries) encouraged at the same time. 2 cents, -- Bastien -- -- You 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: Reducers newbie question
Yep, thanks, my bad. I got the point. Actually, what I was trying to do, is to prototype multithreaded i/o operation via reducers. And then use fold to regulate number of concurrent operations. But now something tells me I am doing not very clever thing. On Friday, April 26, 2013 5:27:46 PM UTC+3, Stanislav Yurin wrote: I was assuming that following code will fold in parallel, but it is reduced sequentially (require '[clojure.core.reducers :as r]) (defn test1 [x] (Thread/sleep 1000) (println (str Finished: x)) x) (def xxx (r/map test1 (range 100))) (r/fold + xxx) What am I doing wrong? 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: Reducers newbie question
Thanks Alan, looking into it. By the way, fold function has [n combinef reducef coll] implementation, where n is number of elements collection is folded by. 512 is just the default. On Saturday, April 27, 2013 3:51:39 PM UTC+3, Alan Busby wrote: On Sat, Apr 27, 2013 at 7:35 PM, Stanislav Yurin jus...@gmail.comjavascript: wrote: Actually, what I was trying to do, is to prototype multithreaded i/o operation via reducers. And then use fold to regulate number of concurrent operations. But now something tells me I am doing not very clever thing. I'm not entirely sure what you mean above, but I've been very happy using reducers with I/O so far. Reducers just have a few tricks you need to be aware of first; 1. You wont get parallel processing unless the input is a vector. 2. Each thread gets ~512 elements each, so reducing a vector of 800 elements will only use two cores. 3. How you aggregate your final result can greatly impact performance. (Ex. (r/fold +) is fast, fold-into-vec is slower, etc) I wrote a library to use reducers over text files (input) and have found it to be invaluable for working with giant TSV files. Link: https://github.com/thebusby/iota/ I often then use fold-into-lazy-seq to write the output back to a file. Link: https://gist.github.com/thebusby/5472980 Hope this helps! ;) -- -- You 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: Reducers newbie question
Indeed, that was my really bad example with 100. On Saturday, April 27, 2013 4:19:07 PM UTC+3, Alan Busby wrote: On Sat, Apr 27, 2013 at 10:01 PM, Stanislav Yurin jus...@gmail.comjavascript: wrote: By the way, fold function has [n combinef reducef coll] implementation, where n is number of elements collection is folded by. 512 is just the default. Yep I misspoke there, but it is still one of the tricks to be aware of. Lots of people do; (- (range 100) vec (r/filter even?) (r/fold +)) And wonder why it's not running in parallel. -- -- You 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.
Reducers newbie question
I was assuming that following code will fold in parallel, but it is reduced sequentially (require '[clojure.core.reducers :as r]) (defn test1 [x] (Thread/sleep 1000) (println (str Finished: x)) x) (def xxx (r/map test1 (range 100))) (r/fold + xxx) What am I doing wrong? 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.
