Calling an overloaded Scala function
I am trying to call into some Scala that has the following overloaded methods : def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new AtomicDist(name, clauses.toList, collection) def apply[T](clauses: (Element[Double], Element[T])*)(implicit name: Name[T], collection: ElementCollection) = new CompoundDist(name, clauses.toList, collection) So one method takes a list of tuples of Double to Element and the other method takes a list of tuples of Element to Element. I am using t6.from-scala (https://github.com/t6/from-scala) to build up my list of Tuples. But when building these up there is no way to specify explicit type information about the collections. Consequently when calling this apply method Clojure will always choose to call the first method - even when my list is a collection of Element to Element tuples. I can definitely appreciate how it is going to be tricky for Clojure to determine the correct overload to use here. Is there any way I can somehow force it to call the correct overload myself? Thanks Stephen -- 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: Basic question: what's the difference between require as and use as?
I always have (:use clojure.core) in a new namespace. Is that necessary or is clojure.core is automatically interned when a new namespace is created? On Jun 23, 2015, at 6:37 AM, Gary Verhaegen gary.verhae...@gmail.com wrote: Unless you have a very compelling reason, just don't use use. It's mostly a historical accident that's kept there for backwards compatibility. And try to avoid :refer :all if possible. There are legitimate use-cases for it, but outside the REPL they are pretty rare. On Tuesday, 23 June 2015, Ritchie Cai ritchie...@gmail.com mailto:ritchie...@gmail.com wrote: Ah, I see. I thought “use :as” will not intern all the symbols into current namespace, apparently that’s not the case. Thanks for clearing this up. Ritchie On Jun 22, 2015, at 4:52 PM, Sean Corfield s...@corfield.org javascript:; wrote: On Jun 22, 2015, at 2:39 PM, Ritchie Cai ritchie...@gmail.com javascript:; wrote: Ok, so require without :refer will default to :refer :all? No. (:use [clojure.java.io http://clojure.java.io/]) is equivalent to (:require [clojure.java.io http://clojure.java.io/ :refer :all]) There’s no :as here. :use is like :require :refer :all. (:use [clojure.java.io http://clojure.java.io/ :as io]) is equivalent to (:require [clojure.java.io http://clojure.java.io/ :as io :refer :all]) There’s an :as in both here. :use :as is like :require :as :refer :all Both :use and :refer :all (in :require) are discouraged because they pollute your namespace with every symbol from the used/required namespace. There’s not much point in specifying an alias (with :as) for :use or :require :refer :all since those bring in every symbol directly anyway. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ http://corfield.org/ 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 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+unsubscr...@googlegroups.com javascript:; For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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/ned76MpB-W0/unsubscribe https://groups.google.com/d/topic/clojure/ned76MpB-W0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout 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 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+unsubscr...@googlegroups.com javascript:; For more options, visit this group at http://groups.google.com/group/clojure?hl=en 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 javascript:;. For more options, visit https://groups.google.com/d/optout 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 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/ned76MpB-W0/unsubscribe https://groups.google.com/d/topic/clojure/ned76MpB-W0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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
Re: I'm trying to decode some source code to understand how it works
Hi Gregg, When you look at the function given as the first argument to 'recurse', (fn [f g] #(f (apply g %))), how do you think about when '%' is replaced by [1 2 3 4]? Does this happen only when 'recurse' has consumed all the items in the collection it's been given (as the second argument)? I would guess that given an expression such as: ((mycomp inc first reverse) [1 2 3 4]) Clojure will first evaluate the innermost list, building a composed function with reduce, and only then pass the vector [1 2 3 4] to such composed function in any case, the good thing about pure functional programming is that you don't have to worry too much about the evaluation order, the result should be the same hth, -Gianluca -- 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] Introducing Yagni, a Leiningen plugin for finding unused code
Hello everyone. I'm happy to announce the initial release of Yagni, a Leiningen plugin for finding unused code. At a high level, Yagni works by identifying all of the interned vars in the namespaces findable within your :source-paths, and then walking the forms of those vars. As it walks the forms, it builds a graph of references to other vars. It then searches the graph from a set of entrypoints (by default your project's :main method), and emits warnings for any vars that it couldn't find in the graph's search. There's some other clever stuff going on there and some options for additional customization as well. I've written up a blog post, located here http://blog.venanti.us/yagni/, that goes into considerably more detail on how the plugin works and what the project's roadmap looks like. For those of you who want to look at the repository, it's on GitHub here: https://github.com/venantius/yagni And, of course, for those of you who just want to get started fiddling, you can add the following to your project's plugins map `[venantius/yagni 0.1.1]` and type `lein yagni` to give it a whirl. Cheers! - V -- 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: Basic question: what's the difference between require as and use as?
I see. Thanks. On Jun 23, 2015, at 11:02 AM, Fluid Dynamics a2093...@trbvm.com wrote: On Tuesday, June 23, 2015 at 10:40:25 AM UTC-4, Ritchie Cai wrote: I always have (:use clojure.core) in a new namespace. Is that necessary or is clojure.core is automatically interned when a new namespace is created? It depends. Yes if you use (ns foo) ..., but not apparently if you use (in-ns 'foo) which might be done in certain metaprogramming situations, or during repl experimentation. -- 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 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/ned76MpB-W0/unsubscribe https://groups.google.com/d/topic/clojure/ned76MpB-W0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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: Cider form-init buffer
When exactly does this appear? It's just a file used by Clojure for code evaluated in a REPL, but shouldn't appear in CIDER at all (except in stacktraces). On 23 June 2015 at 18:56, dtouch3d completely dtouc...@gmail.com wrote: Is there a way to disable the /tmp/form-init*.clj buffer from showing when there is an error in evaluation ? It can be very annoying as I am new to clojure and emacs and it replaces my source file buffer and provides no useful information. The cider-error buffer is more than adequate for understanding the error. 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. -- 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.
Cider form-init buffer
Is there a way to disable the /tmp/form-init*.clj buffer from showing when there is an error in evaluation ? It can be very annoying as I am new to clojure and emacs and it replaces my source file buffer and provides no useful information. The cider-error buffer is more than adequate for understanding the error. 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: Basic question: what's the difference between require as and use as?
On Tuesday, June 23, 2015 at 10:40:25 AM UTC-4, Ritchie Cai wrote: I always have (:use clojure.core) in a new namespace. Is that necessary or is clojure.core is automatically interned when a new namespace is created? It depends. Yes if you use (ns foo) ..., but not apparently if you use (in-ns 'foo) which might be done in certain metaprogramming situations, or during repl experimentation. -- 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: Cider form-init buffer
It appears when I try to evaluate code that has syntactic errors. On Tuesday, June 23, 2015 at 7:42:10 PM UTC+3, Bozhidar Batsov wrote: When exactly does this appear? It's just a file used by Clojure for code evaluated in a REPL, but shouldn't appear in CIDER at all (except in stacktraces). On 23 June 2015 at 18:56, dtouch3d completely dtou...@gmail.com javascript: wrote: Is there a way to disable the /tmp/form-init*.clj buffer from showing when there is an error in evaluation ? It can be very annoying as I am new to clojure and emacs and it replaces my source file buffer and provides no useful information. The cider-error buffer is more than adequate for understanding the error. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com 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: Cider form-init buffer
Submit a ticket to the issue tracker with some repro steps and I'll take a look at it. I've never seen this behaviour (and nobody has reported it so far), so I'm guessing something in your setup is uncommon. On 23 June 2015 at 21:27, dtouch3d completely dtouc...@gmail.com wrote: It appears when I try to evaluate code that has syntactic errors. On Tuesday, June 23, 2015 at 7:42:10 PM UTC+3, Bozhidar Batsov wrote: When exactly does this appear? It's just a file used by Clojure for code evaluated in a REPL, but shouldn't appear in CIDER at all (except in stacktraces). On 23 June 2015 at 18:56, dtouch3d completely dtou...@gmail.com wrote: Is there a way to disable the /tmp/form-init*.clj buffer from showing when there is an error in evaluation ? It can be very annoying as I am new to clojure and emacs and it replaces my source file buffer and provides no useful information. The cider-error buffer is more than adequate for understanding the error. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to 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] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit - it
means that ylet can be used in nested calls, too - for example, to set up
and compose groups of components/sub-systems: (contrived example, though!)
;; (docs for ylet at https://github.com/james-henderson/yoyo#introducing-ylet )
(require '[yoyo :refer [ylet]])
(defn with-connections [config f]
(ylet [db-pool (with-db-pool (:db config))
es-conn (with-es-connection (:elasticsearch config))]
(f {:db-pool db-pool
:es-conn es-conn})))
(defn make-system [latch]
(let [config ...]
(ylet [connections (with-connections system)
_ (with-webserver {:handler (make-handler (merge connections
{:config config}))
:port 3000})]
(latch
How would you see the with-* functions working, btw?
Cheers,
James
On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server)
(latch
to:
(yoyo/foo! [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server))
I believe with-* function can also be simplified further.
On Tue, Jun 23, 2015 at 1:18 AM, James Henderson ja...@jarohen.me.uk
javascript: wrote:
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less, function
composition-based alternative to Component. It's still in its early stages,
so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be de-coupled from the
concept of 'reloadable systems', so you won't find any configuration,
dependency injection, etc - just a way to write a system that can be easily
started, stopped, and reloaded.
Fundamentally, we start by assuming there's a function available that
only returns 'when the system stops' - a 'latch', say. If we had such a
function, we could start our system, call that function, then stop the
system (closing any necessary resources). A database pool, for example,
might look like this:
(defn with-db-pool [db-config f]
(let [db-pool (start-pool! db-config)]
(try
(f db-pool)
(finally
(stop-pool! db-pool)
Here, we're assuming that we'll be passed 'f', the 'latch' function. A
web server would be similar, and, because they're both functions, they're
very simple to compose:
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
:port ...}
(fn [web-server]
;; TODO: Ah. We've run out of turtles. :(
This is where Yo-yo comes in - there’s a function called run-system!,
which takes a function that accepts a latch:
(:require [yoyo])
(yoyo/run-system!
(fn [latch]
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
we have access to the db-pool here - no need for global state!
:port ...}
(fn [web-server]
(latch))) ; Aha!
run-system! then returns a promise - deliver any value to it, and it'll
stop the system.
And that's pretty much it! There are a few more functions - mostly to do
with easily starting/stopping/reloading a system through the REPL, and a
macro to simplify the 'function staircase' - these are covered in more
detail in the README. There are some also common components - a database
pool, a web server, and a simple integration for existing Component systems.
It'd be great to hear your thoughts/ideas, whatever they may be - either
through here, e-mail, Github, or Twitter - thanks!
James
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.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
Re: roundtripping using data.xml?
Matching Socks, thanks for mentioning the design page I created. I haven't pushed anything recently, but I'm still working on the rewrite implementing the proposal: https://github.com/bendlas/data.xml I've also made a library, that uses a snapshot from my rewrite to implement a WebDAV server: https://github.com/bendlas/davstore/blob/master/src/davstore/dav.clj I'm now in the process of simplifying my data.xml rewrite based on experience with the library. E.g. I intend to drop the raw mode described in the design page and instead make it possible to transduce the event stream in order to implement such modes. If you are thinking about rolling your own xml processing, please also consider joing efforts on data.xml. 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: Writing REST api the right way
On Tue, Jun 23, 2015 at 11:19 AM, Mike Grabowski grab...@gmail.com wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) It would be really cool if documentation could be generated from Liberator resource defs (http://clojure-liberator.github.io/). Maybe it's possible right now and I don't know about it. 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. -- 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/d/optout.
Writing REST api the right way
Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server)
(latch
to:
(yoyo/foo! [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server (with-web-server server-opts)]
(do-this web-server)
(do-that db-pool web-server))
I believe with-* function can also be simplified further.
On Tue, Jun 23, 2015 at 1:18 AM, James Henderson ja...@jarohen.me.uk
wrote:
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less, function
composition-based alternative to Component. It's still in its early stages,
so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be de-coupled from the
concept of 'reloadable systems', so you won't find any configuration,
dependency injection, etc - just a way to write a system that can be easily
started, stopped, and reloaded.
Fundamentally, we start by assuming there's a function available that only
returns 'when the system stops' - a 'latch', say. If we had such a
function, we could start our system, call that function, then stop the
system (closing any necessary resources). A database pool, for example,
might look like this:
(defn with-db-pool [db-config f]
(let [db-pool (start-pool! db-config)]
(try
(f db-pool)
(finally
(stop-pool! db-pool)
Here, we're assuming that we'll be passed 'f', the 'latch' function. A
web server would be similar, and, because they're both functions, they're
very simple to compose:
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
:port ...}
(fn [web-server]
;; TODO: Ah. We've run out of turtles. :(
This is where Yo-yo comes in - there’s a function called run-system!,
which takes a function that accepts a latch:
(:require [yoyo])
(yoyo/run-system!
(fn [latch]
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
we have access to the db-pool here - no need for global state!
:port ...}
(fn [web-server]
(latch))) ; Aha!
run-system! then returns a promise - deliver any value to it, and it'll
stop the system.
And that's pretty much it! There are a few more functions - mostly to do
with easily starting/stopping/reloading a system through the REPL, and a
macro to simplify the 'function staircase' - these are covered in more
detail in the README. There are some also common components - a database
pool, a web server, and a simple integration for existing Component systems.
It'd be great to hear your thoughts/ideas, whatever they may be - either
through here, e-mail, Github, or Twitter - thanks!
James
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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.
--
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/d/optout.
Re: Basic question: what's the difference between require as and use as?
Unless you have a very compelling reason, just don't use use. It's mostly a historical accident that's kept there for backwards compatibility. And try to avoid :refer :all if possible. There are legitimate use-cases for it, but outside the REPL they are pretty rare. On Tuesday, 23 June 2015, Ritchie Cai ritchie...@gmail.com wrote: Ah, I see. I thought “use :as” will not intern all the symbols into current namespace, apparently that’s not the case. Thanks for clearing this up. Ritchie On Jun 22, 2015, at 4:52 PM, Sean Corfield s...@corfield.org javascript:; wrote: On Jun 22, 2015, at 2:39 PM, Ritchie Cai ritchie...@gmail.com javascript:; wrote: Ok, so require without :refer will default to :refer :all? No. (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io :refer :all]) There’s no :as here. :use is like :require :refer :all. (:use [clojure.java.io :as io]) is equivalent to (:require [ clojure.java.io :as io :refer :all]) There’s an :as in both here. :use :as is like :require :as :refer :all Both :use and :refer :all (in :require) are discouraged because they pollute your namespace with every symbol from the used/required namespace. There’s not much point in specifying an alias (with :as) for :use or :require :refer :all since those bring in every symbol directly anyway. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ 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 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+unsubscr...@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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/ned76MpB-W0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@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 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+unsubscr...@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+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to share the large files that can not fit in Github?
There is also a git annex command. I have not use it personally, but my understanding is that it is essentially keeping a hash of the file (and perhaps a url to download it?) in source control in git, without adding the file itself. That way git can tell when the file has changed, without polluting the git repo itself. On Monday, 22 June 2015, Daniel Jomphe danieljom...@gmail.com wrote: Since you mentioned GitHub, have you looked at Git Large File Storage? https://github.com/blog/1986-announcing-git-large-file-storage-lfs On Monday, June 22, 2015 at 4:09:31 PM UTC-4, Mohit Thatte wrote: AWS S3 is a great place to put large files https://aws.amazon.com/blogs/aws/amazon-s3-object-size-limit/. You can use S3 sync http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html to keep things current. ~Mohit On Mon, Jun 22, 2015 at 9:34 PM, Lawrence Krubner lawr...@rollioforce.com wrote: This is more of Java eco-system/development question, but I am curious what folks in the Clojure community might regard as best practice. Up till now most of the projects that I've worked on we've been able to share resources informally via scp and email, or via Github, but on the current project we are dealing with a lot of massive files, over 100 megs, many over a gig. These are things such as Natural Language Processing classifiers/dictionaries, many of which are huge. We need to have them available on our machines so we can do development work. We're trying to figure a way such that when we add new paths or new files we can tell each other, or find a way that they can do something similar to git fetch origin and see what changes have happened. How do others handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -Mohit Thatte -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: transducer (+ closures) efficiency question
Oh fantastic! I was 100% wrong in literally the best way. Thanks! On Tue, Jun 23, 2015 at 7:17 PM, Ghadi Shayban gshay...@gmail.com wrote: Good question. Clojure's evaluation semantics dictate that the arguments are evaluated (computed) *before* calling the function. So(set coll) is computed before being passed to `partial`. Partial receives a function (a value) and arguments (also values) and returns back a new function that saves those original arguments (which happen to be stuffed away in Java final fields). All three of your filters return a transducer. All three of the inputs to `remove` are a partial function. Each of the arguments to the call to partial is a set. They are all essentially equivalent, and should perform the same. (Except filter3 happens to create the set twice; once in the let, and once as the arg to partial). So over a billion item collection, the set in your examples will only be computed once, once, and twice respectively. Note however that sets *are* functions that evaluate whether the argument is in the set. This means you could remove the call to partial and shorten to: (defn filter-contains1 [edn-file] (remove (set (read-edn-file edn-file Tangentially: (remove even?) Will be faster than (remove (fn [i] (even? i))) because in the first case the dereference of the var 'even?' happens only once and the value inside the var will be passed to `remove` at the outset. In the second example the var dereference happens for every single item (though it's very cheap). The second example is equivalent to writing (remove #'even?) On Tuesday, June 23, 2015 at 6:07:06 PM UTC-4, Sam Raker wrote: Let's say that, as part of an xf, I want to filter out everything in a sequence that's also in some other sequence. Here are some ways of doing that: (defn filter-contains1 [edn-file] (remove (partial contains? (set (read- edn-file edn-file) (defn filter-contains2 [coll] (remove (partial contains? (set coll (def filter-contains3 [coll] (let [coll-as-set (set coll)] (remove ( partial contains? (set coll) I have the strong suspicion that `filter-contains3` is the best of the 3, and `filter-contains1` the worst. The internal mechanics of transduce are a bit of a mystery to me, however: if `filter-contains2` were to be used on a collection of, say, a million items, would `coll` be cast to a set a million times, or is Clojure/the JVM smarter than that? I'm also wondering if anyone has any best practices (or whatever) they can share relating to this kind of intersection of transducers/xfs and closures. It seems to me, for example, that something like (defn my-thing [coll stuff] (let [s (set coll)] ... (comp ... (map foo) (filter bar) (remove (partial contains? s)) ... is awkward, but that a lot of limited-use transducer factory functions (like the ones above) aren't exactly optimal, either. -- 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/H0zoF6jlY-c/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- . -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
transducer (+ closures) efficiency question
Let's say that, as part of an xf, I want to filter out everything in a sequence that's also in some other sequence. Here are some ways of doing that: (defn filter-contains1 [edn-file] (remove (partial contains? (set (read-edn-file edn-file) (defn filter-contains2 [coll] (remove (partial contains? (set coll (def filter-contains3 [coll] (let [coll-as-set (set coll)] (remove (partial contains? (set coll) I have the strong suspicion that `filter-contains3` is the best of the 3, and `filter-contains1` the worst. The internal mechanics of transduce are a bit of a mystery to me, however: if `filter-contains2` were to be used on a collection of, say, a million items, would `coll` be cast to a set a million times, or is Clojure/the JVM smarter than that? I'm also wondering if anyone has any best practices (or whatever) they can share relating to this kind of intersection of transducers/xfs and closures. It seems to me, for example, that something like (defn my-thing [coll stuff] (let [s (set coll)] ... (comp ... (map foo) (filter bar) (remove (partial contains? s)) ... is awkward, but that a lot of limited-use transducer factory functions (like the ones above) aren't exactly optimal, either. -- 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: transducer (+ closures) efficiency question
Good question. Clojure's evaluation semantics dictate that the arguments are evaluated (computed) *before* calling the function. So(set coll) is computed before being passed to `partial`. Partial receives a function (a value) and arguments (also values) and returns back a new function that saves those original arguments (which happen to be stuffed away in Java final fields). All three of your filters return a transducer. All three of the inputs to `remove` are a partial function. Each of the arguments to the call to partial is a set. They are all essentially equivalent, and should perform the same. (Except filter3 happens to create the set twice; once in the let, and once as the arg to partial). So over a billion item collection, the set in your examples will only be computed once, once, and twice respectively. Note however that sets *are* functions that evaluate whether the argument is in the set. This means you could remove the call to partial and shorten to: (defn filter-contains1 [edn-file] (remove (set (read-edn-file edn-file Tangentially: (remove even?) Will be faster than (remove (fn [i] (even? i))) because in the first case the dereference of the var 'even?' happens only once and the value inside the var will be passed to `remove` at the outset. In the second example the var dereference happens for every single item (though it's very cheap). The second example is equivalent to writing (remove #'even?) On Tuesday, June 23, 2015 at 6:07:06 PM UTC-4, Sam Raker wrote: Let's say that, as part of an xf, I want to filter out everything in a sequence that's also in some other sequence. Here are some ways of doing that: (defn filter-contains1 [edn-file] (remove (partial contains? (set (read- edn-file edn-file) (defn filter-contains2 [coll] (remove (partial contains? (set coll (def filter-contains3 [coll] (let [coll-as-set (set coll)] (remove ( partial contains? (set coll) I have the strong suspicion that `filter-contains3` is the best of the 3, and `filter-contains1` the worst. The internal mechanics of transduce are a bit of a mystery to me, however: if `filter-contains2` were to be used on a collection of, say, a million items, would `coll` be cast to a set a million times, or is Clojure/the JVM smarter than that? I'm also wondering if anyone has any best practices (or whatever) they can share relating to this kind of intersection of transducers/xfs and closures. It seems to me, for example, that something like (defn my-thing [coll stuff] (let [s (set coll)] ... (comp ... (map foo) (filter bar) (remove (partial contains? s)) ... is awkward, but that a lot of limited-use transducer factory functions (like the ones above) aren't exactly optimal, either. -- 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: transducer (+ closures) efficiency question
On Tue, Jun 23, 2015 at 4:17 PM, Ghadi Shayban gshay...@gmail.com wrote: Tangentially: (remove even?) Will be faster than (remove (fn [i] (even? i))) because in the first case the dereference of the var 'even?' happens only once and the value inside the var will be passed to `remove` at the outset. In the second example the var dereference happens for every single item (though it's very cheap). The second example is equivalent to writing (remove #'even?) I can't seem to observe a difference between the two cases. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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.
