Re: Feedback on idiomatic API design
I would suggest a slightly different approach. First, define a record for
your fake server, which implements Closeable; put your current "shutdown"
code in the close method.
This will allow you to use the existing with-open macro, instead of having
to redefine your own, while leaving the option of not using the macro
should the user want that.
Then, define a constructor function for that record, which takes as
argument a map or vector defining your routes, and returns an instance of
the above record. That record should have a :uri property, and encapsulate
the actual server.
Then you can do stuff like:
(with-open [srv (fake-server routes)]
(http/get (:uri srv) ...)
...)
while leaving the option of creating and closing the server manually if it
makes sense for some use-case. You can also easily reuse routes from one
server to another as it is a simple data structure.
On Wednesday, 9 March 2016, Marc Limotte wrote:
> With the macro approach, they don't need to escape it.
>
> On Wed, Mar 9, 2016 at 12:52 PM, Johan Haleby > wrote:
>
>> Thanks a lot for your support Marc, really appreciated.
>>
>> On Wed, Mar 9, 2016 at 5:33 PM, Marc Limotte > > wrote:
>>
>>> Yes, I was assuming the HTTP calls happen inside the with-fake-routes!
>>> block.
>>>
>>> I missed the part about the random port. I se 3 options for that:
>>>
>>> *Assign a port, rather than random*
>>>
>>> (with-fake-routes! ...)
>>>
>>>
>>> But then, of course, you have to worry about port already in use.
>>>
>>> *An atom*
>>>
>>> (def the-uri (atom nil))
>>> (with-fake-routes! the-uri
>>> ...
>>> (http/get @the-uri "/x"))
>>>
>>> *A macro*
>>>
>>> A common convention in Clojure would be to pass it a symbol (e.g. `uri`
>>> that is bound by the macro), rather implicitly creating `uri`.
>>>
>>> (with-fake-routes! [uri option-server-instance]
>>>
>>> route-map
>>>
>>> (http/get uri "/x"))
>>>
>>>
>> Didn't know about this convention so thanks for the tip. But is your
>> snippet above actually working code or does the user need escape "uri" and "
>> option-server-instance" using a single-quotes, i.e.
>>
>> (with-fake-routes! [*'*uri *'*option-server-instance] ...)
>>
>>
>>>
>>> or, with a pre-defined server
>>>
>>> (def fake-server ...)
>>> (with-fake-routes!
>>>
>>> route-map
>>>
>>> (http/get (:uri fake-server) "/x"))
>>>
>>>
>>> marc
>>>
>>>
>>>
>>> On Wed, Mar 9, 2016 at 1:00 AM, Johan Haleby >> > wrote:
>>>
On Wed, Mar 9, 2016 at 6:20 AM, Johan Haleby >>> > wrote:
> Thanks for your feedback, exactly what I wanted.
>
> On Tuesday, March 8, 2016 at 3:16:02 PM UTC+1, mlimotte wrote:
>>
>> I don't think you need a macro here. In any case, I'd avoid using a
>> macro as late as possible. See how far you get with just functions, and
>> then maybe at the end, add one macro if you absolutely need it to add
>> just
>> a touch of syntactic sugar.
>>
>> routes should clearly be some sort of data-structure, rather than
>> side-effect setter functions. Maybe this:
>>
>> (with-fake-routes!
>> optional-server-instance
>> route-map)
>>
>>
Hmm now that I come to think of it I don't see how this would actually
work unless you also perform the HTTP request from inside the scope of
with-fake-routes!,
otherwise the server instance would be closed before you get the chance
to make the request. Since you make an actual HTTP request you need
access to the URI generated when starting the fake-server instance (at
least if the port is chosen randomly). So either I suppose you would
have to do like this (which requires a macro?):
(with-fake-routes!
{"/x" {:status 200 :content-type "application/json" :body (slurp
(io/resource "my.json"))}}
; Actual HTTP request
(http/get uri "/x"))
where "uri" is created by the with-fake-routes! macro *or* we could
return the generated fake-server. But if so with-fake-routes! cannot
automatically close the fake-server instance since we need the
instance to be alive when we make the call to the generated uri. I suppose
it would have to look something like this:
(let [fake-server (with-fake-routes! {"/x" {:status 200 :content-type
"application/json" :body (slurp (io/resource "my.json"))}})]
(http/get (:uri fake-server) "/x")
(shutdown! fake-server))
If so I think that the second option is unnecessary since then you
might just go with:
(with-fake-routes!
*required*-server-instance
route-map)
instead of having two options. But then we loose the niceness of having
the server instance be automatically created and stopped for us?
>> Where optional-server-instance, if it exists is, an object returned
>> by (fake-server/start!). If optional-server-instance is not passed
>> in, then with-fake-routes! creates it's
Re: Understanding init (the zero arity function) for transducers.
Looking at both the implementation for TransformerIterator (sequence), transduce and eduction, it's clear that the 0-arg arity is never invoked on a transducer, while it's ever only used to provide the reducing step function of transduce its init value, if not provided explicitely. I have to agree that I don't see a point in that 0-arity for transducers. On Thu, Mar 10, 2016 at 2:42 AM, Philos Kim wrote: > I wrote the next example to trace the inner workings of transducer. I hope > that this will help. > > The next filter-t(transducer), map-t(transducer) and conj-t(reducer) > functions are excerpted from the filter, map and conj from clojure.core and > then simplified and modified to focus on the understanding of the inner > workings. > > (defn filter-t > [pred] > ;; The first fn is a transducer. It receives the reducer rf and returns > ;; the reducer(the second fn part of this code). > (fn [rf] > (fn > ([] >(let [r (rf)] > (println "filter-t [] post: result =" r) > r)) > ([result] >(println "filter-t [result] pre: result =" result) >(let [r (rf result)] > (println "filter-t [result] post: result =" r) > r)) > ([result input] >(println "filter-t [result input] pre: result =" result ", input =" > input) >(let [r (if (pred input) > (rf result input) > result)] > (println "filter-t [result input] post: result =" r) > r) > > (defn map-t > [f] > (fn [rf] > (fn > ([] >(let [r (rf)] > (println "map-t [] post: result =" r) > r)) > ([result] >(println "map-t [result] pre: result =" result) >(let [r (rf result)] > (println "map-t [result] post: result =" r) > r)) > ([result input] >(println "map-t [result input] pre: result =" result ", input =" > input) >(let [r (rf result (f input))] > (println "map-t [result input] post: result =" r) > r) > > (defn ^:static conj-t > [] > ;; This is a reducer itself, not a transducer, because it doesn't receive > the reducer > ;; and return a reducer as a transducer. > (fn > ([] > (println "conj-t []: result =" []) > []) > ([result] > (println "conj-t [result]: result =" result) > result) > ([result input] > (println "conj-t [result input] pre: result =" result ", input =" > input) > (let [r (. clojure.lang.RT (conj result input))] >(println "conj-t [result input] post: retrun =" r) >r) ))) > > > The oupput is edited to facilitate the understandings. > > (def xform (comp (filter-t odd?) (map-t #(* % 10 > > (transduce xform (conj-t) [1 2 3 4 5]) > ;>> conj-t []: result = [] > ; > ; filter-t [result input] pre: result = [] , input = 1 > ; map-t [result input] pre: result = [] , input = 1 > ; conj-t [result input] pre: result = [] , input = 10 > ; conj-t [result input] post: retrun = [10] > ; map-t [result input] post: result = [10] > ; filter-t [result input] post: result = [10] > ; > ; filter-t [result input] pre: result = [10] , input = 2 > ; filter-t [result input] post: result = [10] > ; > ; filter-t [result input] pre: result = [10] , input = 3 > ; map-t [result input] pre: result = [10] , input = 3 > ; conj-t [result input] pre: result = [10] , input = 30 > ; conj-t [result input] post: retrun = [10 30] > ; map-t [result input] post: result = [10 30] > ; filter-t [result input] post: result = [10 30] > ; > ; filter-t [result input] pre: result = [10 30] , input = 4 > ; filter-t [result input] post: result = [10 30] > ; > ; filter-t [result input] pre: result = [10 30] , input = 5 > ; map-t [result input] pre: result = [10 30] , input = 5 > ; conj-t [result input] pre: result = [10 30] , input = 50 > ; conj-t [result input] post: retrun = [10 30 50] > ; map-t [result input] post: result = [10 30 50] > ; filter-t [result input] post: result = [10 30 50] > ; > ; filter-t [result] pre: result = [10 30 50] > ; map-t [result] pre: result = [10 30 50] > ; conj-t [result]: result = [10 30 50] > ; map-t [result] post: result = [10 30 50] > ; filter-t [result] post: result = [10 30 50] > ;=> [10 30 50] > > From the above output, my conclusion is that the init part(with no argument) > of reducer is called only in the last reducer(conj-t in this case) and never > called in the reducers within the transducers(filter-t and map-t). > > If you give the init value to the transduce function as follows, > > (transduce xform (conj-t) [] [1 2 3 4 5]) > ;>> filter-t [result input] pre: result = [] , input = 1 > ; map-t [result input] pre: result = [] , input = 1 > ; conj-t [result input] pre: result = [] , input = 10 > ; conj-t [result input] post: retrun = [10] > ; map-t [result input] post: result = [10] > ; filter-t [result
Re: Similar lisps and emacs reimplementations?
Common Lisp is timeless in my opinion. :) STMX is a high performance STM implementation for Common Lisp. https://github.com/cosmos72/stmx On SBCL it even compiled down as an optimization to Intel TSX assembly instructions (which incidentally were disabled by the manufacturer unfortunately a couple of years ago due to a major bug; I am not sure if they fixed the bug in newer chips yet). In any event, it's still a great implementation. On Wednesday, March 9, 2016 at 1:43:38 PM UTC-5, Sam Halliday wrote: > > Hi all, > > I have been learning clojure as holiday reading (I'm a scala dev and am > one of the main authors of ENSIME.org, which brings IDE like support to > text editors for Java and Scala). > > Clojure is amazing! I'm really loving learning it. There is so much good > stuff in here, plus it's a lisp which is just incredible for me because > I've been an Emacs hacker for nearly two decades. > > I've done enough research to know that the clojure licence is off topic > and discussions about it make people feel "nauseous", so I'll skip over > begging you to change it to MPL or Apache 2.0 and tell you that I cannot > use EPL at work. It is blacklisted by many of my customers and the patent > retaliation clause gives my legal advisors enough to construct terrifying > scenarios that all ended up in the end of my career. Also, I can't add > clojure support or use clojure in ENSIME because of the well known GPL / > EPL incompatibility. > > So... skipping over that. It seems I can't actually use this beautiful > language. But I do a fair bit of emacs-lisp so naturally I'd like to know > to what extent the features have been reimplemented? > > I've seen that Emacs 25 is going to have something that looks a bit like > destructuring, I've used dash (but there is an idiomatic replacement coming > too) and I've seen some "ports" of the threading (I love this macro so > much). However direct ports are still subject to the original licence, so > it needs to be a clean room implementation (or Rich/the author to release > those macros user GPL as an emacs package). > > Is there anything else that is making its way back into Emacs lisp as a > result of what has been learnt in Clojure? > > And are there any other lisps which use STM? Emacs is still single > threaded so STM is almost useless there. I'd be really interested in a > modern lisp with STM and a licence that I could use at work. > > Best regards, > Sam -- 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: Similar lisps and emacs reimplementations?
If you're more keen on GPL-compatible, Clojure-like language with STM/CSP (upcoming) than being currently able to use it in production take a look at Pixie: https://github.com/pixie-lang/pixie It's syntax is heavily inspired by Clojure, STM is coming, and it's fast - no JVM. The state is "pre-alpha" though. Cheers, Aleksander On 10 March 2016 at 14:03, wrote: > Common Lisp is timeless in my opinion. :) > > STMX is a high performance STM implementation for Common Lisp. > > https://github.com/cosmos72/stmx > > On SBCL it even compiled down as an optimization to Intel TSX assembly > instructions (which incidentally were disabled by the manufacturer > unfortunately a couple of years ago due to a major bug; I am not sure if > they fixed the bug in newer chips yet). In any event, it's still a great > implementation. > > > On Wednesday, March 9, 2016 at 1:43:38 PM UTC-5, Sam Halliday wrote: >> >> Hi all, >> >> I have been learning clojure as holiday reading (I'm a scala dev and am >> one of the main authors of ENSIME.org, which brings IDE like support to >> text editors for Java and Scala). >> >> Clojure is amazing! I'm really loving learning it. There is so much good >> stuff in here, plus it's a lisp which is just incredible for me because >> I've been an Emacs hacker for nearly two decades. >> >> I've done enough research to know that the clojure licence is off topic >> and discussions about it make people feel "nauseous", so I'll skip over >> begging you to change it to MPL or Apache 2.0 and tell you that I cannot >> use EPL at work. It is blacklisted by many of my customers and the patent >> retaliation clause gives my legal advisors enough to construct terrifying >> scenarios that all ended up in the end of my career. Also, I can't add >> clojure support or use clojure in ENSIME because of the well known GPL / >> EPL incompatibility. >> >> So... skipping over that. It seems I can't actually use this beautiful >> language. But I do a fair bit of emacs-lisp so naturally I'd like to know >> to what extent the features have been reimplemented? >> >> I've seen that Emacs 25 is going to have something that looks a bit like >> destructuring, I've used dash (but there is an idiomatic replacement coming >> too) and I've seen some "ports" of the threading (I love this macro so >> much). However direct ports are still subject to the original licence, so >> it needs to be a clean room implementation (or Rich/the author to release >> those macros user GPL as an emacs package). >> >> Is there anything else that is making its way back into Emacs lisp as a >> result of what has been learnt in Clojure? >> >> And are there any other lisps which use STM? Emacs is still single >> threaded so STM is almost useless there. I'd be really interested in a >> modern lisp with STM and a licence that I could use at work. >> >> Best regards, >> Sam > > -- > 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. > -- *uSwitch is a trading name of uSwitch Ltd. Registered in **England and Wales **(Company No. 03612689). Registered Address: **Notcutt House, 36 Southwark Bridge Road, London, SE1 9EU* *This communication and any attachments contains information which is confidential and may be subject to legal privilege. It is for intended recipients only. If you are not the intended recipient you must not copy, distribute, publish, rely on or otherwise use it without our consent. Some of our communications may contain confidential information which it could be a criminal offence for you to disclose or use without authority. If you have received this email in error please notify the sender immediately and delete the email from your computer.* *uSwitch Ltd reserves the right to monitor all email communications for compliance with legal, regulatory and professional standards.* -- 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
[ANN] "Real" air traffic control system - complex Clojure-ClojureScript example
Hi, "Real" air traffic control system - client-server ClojureScript-Clojure application based on: 1. *rete4frames* expert system shell (http://github.com/rururu/rete4frames/), 2. *Flightradar24* web service (http://www.flightradar24.com/), 2. *Leaflet* JavaScript GIS libraty (http://leafletjs.com/), 3.. *httpkit, compojure, core.async* and others Clojure libraries. This example is in the repository https://github.com/rururu/rete4flights. New functionality: You can plan your own flights and add them to the real air traffic. Enjoy! Sincerely, Ru -- 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: Understanding init (the zero arity function) for transducers.
Just to be clear, I do think transducers should have a 0-arity part, but the things that use transducers should call it. (As opposed to saying the calling code is correct so transducers don't need a 0-arity part.) In Dan's post (linked at the top of the thread), he provides an alternative implementation of transduce that does call the 0-arity part. I have a toy project using channels, so I made a few changes to core.async so that it would be called, and give me the behavior that I expect. I'm not 100% sure if or how eduction should call it, but in any case I think transducers should keep the same definition, and the calling code needs to be updated in a few places. On Thursday, March 10, 2016 at 5:41:21 AM UTC-5, Nicola Mometto wrote: > > Looking at both the implementation for TransformerIterator (sequence), > transduce and eduction, it's clear that the 0-arg arity is never > invoked on a transducer, while it's ever only used to provide the > reducing step function of transduce its init value, if not provided > explicitely. > > I have to agree that I don't see a point in that 0-arity for transducers. > > On Thu, Mar 10, 2016 at 2:42 AM, Philos Kim > wrote: > > I wrote the next example to trace the inner workings of transducer. I > hope > > that this will help. > > > > The next filter-t(transducer), map-t(transducer) and conj-t(reducer) > > functions are excerpted from the filter, map and conj from clojure.core > and > > then simplified and modified to focus on the understanding of the inner > > workings. > > > > (defn filter-t > > [pred] > > ;; The first fn is a transducer. It receives the reducer rf and > returns > > ;; the reducer(the second fn part of this code). > > (fn [rf] > > (fn > > ([] > >(let [r (rf)] > > (println "filter-t [] post: result =" r) > > r)) > > ([result] > >(println "filter-t [result] pre: result =" result) > >(let [r (rf result)] > > (println "filter-t [result] post: result =" r) > > r)) > > ([result input] > >(println "filter-t [result input] pre: result =" result ", input > =" > > input) > >(let [r (if (pred input) > > (rf result input) > > result)] > > (println "filter-t [result input] post: result =" r) > > r) > > > > (defn map-t > > [f] > > (fn [rf] > > (fn > > ([] > >(let [r (rf)] > > (println "map-t [] post: result =" r) > > r)) > > ([result] > >(println "map-t [result] pre: result =" result) > >(let [r (rf result)] > > (println "map-t [result] post: result =" r) > > r)) > > ([result input] > >(println "map-t [result input] pre: result =" result ", input =" > > input) > >(let [r (rf result (f input))] > > (println "map-t [result input] post: result =" r) > > r) > > > > (defn ^:static conj-t > > [] > > ;; This is a reducer itself, not a transducer, because it doesn't > receive > > the reducer > > ;; and return a reducer as a transducer. > > (fn > > ([] > > (println "conj-t []: result =" []) > > []) > > ([result] > > (println "conj-t [result]: result =" result) > > result) > > ([result input] > > (println "conj-t [result input] pre: result =" result ", input =" > > input) > > (let [r (. clojure.lang.RT (conj result input))] > >(println "conj-t [result input] post: retrun =" r) > >r) ))) > > > > > > The oupput is edited to facilitate the understandings. > > > > (def xform (comp (filter-t odd?) (map-t #(* % 10 > > > > (transduce xform (conj-t) [1 2 3 4 5]) > > ;>> conj-t []: result = [] > > ; > > ; filter-t [result input] pre: result = [] , input = 1 > > ; map-t [result input] pre: result = [] , input = 1 > > ; conj-t [result input] pre: result = [] , input = 10 > > ; conj-t [result input] post: retrun = [10] > > ; map-t [result input] post: result = [10] > > ; filter-t [result input] post: result = [10] > > ; > > ; filter-t [result input] pre: result = [10] , input = 2 > > ; filter-t [result input] post: result = [10] > > ; > > ; filter-t [result input] pre: result = [10] , input = 3 > > ; map-t [result input] pre: result = [10] , input = 3 > > ; conj-t [result input] pre: result = [10] , input = 30 > > ; conj-t [result input] post: retrun = [10 30] > > ; map-t [result input] post: result = [10 30] > > ; filter-t [result input] post: result = [10 30] > > ; > > ; filter-t [result input] pre: result = [10 30] , input = 4 > > ; filter-t [result input] post: result = [10 30] > > ; > > ; filter-t [result input] pre: result = [10 30] , input = 5 > > ; map-t [result input] pre: result = [10 30] , input = 5 > > ; conj-t [result input] pre: resul
Re: Feedback on idiomatic API design
Very interesting approach indeed. I'm going to finish up the previous
approach first then I'll look more closely into this. I like it, and its
simple!
Thanks!
On Thu, Mar 10, 2016 at 10:51 AM, Gary Verhaegen
wrote:
> I would suggest a slightly different approach. First, define a record for
> your fake server, which implements Closeable; put your current "shutdown"
> code in the close method.
>
> This will allow you to use the existing with-open macro, instead of having
> to redefine your own, while leaving the option of not using the macro
> should the user want that.
>
> Then, define a constructor function for that record, which takes as
> argument a map or vector defining your routes, and returns an instance of
> the above record. That record should have a :uri property, and encapsulate
> the actual server.
>
> Then you can do stuff like:
>
> (with-open [srv (fake-server routes)]
> (http/get (:uri srv) ...)
> ...)
>
> while leaving the option of creating and closing the server manually if it
> makes sense for some use-case. You can also easily reuse routes from one
> server to another as it is a simple data structure.
>
>
> On Wednesday, 9 March 2016, Marc Limotte wrote:
>
>> With the macro approach, they don't need to escape it.
>>
>> On Wed, Mar 9, 2016 at 12:52 PM, Johan Haleby
>> wrote:
>>
>>> Thanks a lot for your support Marc, really appreciated.
>>>
>>> On Wed, Mar 9, 2016 at 5:33 PM, Marc Limotte
>>> wrote:
>>>
Yes, I was assuming the HTTP calls happen inside the with-fake-routes!
block.
I missed the part about the random port. I se 3 options for that:
*Assign a port, rather than random*
(with-fake-routes! ...)
But then, of course, you have to worry about port already in use.
*An atom*
(def the-uri (atom nil))
(with-fake-routes! the-uri
...
(http/get @the-uri "/x"))
*A macro*
A common convention in Clojure would be to pass it a symbol (e.g. `uri`
that is bound by the macro), rather implicitly creating `uri`.
(with-fake-routes! [uri option-server-instance]
route-map
(http/get uri "/x"))
>>> Didn't know about this convention so thanks for the tip. But is your
>>> snippet above actually working code or does the user need escape "uri" and "
>>> option-server-instance" using a single-quotes, i.e.
>>>
>>> (with-fake-routes! [*'*uri *'*option-server-instance] ...)
>>>
>>>
or, with a pre-defined server
(def fake-server ...)
(with-fake-routes!
route-map
(http/get (:uri fake-server) "/x"))
marc
On Wed, Mar 9, 2016 at 1:00 AM, Johan Haleby
wrote:
>
>
> On Wed, Mar 9, 2016 at 6:20 AM, Johan Haleby
> wrote:
>
>> Thanks for your feedback, exactly what I wanted.
>>
>> On Tuesday, March 8, 2016 at 3:16:02 PM UTC+1, mlimotte wrote:
>>>
>>> I don't think you need a macro here. In any case, I'd avoid using a
>>> macro as late as possible. See how far you get with just functions, and
>>> then maybe at the end, add one macro if you absolutely need it to add
>>> just
>>> a touch of syntactic sugar.
>>>
>>> routes should clearly be some sort of data-structure, rather than
>>> side-effect setter functions. Maybe this:
>>>
>>> (with-fake-routes!
>>> optional-server-instance
>>> route-map)
>>>
>>>
> Hmm now that I come to think of it I don't see how this would actually
> work unless you also perform the HTTP request from inside the scope of
> with-fake-routes!,
> otherwise the server instance would be closed before you get the
> chance to make the request. Since you make an actual HTTP request you
> need access to the URI generated when starting the fake-server instance
> (at least if the port is chosen randomly). So either I suppose you
> would have to do like this (which requires a macro?):
>
> (with-fake-routes!
> {"/x" {:status 200 :content-type "application/json" :body (slurp
> (io/resource "my.json"))}}
> ; Actual HTTP request
> (http/get uri "/x"))
>
> where "uri" is created by the with-fake-routes! macro *or* we could
> return the generated fake-server. But if so with-fake-routes! cannot
> automatically close the fake-server instance since we need the
> instance to be alive when we make the call to the generated uri. I suppose
> it would have to look something like this:
>
> (let [fake-server (with-fake-routes! {"/x" {:status 200 :content-type
> "application/json" :body (slurp (io/resource "my.json"))}})]
> (http/get (:uri fake-server) "/x")
> (shutdown! fake-server))
>
> If so I think that the second option is unnecessary since then you
> might just go with:
>
> (with-fake-routes!
> *required*-server-in
is there an implementation of GraphQL in Clojure?
I am looking here: https://github.com/chentsulin/awesome-graphql and Clojure is not listed. Is there anything in Clojure that I can use to offer GraphQL queries to a React frontend? -- 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 there an implementation of GraphQL in Clojure?
There is a Java solution in that list at: https://github.com/andimarek/graphql-java You could use that directly through interop. If you're feeling generous, you could even build a Clojure wrapper around it and release that as open-source. On Thursday, 10 March 2016, wrote: > > I am looking here: > > https://github.com/chentsulin/awesome-graphql > > and Clojure is not listed. > > Is there anything in Clojure that I can use to offer GraphQL queries to a > React frontend? > > -- > 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.
[ANN] aatree/aautil release 0.0.8 (a cljc library containing snippets of useful code): building on octet
Added buffer. Buffer builds on the funcool/octet project, adding a number of capabilities from java.nio.bytebuffer while supporting the extensible specs from octet. See https://github.com/aatree/aautil#buffer -- 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] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
*New version, 0.4.0 released:* http://fluokitten.uncomplicate.org/ has lots of documentation and tutorials. Source at: https://github.com/uncomplicate/fluokitten New features: - Added PseudoFunctor, PseudoApplicative, and PseudoMonad, to support destructive operations in Neanderthal. - Better support for functions and curried functions. - fold, foldmap, and op much improved with variadic versions. - Varargs versions of pure, return, and unit. Changes: - fmap implementation for function changed to be in line with bind; supports multi-arity functions and offer super-comp. - Collections use reducers where appropriate. - op, fold, foldmap, support multiple arguments, have better implementations. On Monday, July 22, 2013 at 4:33:48 PM UTC+2, Phillip Lord wrote: > > > > That's a good answer! I've enjoyed reading the documentation of both > fluokitten and morph and understood it. The functionality certainly > seems useful. > > Phil > > Dragan Djuric > writes: > > > If Clojure has all of the Haskell's type features, I guess there would > be > > only one Clojure monad library, more or less a direct port of Haskell's. > As > > Clojure is different, there are different ways to approach monads from > > neither of which can be the same as Haskell's, each having its pros and > > cons, so there are many libraries. Additional motivation in my case is > that > > the other libraries (except morph, which is also a newcomer) were poorly > > documented or not documented at all, and that even simple examples from > > Haskell literature were not simple at all in those libraries, and in > many > > cases, not even supported (many of them don't even define functors and > > monoids, let alone applicative functors). > > > > What I've not yet understood is what the difference is between all of > >> these libraries? > >> > >> > > > > -- > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk > > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > -- 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 there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)
core.matrix maintainer here. I think it would be great to have more work on dataframe-type support. I think the right strategy is as follows: a) Make use of the core.matrix Dataset protocols where possible (or add new ones) b) Create implementation(s) for these protocols for whatever back-end data frame implementation is being used The beauty of core.matrix is that we *can* support multiple implementations without fragmentation, because the protocol based approach means that every implementation can use the same API. This is already working well for the array programming APIs (it's easy to mix and match Clojure data structures, Vectorz Java-based arrays, GPU backed arrays in computations). We just need to do the same for DataFrames. Now: the current core.matrix Dataset API is a bit focused on 2D data tables, but I think it can be extended to general N-dimensional dataframe capability. Would be a great project for someone to take on, happy to give guidance and help merge in changes as needed. I don't have a particularly strong opinion on which Dataframe implementations are best, but it looks like Spark and Renjin are both great candidates and would be very useful additions to the Clojure numerical ecosystem. If we do things right, they should interoperate easily with the core.matrix APIs, making Clojure ideal for "glue" code across such implementations. On Thursday, 10 March 2016 04:57:31 UTC+8, arthur.ma...@gmail.com wrote: > > Is there any desire or need for a Clojure DataFrame? > > > By DataFrame, I mean a structure similar to R's data.frame, and Python's > pandas.DataFrame. > > Incanter's DataSet may already be fulfilling this purpose, and if so, I'd > like to know if and how people are using it. > > From quickly researching, I see that some prior work has been done in this > space, such as: > > * https://github.com/cardillo/joinery > * https://github.com/mattrepl/data-frame > * > http://spark.apache.org/docs/latest/sql-programming-guide.html#dataframes > > Rather than going off and creating a competing implementation ( > https://xkcd.com/927/), I'd like to know if anyone here is actively > working on, or would like to work on a DataFrame and related utilities for > Clojure (and by extension Java)? Is it something that's sorely needed, or > is everybody happy with using Incanter or some other library that I'm not > aware of? If there's already a defacto standard out there, would anyone > care to please point it out? > > As background information: > > My specific use-case is in NLP and ML, where I often explore and prototype > in Python, but I'm then left to deal with a smattering of libraries on the > JVM (Mallet, Weka, Mahout, ND4J, DeepLearning4j, CoreNLP, etc.), each with > their own ad-hoc implementations of algorithms, matrices, and utilities for > reading data. It would be great to have a unified way to explore my data in > the Clojure REPL, and then serve the same code and models in production. > > I would love for Clojure to have a broadly compatible ecosystem similar to > Python's Numpy/Pandas/Scikit-*/Scipy/matplotlib/GenSim,etc. Core.Matrix and > Incanter appear to fulfill a large chunk of those roles, but I am not aware > if they've yet become the defacto standards in the community. > > Any feedback is greatly appreciated. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)
> > This is already working well for the array programming APIs (it's easy to > mix and match Clojure data structures, Vectorz Java-based arrays, GPU > backed arrays in computations). > While we could agree to some extent on the other parts of your post but the GPU part is *NOT* true: I would like you to point me to a single implementation anywhere (Clojure or other) that (easily or not) mixes and matches arrays in RAM and arrays on the GPU backend. It simply does not work that way. -- 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 there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)
Renjin and Spark's dataframes are not going to be easily removed from their respective codebases, as far as my brief perusal of the source can tell. I agree that N-D DataFrames would be a good addition to the ecosystem, similar to the goals of Python's xarray (xarray.pydata.org). However, it is not a priority for myself as of this time. Thanks for pointing out the DataSet proposal. I'll take a look at that later. On a slightly related note, where is the best place to ask core.matrix questions? I have some small questions about sparse matrix support in core.matrix, and what sparse formats are implemented. On Thursday, March 10, 2016 at 7:45:44 PM UTC-5, Mikera wrote: > > core.matrix maintainer here. > > I think it would be great to have more work on dataframe-type support. I > think the right strategy is as follows: > a) Make use of the core.matrix Dataset protocols where possible (or add > new ones) > b) Create implementation(s) for these protocols for whatever back-end data > frame implementation is being used > > The beauty of core.matrix is that we *can* support multiple > implementations without fragmentation, because the protocol based approach > means that every implementation can use the same API. This is already > working well for the array programming APIs (it's easy to mix and match > Clojure data structures, Vectorz Java-based arrays, GPU backed arrays in > computations). We just need to do the same for DataFrames. > > Now: the current core.matrix Dataset API is a bit focused on 2D data > tables, but I think it can be extended to general N-dimensional dataframe > capability. Would be a great project for someone to take on, happy to give > guidance and help merge in changes as needed. > > I don't have a particularly strong opinion on which Dataframe > implementations are best, but it looks like Spark and Renjin are both great > candidates and would be very useful additions to the Clojure numerical > ecosystem. If we do things right, they should interoperate easily with the > core.matrix APIs, making Clojure ideal for "glue" code across such > implementations. > > On Thursday, 10 March 2016 04:57:31 UTC+8, arthur.ma...@gmail.com wrote: >> >> Is there any desire or need for a Clojure DataFrame? >> >> >> By DataFrame, I mean a structure similar to R's data.frame, and Python's >> pandas.DataFrame. >> >> Incanter's DataSet may already be fulfilling this purpose, and if so, I'd >> like to know if and how people are using it. >> >> From quickly researching, I see that some prior work has been done in >> this space, such as: >> >> * https://github.com/cardillo/joinery >> * https://github.com/mattrepl/data-frame >> * >> http://spark.apache.org/docs/latest/sql-programming-guide.html#dataframes >> >> Rather than going off and creating a competing implementation ( >> https://xkcd.com/927/), I'd like to know if anyone here is actively >> working on, or would like to work on a DataFrame and related utilities for >> Clojure (and by extension Java)? Is it something that's sorely needed, or >> is everybody happy with using Incanter or some other library that I'm not >> aware of? If there's already a defacto standard out there, would anyone >> care to please point it out? >> >> As background information: >> >> My specific use-case is in NLP and ML, where I often explore and >> prototype in Python, but I'm then left to deal with a smattering of >> libraries on the JVM (Mallet, Weka, Mahout, ND4J, DeepLearning4j, CoreNLP, >> etc.), each with their own ad-hoc implementations of algorithms, matrices, >> and utilities for reading data. It would be great to have a unified way to >> explore my data in the Clojure REPL, and then serve the same code and >> models in production. >> >> I would love for Clojure to have a broadly compatible ecosystem similar >> to Python's Numpy/Pandas/Scikit-*/Scipy/matplotlib/GenSim,etc. Core.Matrix >> and Incanter appear to fulfill a large chunk of those roles, but I am not >> aware if they've yet become the defacto standards in the community. >> >> Any feedback is greatly appreciated. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is there any desire or need for a Clojure DataFrame? (X-POST from Numerical Clojure mailing list)
On Friday, 11 March 2016 09:09:14 UTC+8, Dragan Djuric wrote: > > This is already working well for the array programming APIs (it's easy to >> mix and match Clojure data structures, Vectorz Java-based arrays, GPU >> backed arrays in computations). >> > > While we could agree to some extent on the other parts of your post but > the GPU part is *NOT* true: I would like you to point me to a single > implementation anywhere (Clojure or other) that (easily or not) mixes and > matches arrays in RAM and arrays on the GPU backend. It simply does not > work that way. > You misunderstand my point. Obviously, there may need to be some copying when you move between managed and unmanaged memory. But I'm not talking about that: the point is that this can happen "under the hood", without the user needing to do explicit conversions etc. All thanks to the protocol implementations, you can mix and match GPU, native and Java backed instances with the same API. core.matrix can trivially do stuff like (add! native-array java-array) for example. What's not to like about that? -- 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.
changes in logging in 1.8?
Hi,
I noticed that after upgrade to Clojure 1.8.0 (from 1.7.0) a weird
occurrence of logging, even during uberjar generation which looks like
this, using lein 2.5.3:
$ lein uberjar
Compiling core
2016-03-10 22:11:23.030:INFO::main: Logging initialized @964ms
I believe that actual log is pegged from here
https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java#L186
, which gniazdo depend on.
I spend some time trying to better understand the underlying cause but
failed to do so. My questions are:
1) why client code would be executed during uberjar generation (provided
my assumption is valid)?
2) what changed in 1.8 to cause that?
Thanks in advance,
Andy
= sources
$ cat project.clj src/core.clj
(defproject tmp "0.1.0-SNAPSHOT"
:dependencies [[org.clojure/clojure "1.8.0"] [stylefruits/gniazdo
"0.4.1"]]
:profiles {:uberjar {:aot :all}})
(ns core
(:require [gniazdo.core :as ws]))
--
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.
