Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson ja...@jarohen.me.uk
javascript: wrote:
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?
I think the general idea should be to provide a clean API to the consumer
(of your lib). Perhaps something that accepts a start function, a stop
function and some sort of main loop (f in your example).
Not sure I understand what you mean here? Tbh, I was trying to get away
from the idea of separate start stop functions - it seems 'cleaner' to me
without them! (although of course that's subjective).
Also, the 'with-*' functions here are consumer code - the only Yo-yo
functions/macros in this example are 'run-system!' and 'ylet'. Yo-yo itself
is *tiny* (100 LoC) - my aim was for a library that solely dealt with
starting/stopping a provided system, and *no more* :)
Maybe it'd be worth fleshing out an example of what you were looking for?
Cheers,
James
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
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
Re: Calling an overloaded Scala function
Interesting. That could be a good last resort. On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com wrote: Sorry, I do not know whether Clojure can or cannot determine the correct overload in this situation. All I have is a weak suggestion that work well enough: have you considered creating wrapper functions, e.g. in Scala or Java, that have different enough function signatures that Clojure can easily determine the correct one? Andy On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com wrote: 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. -- 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.
Re: Calling an overloaded Scala function
Sorry, I do not know whether Clojure can or cannot determine the correct overload in this situation. All I have is a weak suggestion that work well enough: have you considered creating wrapper functions, e.g. in Scala or Java, that have different enough function signatures that Clojure can easily determine the correct one? Andy On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com wrote: 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. -- 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: materials
Alex, I just realised my mistake. My apologies to the poster. Regards, BG On Thu, Jun 25, 2015 at 6:49 PM, Alex Miller a...@puredanger.com wrote: Hey BG, Perhaps the OP did Google already but saw too many choices and was looking for an informed decision about where to go first. Using a lmgtfy link is a condescending way to answer a question and I don't want this list or this community to be that kind of place. I would prefer people to respond to requests like this with a helpful pointer instead. We were all newbies once. Thanks, Alex On Thursday, June 25, 2015 at 4:10:46 AM UTC-5, Baishampayan Ghose wrote: http://lmgtfy.com/?q=clojure+tutorial Hope this helps. ~BG -- 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. -- Baishampayan Ghose b.ghose at gmail.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: materials
Hey BG, Perhaps the OP did Google already but saw too many choices and was looking for an informed decision about where to go first. Using a lmgtfy link is a condescending way to answer a question and I don't want this list or this community to be that kind of place. I would prefer people to respond to requests like this with a helpful pointer instead. We were all newbies once. Thanks, Alex On Thursday, June 25, 2015 at 4:10:46 AM UTC-5, Baishampayan Ghose wrote: http://lmgtfy.com/?q=clojure+tutorial Hope this helps. ~BG -- 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 an overloaded Scala function
Do you know how to call this method from Java 1.4? That will probably give enough context to use in Clojure type hints. Thanks, Ambrose On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely fungus.humun...@gmail.com wrote: Interesting. That could be a good last resort. On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com wrote: Sorry, I do not know whether Clojure can or cannot determine the correct overload in this situation. All I have is a weak suggestion that work well enough: have you considered creating wrapper functions, e.g. in Scala or Java, that have different enough function signatures that Clojure can easily determine the correct one? Andy On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com wrote: 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. -- 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. -- 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: materials
Living Clojure Do ~20 project euler problems (there are few open source repos in Clojure you can compare your algorithms with). On Thursday, 25 June 2015 10:59:12 UTC+2, Baskar Kalyanasamy wrote: hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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: let vs. let*
raould, I find lmgtfy links to be a condescending way to answer a question and I would prefer that we not use them on this list. If you have an answer or a link to one, then respond with this, otherwise I do not see a reason to post this. Thanks, Alex On Thursday, June 18, 2015 at 3:35:53 PM UTC-5, raould wrote: http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22 -- 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: side-effecting re-/transducers
Hi Sam, Transducers are a new feature, and best practices are still emerging. Transducing/reducing is always non-lazy, so it's *less* risky to have side effects in a reduce compared with side effects in a lazy sequence. Still, I would offer the same advice I give for lazy sequences. Keep your side-effects as separated as possible from the purely-functional computation that feeds them. Don't put a side-effect in the middle of a chain of map/filter-like operations. Do all your map/filter/whatever with pure functions, then process the entire result non-lazily to do the side effects. The driver for that process could be `doseq`, `run!`, `transduce`, or even `reduce`. `doseq` has overhead to allocate the sequence, which the others avoid. –S On Thursday, June 25, 2015 at 2:30:21 PM UTC-4, Sam Raker wrote: This seems bad, is this bad: (defn to-db [conn] (fn ([val] (upload-to-my-db conn val)) ([_ val] (upload-to-my-db conn val))) (defn -main [] (transduce my-preprocessing-xf (to-db (get-db-conn)) seq-of-things-to- preprocess-and-upload)) I ask only because 1) Plugging the side-effecting part into the transducer pipeline seems cleaner and potentially more efficient than e.g. (doseq [v (sequence my-preprocessing-xf sea-of-things)] (upload-to-my-db conn v)) which is what I was doing 2) The addition of `run!`[1] in 1.7 seems to perhaps implicitly condone this kind of thing. There's very little out there about it, though, so I could very well be wrong. [1] http://conj.io/store/v1/org.clojure/clojure/1.7.0-alpha4/clj/clojure.core/run%21 -- 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 an overloaded Scala function
Scala has to compile down to JVM bytecode just like Clojure, but it may change method signatures along the way. You could try running `javap` to disassemble the compiled Scala bytecode and figure out what the method signatures actually are. Or use Java reflection to examine the objects you have and see what methods they declare. –S On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote: 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: Calling an overloaded Scala function
So using reflection on the objects gives the following signatures - they
have identical signatures :
{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
{:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
wrote:
Scala has to compile down to JVM bytecode just like Clojure, but it may
change method signatures along the way.
You could try running `javap` to disassemble the compiled Scala bytecode
and figure out what the method signatures actually are. Or use Java
reflection to examine the objects you have and see what methods they
declare.
–S
On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:
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.
--
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 an overloaded Scala function
javap gives :
public T com.cra.figaro.language.AtomicDistT
apply(scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
public T com.cra.figaro.language.CompoundDistT
apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
Bit of an eyesore, but the two methods only differ in the generic types..
On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
wrote:
So using reflection on the objects gives the following signatures - they
have identical signatures :
{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
{:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
wrote:
Scala has to compile down to JVM bytecode just like Clojure, but it may
change method signatures along the way.
You could try running `javap` to disassemble the compiled Scala bytecode
and figure out what the method signatures actually are. Or use Java
reflection to examine the objects you have and see what methods they
declare.
–S
On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:
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.
--
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
Yeah, looks interesting, but unfortunately still in alpha, so I can't profit from it at this stage. But will check later! Thank you all for your responses! It's been really great source of new ideas and thoughts about API benchmarking and blocking/non-blocking approaches :) On Thursday, 25 June 2015 16:45:45 UTC+2, Dylan Butman wrote: Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling an overloaded Scala function
I am sadly quite clueless when it comes to Java.
De-compiling the Scala class file to Java gives me the following:
public T AtomicDistT apply(SeqTuple2Object, ElementT clauses,
NameT name, ElementCollection collection) {
return new AtomicDist(name, clauses.toList(), collection);
}
public T CompoundDistT apply(SeqTuple2ElementObject,
ElementT clauses, NameT name, ElementCollection collection) {
return new CompoundDist(name, clauses.toList(), collection);
}
Generics all over the place. Would this even be callable from Java 1.4?
On Thu, Jun 25, 2015 at 2:13 PM Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Do you know how to call this method from Java 1.4? That will probably give
enough context to use in Clojure type hints.
Thanks,
Ambrose
On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely fungus.humun...@gmail.com
wrote:
Interesting. That could be a good last resort.
On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
wrote:
Sorry, I do not know whether Clojure can or cannot determine the correct
overload in this situation.
All I have is a weak suggestion that work well enough: have you
considered creating wrapper functions, e.g. in Scala or Java, that have
different enough function signatures that Clojure can easily determine the
correct one?
Andy
On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely
fungus.humun...@gmail.com wrote:
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.
--
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.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
Re: Writing REST api the right way
Have you looked at yada http://yada.juxt.pro/user-guide.html ? It's an aleph compatible alternative to liberator that is swagger compatible with swagger out of the box. On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: Hey guys, I am so excited to join Clojure bandwagon, last weeks have been super exciting, pretty much in love with Clojure syntax. As we are currently building an application broken into smaller micro services, I thought I am gonna make one or two Clojure based modules. Although the initial purpose of picking the language was to do some CPU demand calculations and data processing, I found it really simple yet enjoyable to write REST api as well (we also use Node.js and Elixir for that purpose and it works pretty well - especially with Elixir thanks to awesome yet simple Erlang model where you can `spawnblock` and be happy). I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and other HTTP servers and I am currently with `Aleph` thanks to its ability to handle channels and futures out of the box. Unfortunately, because I spent so many years with Node.js and stopped using Java ages ago, I just can't stop thinking about non-blocking evented IO interactions. It just does not feel right to me to block the thread when e.g. logging in an user. Unfortunately, there are no NIO drivers for the database engines I am interested in (Neo4J, Mongo) so async channels are not the way to go. Any advices or interesting thoughts? Maybe I am missing something as I am not entirely sure if evented IO is always speeding up the overall performance. Any performance optimisations are welcome. I am especially unhappy with one Neo4J request that takes 1.5 second to finish (it's only because the database is hosted on free Heroku plan and this is not going to happen in production but I find it quite a good place to tweak the optimisations and concurrency). Another question is - is there any documentation generator that can parse your comments, take keywords like `:params` or `:returns` (just the idea) and generate beautiful API docs out of the box? Swagger is not a way to go as it requires me to use `Schema` plugin - I am currently with `bouncer` thanks to more real-life validators as well as user friendly messages that I can just print to users out of the box (maybe it's worth building as an open source module then) Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Is this expected behavior with meta data?
Why doesn't this work?
user= (meta ^{:some-meta 123} 'n)
nil
While this works:
user= (meta ^{:some-meta 123} (fn [n] n))
{:some-meta 123}
And this works too:
user= (meta (with-meta 'n {:some-meta 123}))
{:some-meta 123}
Is this intended behavior? If so, what's the reasoning?
Thanks,
Sarkis
--
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: let vs. let*
I had to query it myself not knowing what this site was all about, nice tutorial, I think I understood it :) Luc P. raould, I find lmgtfy links to be a condescending way to answer a question and I would prefer that we not use them on this list. If you have an answer or a link to one, then respond with this, otherwise I do not see a reason to post this. Thanks, Alex On Thursday, June 18, 2015 at 3:35:53 PM UTC-5, raould wrote: http://lmgtfy.com/?q=clojure+%22let+vs.+let*%22 -- 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. -- Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is this expected behavior with meta data?
There was just this question the other day:
http://stackoverflow.com/questions/30922413/why-does-metadata-symbol-not-work
There is also a few threads a few weeks ago here on google groups about it:
https://groups.google.com/d/msg/clojure/_e7vBom2acw/0AAKTiGuzv4J
HTH
On Thursday, June 25, 2015 at 10:00:59 AM UTC-4, Sarkis Karayan wrote:
Why doesn't this work?
user= (meta ^{:some-meta 123} 'n)
nil
While this works:
user= (meta ^{:some-meta 123} (fn [n] n))
{:some-meta 123}
And this works too:
user= (meta (with-meta 'n {:some-meta 123}))
{:some-meta 123}
Is this intended behavior? If so, what's the reasoning?
Thanks,
Sarkis
--
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.
Looking for library to annotate structures with grammar descriptions
Suppose we have a structure like this: [ :a [:a :b :c][:a [:b1 :b2] :c ] ] That is a *required* list. It consists of keywords and *paths* (nested vector like [:a :b :c] above). A path consists of keywords and *alternates* (a twice-nested vector like [:b1 :b2]) above. It's easy to descend this by hand and keep track of which type of vector you're dealing with. However, this sort of thing comes up enough that it would be convenient if there were a function that takes a grammar and a structure and returns that structure annotated (metadata?) with type information. Coupled with Specter https://github.com/nathanmarz/specter, that would make a good number of data transformations easy-peasy. Is there such a library? Or a library I can build on? A quick scan shows a lot of parsers for dealing with strings, but we've already got one of those: it's called `read`. @marick -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is this expected behavior with meta data?
to get the meta-data of a var (I'm guessing symbol n refers to a var...)
you should call it on the var iself, not its value or symbol:
user= (def ^{:some-meta 123} n 0)
#'user/n
user= (meta n)
nil
user= (meta 'n)
nil
user= (meta #'n)
{:some-meta 123, :ns #Namespace user, :name n, :file NO_SOURCE_PATH,
:column 1, :line 1}
hth,
-Gianluca
On Thursday, June 25, 2015 at 4:00:59 PM UTC+2, Sarkis Karayan wrote:
Why doesn't this work?
user= (meta ^{:some-meta 123} 'n)
nil
While this works:
user= (meta ^{:some-meta 123} (fn [n] n))
{:some-meta 123}
And this works too:
user= (meta (with-meta 'n {:some-meta 123}))
{:some-meta 123}
Is this intended behavior? If so, what's the reasoning?
Thanks,
Sarkis
--
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: materials
The sidebar on reddit is actually pretty decent: http://www.reddit.com/r/clojure My #1 resource for looking up docs is nowadays clojuredocs.org since it gives examples/comments for most of the functions. HTH On Thursday, June 25, 2015 at 4:59:12 AM UTC-4, Baskar Kalyanasamy wrote: hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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.
side-effecting re-/transducers
This seems bad, is this bad: (defn to-db [conn] (fn ([val] (upload-to-my-db conn val)) ([_ val] (upload-to-my-db conn val))) (defn -main [] (transduce my-preprocessing-xf (to-db (get-db-conn)) seq-of-things-to- preprocess-and-upload)) I ask only because 1) Plugging the side-effecting part into the transducer pipeline seems cleaner and potentially more efficient than e.g. (doseq [v (sequence my-preprocessing-xf sea-of-things)] (upload-to-my-db conn v)) which is what I was doing 2) The addition of `run!`[1] in 1.7 seems to perhaps implicitly condone this kind of thing. There's very little out there about it, though, so I could very well be wrong. [1] http://conj.io/store/v1/org.clojure/clojure/1.7.0-alpha4/clj/clojure.core/run%21 -- 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: clj-pronouncing
I ported Allison Parrish's Pronouncing python library, an interface to the CMU Pronouncing Dictionary, to clojure: https://github.com/wiseman/clj-pronouncing You can use it to count syllables, find rhymes, etc.: user (require '[com.lemonodor.pronouncing :as pro]) user (- literally pro/phones-for-word (map pro/syllable-count)) (4 3) ;; Some people say it with 4 syllables, some with 3. user (require '[com.lemonodor.pronouncing :as pro]) user (pro/rhymes failings) (mailings railings tailings) I use it in songku, which finds haiku in song titles: https://songku.herokuapp.com/ John -- 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 an overloaded Scala function
They apparently differ in the return type. I don't think
clojure.lang.Reflector considers the return type hint
when resolving methods.
Thanks,
Ambrose
On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com
wrote:
javap gives :
public T com.cra.figaro.language.AtomicDistT
apply(scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
public T com.cra.figaro.language.CompoundDistT
apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
Bit of an eyesore, but the two methods only differ in the generic types..
On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
wrote:
So using reflection on the objects gives the following signatures - they
have identical signatures :
{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
{:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra
the.stuart.sie...@gmail.com wrote:
Scala has to compile down to JVM bytecode just like Clojure, but it may
change method signatures along the way.
You could try running `javap` to disassemble the compiled Scala bytecode
and figure out what the method signatures actually are. Or use Java
reflection to examine the objects you have and see what methods they
declare.
–S
On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:
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.
--
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
Re: Calling an overloaded Scala function
That was meant as a response to the other thread.
On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
They apparently differ in the return type. I don't think
clojure.lang.Reflector considers the return type hint
when resolving methods.
Thanks,
Ambrose
On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com
wrote:
javap gives :
public T com.cra.figaro.language.AtomicDistT
apply(scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
public T com.cra.figaro.language.CompoundDistT
apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);
Bit of an eyesore, but the two methods only differ in the generic types..
On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
wrote:
So using reflection on the objects gives the following signatures - they
have identical signatures :
{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
{:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
com.cra.figaro.language.Name
com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra
the.stuart.sie...@gmail.com wrote:
Scala has to compile down to JVM bytecode just like Clojure, but it may
change method signatures along the way.
You could try running `javap` to disassemble the compiled Scala
bytecode and figure out what the method signatures actually are. Or use
Java reflection to examine the objects you have and see what methods they
declare.
–S
On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:
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.
--
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 -
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Seems like the next step for this would be for me to put together a blog
with an example Component system, and its equivalent Yoyo system?! :)
Should have time for that over the weekend.
James
On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson ja...@jarohen.me.uk
wrote:
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?
I think the general idea should be to provide a clean API to the consumer
(of your lib). Perhaps something that accepts a start function, a stop
function and some sort of main loop (f in your example).
Not sure I understand what you mean here? Tbh, I was trying to get away
from the idea of separate start stop functions - it seems 'cleaner' to me
without them! (although of course that's subjective).
Also, the 'with-*' functions here are consumer code - the only Yo-yo
functions/macros in this example are 'run-system!' and 'ylet'. Yo-yo itself
is *tiny* (100 LoC) - my aim was for a library that solely dealt with
starting/stopping a provided system, and *no more* :)
Maybe it'd be worth fleshing out an example of what you were looking for?
Cheers,
James
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
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
Re: materials
http://www.braveclojure.com/ On Thu, Jun 25, 2015 at 12:10 PM, Baishampayan Ghose b.gh...@gmail.com wrote: http://lmgtfy.com/?q=clojure+tutorial Hope this helps. ~BG On Thu, Jun 25, 2015 at 7:21 AM, Baskar Kalyanasamy baskar...@gmail.com wrote: hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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. -- Baishampayan Ghose b.ghose at gmail.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. -- 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 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.
materials
hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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: materials
http://lmgtfy.com/?q=clojure+tutorial Hope this helps. ~BG On Thu, Jun 25, 2015 at 7:21 AM, Baskar Kalyanasamy baskar...@gmail.com wrote: hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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. -- Baishampayan Ghose b.ghose at gmail.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: materials
Have you tried the most obvious place ? http://clojure.org/getting_started Kind regards On Thursday, June 25, 2015 at 10:59:12 AM UTC+2, Baskar Kalyanasamy wrote: hi everyone, can somebody send me materials for clojure. i am a beginner and i also want to in which tool or software i should practice in. thanks in advance -- 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.
