Re: Transducers are Coming
Looks nice, although I still need to wrap my head arround it. I don't believe in micro-benchmarks but I did one anyways cause I was curious how transduce would stack up against reduce (not reducers). https://github.com/thheller/transduce-bench transduce Evaluation count : 2220 in 60 samples of 37 calls. Execution time sample mean : 27,461565 ms Execution time mean : 27,462916 ms Execution time sample std-deviation : 132,937808 µs Execution time std-deviation : 136,285505 µs Execution time lower quantile : 27,263592 ms ( 2,5%) Execution time upper quantile : 27,792904 ms (97,5%) Overhead used : 2,409871 ns Found 2 outliers in 60 samples (3, %) low-severe 2 (3, %) Variance from outliers : 1,6389 % Variance is slightly inflated by outliers reduce Evaluation count : 1140 in 60 samples of 19 calls. Execution time sample mean : 53,925331 ms Execution time mean : 53,928024 ms Execution time sample std-deviation : 293,048053 µs Execution time std-deviation : 295,900746 µs Execution time lower quantile : 53,477577 ms ( 2,5%) Execution time upper quantile : 54,526940 ms (97,5%) Overhead used : 2,409871 ns Found 1 outliers in 60 samples (1,6667 %) low-severe 1 (1,6667 %) Variance from outliers : 1,6389 % Variance is slightly inflated by outliers Seems worth it even for this use-case but there are far more interesting things to do. Will keep playing with it for sure. Cheers, /thomas On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing > context-independent mapping, filtering etc to other areas, such as > core.async. > > This is work in progress. We will be cutting alpha releases to help make > it easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use > it. > > Please have a look. > > Feedback welcome, > > Rich > > -- 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: Transducers are Coming
Thanks Rich! Transducers, like all of your releases, are an eye opener. I've always felt slightly hesitant to use core.async's version of sequence functions, because of the overhead of intermediate channels. Then there was the strictness tradeoff with reducers. All of that complexity, gone from my head forever. Intermediate sequences aswell (can't wait to see the effect on gc pressure, once this is widely deployed). As usual, there is also the cherry: A smooth definition of the standard transducer constructors as the 1-arity of the sequence library. -- 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: Transducers are Coming
Will the new transducer abstraction also (partly) replace / incorporate the reducer library ? So we could do something like (def xform (comp (fold +) (map inc) (filter even?))) to leverage parallelism ? On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing > context-independent mapping, filtering etc to other areas, such as > core.async. > > This is work in progress. We will be cutting alpha releases to help make > it easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use > it. > > Please have a look. > > Feedback welcome, > > Rich > > -- 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: Cannot get Friend to work (login or unauthorized handler)
So here's what I discovered:
If I wrap ONLY the www-routes in Friend and remove api-routes entirely, it
works. So far, I've tried several combinations of route, handler/api,
handler/site and friend and I get incorrect results, most often a null page.
Any ideas on how to wrap both handler/api and handler/site routes in Friend?
On Wednesday, August 6, 2014 1:30:45 PM UTC-4, Gary Verhaegen wrote:
>
> I just checked, with the given code, after I switch the order of
> middlewares, a POST to /login gives me a 302 redirect to
> /login?&login_failed=Y while a POST with the correct credentials gives me a
> 303 to /.
>
> I'm sorry I cannot explain why, however.
>
> On Wednesday, 6 August 2014, Gary Verhaegen > wrote:
>
>> I was wrong, sorry. Looking at the code for
>> c.f.workflows/interactive-form, you can indeed see where it intercepts a
>> POST request to the provided :login-uri (lines 84-85 on current master).
>>
>> Which means I have absolutely no idea why it gives you a 404, except
>> maybe if it is related to the other point about the order of middlewares.
>>
>> Sorry for the confusion.
>>
>> On Wednesday, 6 August 2014, Jonathon McKitrick
>> wrote:
>>
>>> I'm confused. None of the examples shown implemented the login POST
>>> handler. The docs implied it was already part of the middleware:
>>>
>>> From https://github.com/cemerick/friend :
>>> >>>
>>> The example above defines a single workflow — one supporting the POSTing
>>> of :username and :password parameters to (by default) /login — which
>>> will discover the specified :credential-fn and use it to validate
>>> submitted credentials.
>>> <<<
>>>
>>>
>>> --
>>> Jonathon McKitrick
>>>
>>>
>>> On Wed, Aug 6, 2014 at 10:46 AM, Gary Verhaegen <
>>> gary.verhae...@gmail.com> wrote:
>>>
1. No, you have to provide it (as a non-protected route, obviously).
2. The order in which you apply the handler/site and
friend/authenticate middlewares is reversed: friend needs the session (and
others), so it should come "after" (or rather "within") the handler/site
to
work properly (in execution order).
On Wednesday, 6 August 2014, Jonathon McKitrick
wrote:
> First, the code:
>
> (ns pts.server
> (:use [compojure.core])
> (:require [ring.adapter.jetty :as jetty]
> [ring.util.response :as response]
> [compojure.handler :as handler]
> [compojure.route :as route]
> [cemerick.friend :as friend]
> (cemerick.friend [workflows :as workflows]
> [credentials :as creds])))
>
> (defroutes www-routes
> (GET "/locked" [] (friend/authorize #{::admin} "Admin only"))
> (GET "/home" [] (response/file-response "home.html" {:root
> "resources/public"}))
> (GET "/login" [] (response/file-response "login.html" {:root
> "resources/public"}))
> (GET "/" [] (response/redirect "index.html"))
> (route/resources "/")
> (route/not-found "Not Found"))
>
> (def app (handler/site www-routes))
>
> (def users {"root" {:username "root"
> :password (creds/hash-bcrypt "toor")
> :roles #{::admin}}})
>
> (def secure-app
> (-> app
> (friend/authenticate {:unauthorized-handler #(response/status
> (response/response "NO") 401)
> :credential-fn (partial
> creds/bcrypt-credential-fn users)
> :workflows
> [(workflows/interactive-form)]})))
>
> (defn -main [& args]
> (let [port (Integer/parseInt (get (System/getenv) "PORT" "3000"))]
> (jetty/run-jetty secure-app {:port port :join? false})))
>
> It's dead simple, but 2 major things are not working.
>
> 1. The POST to /login to submit the login form gives a 404 Not
> Found. Isn't the POST handler part of the friend/authenticate middleware?
> 2. Attempts to access the /locked URL throw an exception and a
> stacktrace, rather than calling the unauthorized handler:
> throw+: {:cemerick.friend/required-roles #{:pts.server/admin},
> :cemerick.friend/exprs ["Admin only"], :cemerick.friend/type
> :unauthorized,
> :cemerick.friend/identity nil}
>
> What am I doing wrong here?
>
> --
> 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.
>
Re: Cannot get Friend to work (login or unauthorized handler)
I think it's sequencing. I'm going to try swapping the routes for api and
site.
On Thursday, August 7, 2014 7:19:33 AM UTC-4, Jonathon McKitrick wrote:
>
> So here's what I discovered:
>
> If I wrap ONLY the www-routes in Friend and remove api-routes entirely, it
> works. So far, I've tried several combinations of route, handler/api,
> handler/site and friend and I get incorrect results, most often a null page.
>
> Any ideas on how to wrap both handler/api and handler/site routes in
> Friend?
>
> On Wednesday, August 6, 2014 1:30:45 PM UTC-4, Gary Verhaegen wrote:
>>
>> I just checked, with the given code, after I switch the order of
>> middlewares, a POST to /login gives me a 302 redirect to
>> /login?&login_failed=Y while a POST with the correct credentials gives me a
>> 303 to /.
>>
>> I'm sorry I cannot explain why, however.
>>
>> On Wednesday, 6 August 2014, Gary Verhaegen wrote:
>>
>>> I was wrong, sorry. Looking at the code for
>>> c.f.workflows/interactive-form, you can indeed see where it intercepts a
>>> POST request to the provided :login-uri (lines 84-85 on current master).
>>>
>>> Which means I have absolutely no idea why it gives you a 404, except
>>> maybe if it is related to the other point about the order of middlewares.
>>>
>>> Sorry for the confusion.
>>>
>>> On Wednesday, 6 August 2014, Jonathon McKitrick
>>> wrote:
>>>
I'm confused. None of the examples shown implemented the login POST
handler. The docs implied it was already part of the middleware:
From https://github.com/cemerick/friend :
>>>
The example above defines a single workflow — one supporting the POSTing
of :username and :password parameters to (by default) /login — which
will discover the specified :credential-fn and use it to validate
submitted credentials.
<<<
--
Jonathon McKitrick
On Wed, Aug 6, 2014 at 10:46 AM, Gary Verhaegen <
gary.verhae...@gmail.com> wrote:
> 1. No, you have to provide it (as a non-protected route, obviously).
> 2. The order in which you apply the handler/site and
> friend/authenticate middlewares is reversed: friend needs the session
> (and
> others), so it should come "after" (or rather "within") the handler/site
> to
> work properly (in execution order).
>
>
> On Wednesday, 6 August 2014, Jonathon McKitrick
> wrote:
>
>> First, the code:
>>
>> (ns pts.server
>> (:use [compojure.core])
>> (:require [ring.adapter.jetty :as jetty]
>> [ring.util.response :as response]
>> [compojure.handler :as handler]
>> [compojure.route :as route]
>> [cemerick.friend :as friend]
>> (cemerick.friend [workflows :as workflows]
>> [credentials :as creds])))
>>
>> (defroutes www-routes
>> (GET "/locked" [] (friend/authorize #{::admin} "Admin only"))
>> (GET "/home" [] (response/file-response "home.html" {:root
>> "resources/public"}))
>> (GET "/login" [] (response/file-response "login.html" {:root
>> "resources/public"}))
>> (GET "/" [] (response/redirect "index.html"))
>> (route/resources "/")
>> (route/not-found "Not Found"))
>>
>> (def app (handler/site www-routes))
>>
>> (def users {"root" {:username "root"
>> :password (creds/hash-bcrypt "toor")
>> :roles #{::admin}}})
>>
>> (def secure-app
>> (-> app
>> (friend/authenticate {:unauthorized-handler #(response/status
>> (response/response "NO") 401)
>> :credential-fn (partial
>> creds/bcrypt-credential-fn users)
>> :workflows
>> [(workflows/interactive-form)]})))
>>
>> (defn -main [& args]
>> (let [port (Integer/parseInt (get (System/getenv) "PORT" "3000"))]
>> (jetty/run-jetty secure-app {:port port :join? false})))
>>
>> It's dead simple, but 2 major things are not working.
>>
>> 1. The POST to /login to submit the login form gives a 404 Not
>> Found. Isn't the POST handler part of the friend/authenticate
>> middleware?
>> 2. Attempts to access the /locked URL throw an exception and a
>> stacktrace, rather than calling the unauthorized handler:
>> throw+: {:cemerick.friend/required-roles #{:pts.server/admin},
>> :cemerick.friend/exprs ["Admin only"], :cemerick.friend/type
>> :unauthorized,
>> :cemerick.friend/identity nil}
>>
>> What am I doing wrong here?
>>
>> --
>> 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
Re: Transducers are Coming
The integration with reducers is still todo. On Aug 7, 2014, at 7:03 AM, Niels van Klaveren wrote: > Will the new transducer abstraction also (partly) replace / incorporate the > reducer library ? > So we could do something like (def xform (comp (fold +) (map inc) (filter > even?))) to leverage parallelism ? > > On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing context-independent > mapping, filtering etc to other areas, such as core.async. > > This is work in progress. We will be cutting alpha releases to help make it > easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use it. > > Please have a look. > > Feedback welcome, > > Rich > > > -- > 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.
Compojure routing of www and api content
I'm serving up some html and js content, and using handler/site for that.
I have a separate handler/api group of routes under the "/api" context.
If I include the api routes before the site routes, the site works fine.
If the www routes come first, the api calls fail, probably because the
(route/resources "/") at the end of the site routes catches that call and
returns null.
OTOH, if I try to use friend with the api routes, it breaks the friend
wrapping of the www calls.
(defroutes api-routes
(context "/api" []
.
(route/not-found "ERROR")))
(defroutes www-routes
(GET "/admin" req (friend/authorize #{::admin} "Admin only"))
(GET "/authorized" req (friend/authorize #{::user} "Users only"))
(GET "/home" [] (response/file-response "home.html" {:root
"resources/public"}))
(GET "/login" [] (response/file-response "login.html" {:root
"resources/public"}))
(friend/logout (ANY "/logout" req (response/redirect "/")))
(GET "/" [] (response/redirect "index.html"))
(route/resources "/")
(route/not-found "Not Found"))
(def app
(routes
(-> www-routes
(friend/authenticate {;:allow-anon? true
;;:login-uri "/login.html"
;:default-landing-uri "/"
;:redirect-on-auth? "/home"
;:unauthorized-handler #(response/status
(response/response "NO") 401)
;:login-failure-handler #(response/response
"OOPS")
:credential-fn (partial
creds/bcrypt-credential-fn users)
:workflows [(workflows/interactive-form)]})
;;(wrap-resource "public")
;wrap-content-type
;wrap-not-modified
;;wrap-reload
handler/site)
(-> api-routes
handler/api
;;wrap-reload
wrap-restful-format)))
--
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.
Write/reading java maps and lists using fressian/transit
Hi, I have a program I wrote who needs to serialize java HashMaps and ArrayLists to and from disk but AFAIK (and after some simple tests) it seems fressian writes those maps/lists correctly but read them back as clojure maps and lists (persistent). Is there a way to tell fressian (could be transit too) to read them back as java maps/lists? Just for some context, it's a huge amount of data and it should be serialized in binary format/non-human readable way for performance and space considerations. All the data is composed of simple types (maps, lists, strings, numbers, keywords only. No complex objects) I'm thinking about maybe just using some java serialization library if fressian/transit doesn't support that. 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: Transducers are Coming
Oh dear, I still haven't understood the blogpost on reducers yet, and now there is this one as well. Phil Rich Hickey writes: > I pushed today the initial work on transducers. I describe transducers briefly > in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing context-independent > mapping, filtering etc to other areas, such as core.async. > > This is work in progress. We will be cutting alpha releases to help make it > easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use it. > > Please have a look. > > Feedback welcome, > > Rich -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@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: Transducers are Coming
Hello, what is the reason for comp to produce two different orderings depending on whether it composes partials or transducers? (comp (partial filter even?) (partial map (partial + 1))) (comp (filter even?) (map (partial + 1))) Wouldn't it be more intuitive for upcoming clojurians to have both cases exhibit the same execution order? On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing > context-independent mapping, filtering etc to other areas, such as > core.async. > > This is work in progress. We will be cutting alpha releases to help make > it easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use > it. > > Please have a look. > > Feedback welcome, > > Rich > > -- 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] Silk, an isomorphic routing library for Clojure and ClojureScript
I agree with Joel that I've found that secretary works very well with Om, especially with a few abstractions built over it to built the corresponding state. The opposite direction is tricky though, and the biggest problem I've run into is that matching order is based on runtime route declaration order, and as Dom points out, if you try to do this across namespaces, you're in for trouble. In practive, I've never wanted or needed to define routes in any way but top to bottom in a single file. That said, I think the Silk approach is very elegant. First, isomorphism is great, good one. Second, being able to easily define subsets of routes and match/unmatch on arbitrary combinations of them is very powerful and highly composable. You could use the same (Google History) hash change token → dispatch! → data → transition! (Om), where dispatch! is a match on a group of routes. The state -> route direction is much cleaner with silk. It simplifies the problem a lot to be able to filter your routes to only include those dealing with your current app state, then selecting from your app state and matching on the filtered routes. I was trying to do something similar with Tao (although it was an alpha level mess), but ended up being hampered by the somewhat hidden nature of secretary matching/unmatching. I agree it's a shame to keep reinventing the wheel, but while I like secretary, I've never felt that it's approach was the be all end all. I appreciate some of the sentiment of "if it ain't broke, don't fix it," but more good ideas in the mix only push us all to write better code. Dom, some questions and thoughts for improvement. If you define routes with :path and :query, will the route match/unmatch with undefined query keys? If so, how are they handled? If not, I'd suggest making query matching optional, where nils are substituted. It's a little unclear how your matching functions relate to route. It looks like Silk always breaks at / in path and matches, is that correct? There are some really good things in secretary. What do you think about them? Splat, regex, format matchers. protocol based render function for multiple arity "unmatching." this is really great. and more I'm sure I'm missing -- 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: Write/reading java maps and lists using fressian/transit
Both Transit and fressian take a Handler map as arguments to the reader/writer functions/constructors. So its pretty straightforward to replace the default handlers with handlers that do what you want. I have no example handy but it should be documented in both libraries. Transit has something called mapBuilder, not sure about fressian. HTH, /thomas On Thursday, August 7, 2014 2:48:20 PM UTC+2, Islon Scherer wrote: > > Hi, > > I have a program I wrote who needs to serialize java HashMaps and > ArrayLists to and from disk but AFAIK (and after some simple tests) it > seems fressian writes those maps/lists correctly but read them back as > clojure maps and lists (persistent). > Is there a way to tell fressian (could be transit too) to read them back > as java maps/lists? > Just for some context, it's a huge amount of data and it should be > serialized in binary format/non-human readable way for performance and > space considerations. All the data is composed of simple types (maps, > lists, strings, numbers, keywords only. No complex objects) > I'm thinking about maybe just using some java serialization library if > fressian/transit doesn't support that. > > 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: Compojure routing of www and api content
Compojure routes are checked in order until one matches. You've set up your
www-routes to match all possible routes, as you have a "catch-all"
not-found route at the bottom.
- James
On 7 August 2014 13:17, Jonathon McKitrick wrote:
> I'm serving up some html and js content, and using handler/site for that.
> I have a separate handler/api group of routes under the "/api" context.
>
> If I include the api routes before the site routes, the site works fine.
> If the www routes come first, the api calls fail, probably because the
> (route/resources "/") at the end of the site routes catches that call and
> returns null.
>
> OTOH, if I try to use friend with the api routes, it breaks the friend
> wrapping of the www calls.
>
> (defroutes api-routes
> (context "/api" []
> .
>(route/not-found "ERROR")))
>
> (defroutes www-routes
> (GET "/admin" req (friend/authorize #{::admin} "Admin only"))
> (GET "/authorized" req (friend/authorize #{::user} "Users only"))
> (GET "/home" [] (response/file-response "home.html" {:root
> "resources/public"}))
> (GET "/login" [] (response/file-response "login.html" {:root
> "resources/public"}))
> (friend/logout (ANY "/logout" req (response/redirect "/")))
> (GET "/" [] (response/redirect "index.html"))
> (route/resources "/")
> (route/not-found "Not Found"))
>
> (def app
> (routes
>(-> www-routes
>(friend/authenticate {;:allow-anon? true
> ;;:login-uri "/login.html"
> ;:default-landing-uri "/"
> ;:redirect-on-auth? "/home"
> ;:unauthorized-handler #(response/status
> (response/response "NO") 401)
> ;:login-failure-handler #(response/response
> "OOPS")
> :credential-fn (partial
> creds/bcrypt-credential-fn users)
> :workflows [(workflows/interactive-form)]})
>;;(wrap-resource "public")
>;wrap-content-type
>;wrap-not-modified
>;;wrap-reload
>handler/site)
>(-> api-routes
>handler/api
>;;wrap-reload
>wrap-restful-format)))
>
> --
> 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: Compojure routing of www and api content
Right, I tried removing that as well, and Friend still fails, and the api
routes fail as well.
--
Jonathon McKitrick
On Thu, Aug 7, 2014 at 2:54 PM, James Reeves wrote:
> Compojure routes are checked in order until one matches. You've set up
> your www-routes to match all possible routes, as you have a "catch-all"
> not-found route at the bottom.
>
> - James
>
>
> On 7 August 2014 13:17, Jonathon McKitrick wrote:
>
>> I'm serving up some html and js content, and using handler/site for
>> that. I have a separate handler/api group of routes under the "/api"
>> context.
>>
>> If I include the api routes before the site routes, the site works fine.
>> If the www routes come first, the api calls fail, probably because the
>> (route/resources "/") at the end of the site routes catches that call and
>> returns null.
>>
>> OTOH, if I try to use friend with the api routes, it breaks the friend
>> wrapping of the www calls.
>>
>> (defroutes api-routes
>> (context "/api" []
>> .
>>(route/not-found "ERROR")))
>>
>> (defroutes www-routes
>> (GET "/admin" req (friend/authorize #{::admin} "Admin only"))
>> (GET "/authorized" req (friend/authorize #{::user} "Users only"))
>> (GET "/home" [] (response/file-response "home.html" {:root
>> "resources/public"}))
>> (GET "/login" [] (response/file-response "login.html" {:root
>> "resources/public"}))
>> (friend/logout (ANY "/logout" req (response/redirect "/")))
>> (GET "/" [] (response/redirect "index.html"))
>> (route/resources "/")
>> (route/not-found "Not Found"))
>>
>> (def app
>> (routes
>>(-> www-routes
>>(friend/authenticate {;:allow-anon? true
>> ;;:login-uri "/login.html"
>> ;:default-landing-uri "/"
>> ;:redirect-on-auth? "/home"
>> ;:unauthorized-handler #(response/status
>> (response/response "NO") 401)
>> ;:login-failure-handler #(response/response
>> "OOPS")
>> :credential-fn (partial
>> creds/bcrypt-credential-fn users)
>> :workflows [(workflows/interactive-form)]})
>>;;(wrap-resource "public")
>>;wrap-content-type
>>;wrap-not-modified
>>;;wrap-reload
>>handler/site)
>>(-> api-routes
>>handler/api
>>;;wrap-reload
>>wrap-restful-format)))
>>
>> --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/A-qRAftd6XY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Compojure routing of www and api content
Let me clarify. I removed the 'not-found' route and the api calls all
return an empty response.
--
Jonathon McKitrick
On Thu, Aug 7, 2014 at 3:14 PM, Jonathon McKitrick
wrote:
> Right, I tried removing that as well, and Friend still fails, and the api
> routes fail as well.
>
>
> --
> Jonathon McKitrick
>
>
> On Thu, Aug 7, 2014 at 2:54 PM, James Reeves
> wrote:
>
>> Compojure routes are checked in order until one matches. You've set up
>> your www-routes to match all possible routes, as you have a "catch-all"
>> not-found route at the bottom.
>>
>> - James
>>
>>
>> On 7 August 2014 13:17, Jonathon McKitrick wrote:
>>
>>> I'm serving up some html and js content, and using handler/site for
>>> that. I have a separate handler/api group of routes under the "/api"
>>> context.
>>>
>>> If I include the api routes before the site routes, the site works
>>> fine. If the www routes come first, the api calls fail, probably because
>>> the (route/resources "/") at the end of the site routes catches that call
>>> and returns null.
>>>
>>> OTOH, if I try to use friend with the api routes, it breaks the friend
>>> wrapping of the www calls.
>>>
>>> (defroutes api-routes
>>> (context "/api" []
>>> .
>>>(route/not-found "ERROR")))
>>>
>>> (defroutes www-routes
>>> (GET "/admin" req (friend/authorize #{::admin} "Admin only"))
>>> (GET "/authorized" req (friend/authorize #{::user} "Users only"))
>>> (GET "/home" [] (response/file-response "home.html" {:root
>>> "resources/public"}))
>>> (GET "/login" [] (response/file-response "login.html" {:root
>>> "resources/public"}))
>>> (friend/logout (ANY "/logout" req (response/redirect "/")))
>>> (GET "/" [] (response/redirect "index.html"))
>>> (route/resources "/")
>>> (route/not-found "Not Found"))
>>>
>>> (def app
>>> (routes
>>>(-> www-routes
>>>(friend/authenticate {;:allow-anon? true
>>> ;;:login-uri "/login.html"
>>> ;:default-landing-uri "/"
>>> ;:redirect-on-auth? "/home"
>>> ;:unauthorized-handler #(response/status
>>> (response/response "NO") 401)
>>> ;:login-failure-handler #(response/response
>>> "OOPS")
>>> :credential-fn (partial
>>> creds/bcrypt-credential-fn users)
>>> :workflows [(workflows/interactive-form)]})
>>>;;(wrap-resource "public")
>>>;wrap-content-type
>>>;wrap-not-modified
>>>;;wrap-reload
>>>handler/site)
>>>(-> api-routes
>>>handler/api
>>>;;wrap-reload
>>>wrap-restful-format)))
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/A-qRAftd6XY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https
Re: Write/reading java maps and lists using fressian/transit
Ok, I got it. Instead of using transit-clj I can user the java library directly. The reader automatically returns ArrayList and HashMap. Great! On Thursday, August 7, 2014 8:11:50 PM UTC+2, Thomas Heller wrote: > > Both Transit and fressian take a Handler map as arguments to the > reader/writer functions/constructors. So its pretty straightforward to > replace the default handlers with handlers that do what you want. > > I have no example handy but it should be documented in both libraries. > Transit has something called mapBuilder, not sure about fressian. > > HTH, > /thomas > > On Thursday, August 7, 2014 2:48:20 PM UTC+2, Islon Scherer wrote: >> >> Hi, >> >> I have a program I wrote who needs to serialize java HashMaps and >> ArrayLists to and from disk but AFAIK (and after some simple tests) it >> seems fressian writes those maps/lists correctly but read them back as >> clojure maps and lists (persistent). >> Is there a way to tell fressian (could be transit too) to read them back >> as java maps/lists? >> Just for some context, it's a huge amount of data and it should be >> serialized in binary format/non-human readable way for performance and >> space considerations. All the data is composed of simple types (maps, >> lists, strings, numbers, keywords only. No complex objects) >> I'm thinking about maybe just using some java serialization library if >> fressian/transit doesn't support that. >> >> 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: Transducers are Coming
Just wanted to add that all of the current transducers work in Clojure is now available in ClojureScript master. David On Wed, Aug 6, 2014 at 2:01 PM, Rich Hickey wrote: > I pushed today the initial work on transducers. I describe transducers > briefly in this blog post: > > http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming > > This work builds on the work done for reducers, bringing context-independent > mapping, filtering etc to other areas, such as core.async. > > This is work in progress. We will be cutting alpha releases to help make it > easier to start using core's transducers together with core.async's new > support for them. > > I am very excited about this powerful technique and how we all might use it. > > Please have a look. > > Feedback welcome, > > Rich > > -- > 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: ClojureScript 0.0-2301, Transducers!
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2301 Leiningen dependency information: [org.clojure/clojurescript "0.0-2301"] The primary reason for this release is the inclusion of the Clojure tranducers work. ### Changes * transducers ### Fixes * eliminate dead branches in conditionals to prevent Closure warnings * bad var resolution if local contained `.` -- 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] Silk, an isomorphic routing library for Clojure and ClojureScript
I'm in agreement that Silk is a step in the right direction. I've reached out to Dom and I think we can learn a lot from each other and work together to improve the routing story in Clojure overall. > There are some really good things in secretary. What do you think about them? > Splat, regex, format matchers. > protocol based render function for multiple arity "unmatching." this is > really great. These are definitely nice things and I'm willing to bet Silk would be capable of supporting some of them. It's obvious to me to that if we can iron out the details with Silk, Secretary could built on top of it as a higher level interface while at the same time taking advantage of what Silk has to offer. It might mean some breaking changes in Secretary but those were already slated anyway. -- 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: ClojureScript 0.0-2301, Transducers!
I just cut 0.0-2307, the only change is that the compiler now optimizes anonymous multi-arity fns which results in a big performance boost to transducer code. David On Thu, Aug 7, 2014 at 5:08 PM, David Nolen wrote: > ClojureScript, the Clojure compiler that emits JavaScript source code. > > README and source code: https://github.com/clojure/clojurescript > > New release version: 0.0-2301 > > Leiningen dependency information: > > [org.clojure/clojurescript "0.0-2301"] > > The primary reason for this release is the inclusion of the Clojure > tranducers work. > > ### Changes > * transducers > > ### Fixes > * eliminate dead branches in conditionals to prevent Closure warnings > * bad var resolution if local contained `.` -- 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: Transducers are Coming
I'm also curious to understand how the underlying implementation of transducers leads function composition to behave in the reverse order of ordinary function composition. On Thu, Aug 7, 2014 at 8:07 AM, wrote: > Hello, what is the reason for comp to produce two different orderings > depending on whether it composes partials or transducers? > > (comp (partial filter even?) (partial map (partial + 1))) > (comp (filter even?) (map (partial + 1))) > > Wouldn't it be more intuitive for upcoming clojurians to have both > cases exhibit the same execution order? > > > On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: > >> I pushed today the initial work on transducers. I describe transducers >> briefly in this blog post: >> >> http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming >> >> This work builds on the work done for reducers, bringing >> context-independent mapping, filtering etc to other areas, such as >> core.async. >> >> This is work in progress. We will be cutting alpha releases to help make >> it easier to start using core's transducers together with core.async's new >> support for them. >> >> I am very excited about this powerful technique and how we all might use >> it. >> >> Please have a look. >> >> Feedback welcome, >> >> Rich >> >> -- > 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: Transducers are Coming
I doubt I can answer this as clearly as Rich or others but... I think the answer to this lies in the fact that composing transducers is composing reducer-transformers not reducer functions themselves. When composing reducer-transformers, the result is another transformer. When this new transformer is actually applied to a reducer function that reducer function is augmented with the composed transformer's functionality from the outside in so to speak. So if a,b, and c are transducers and we can create a new one abc via (comp a b c). In order to do something useful with that we must apply it to a reducer function so we could do (abc identity), which, would yield a reducer function that, during a reduce, would do a then b then c then identity to each value - outside in. So, the transducers are composed just like any other functions but when they're actually used, their logic seems to work left to right. It reminds me somewhat of the way monad transformers work in Haskell (my not-totally-fluent-knowledge) where each monad transformer augments the existing monad with new monad functionality. The original monad becomes the "inner" monad and the transformer's logic gets wrapped on top of the inner monad. /stt On Thursday, August 7, 2014 8:24:52 PM UTC-4, puzzler wrote: > > I'm also curious to understand how the underlying implementation of > transducers leads function composition to behave in the reverse order of > ordinary function composition. > > > On Thu, Aug 7, 2014 at 8:07 AM, > wrote: > >> Hello, what is the reason for comp to produce two different orderings >> depending on whether it composes partials or transducers? >> >> (comp (partial filter even?) (partial map (partial + 1))) >> (comp (filter even?) (map (partial + 1))) >> >> Wouldn't it be more intuitive for upcoming clojurians to have both >> cases exhibit the same execution order? >> >> >> On Wednesday, August 6, 2014 8:01:24 PM UTC+2, Rich Hickey wrote: >> >>> I pushed today the initial work on transducers. I describe transducers >>> briefly in this blog post: >>> >>> http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming >>> >>> This work builds on the work done for reducers, bringing >>> context-independent mapping, filtering etc to other areas, such as >>> core.async. >>> >>> This is work in progress. We will be cutting alpha releases to help make >>> it easier to start using core's transducers together with core.async's new >>> support for them. >>> >>> I am very excited about this powerful technique and how we all might use >>> it. >>> >>> Please have a look. >>> >>> Feedback welcome, >>> >>> Rich >>> >>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
Thanks for your feedback, Dylan!
If you define routes with :path and :query, will the route match/unmatch
> with undefined query keys? If so, how are they handled? If not, I'd suggest
> making query matching optional, where nils are substituted.
I'm not entirely sure what you mean, but I'll give it a shot. Please
provide some example code if I answered the wrong question.
`nil` is a pattern that matches anything. If your URL pattern query is
`nil` then the URL query will not be checked.
A map is a pattern that matches its values against the values of another
map. Therefore, `nil` and `{}` are equivalent when used as a query pattern.
You can make a query value pattern optional by wrapped it with
`silk/option`.
It's a little unclear how your matching functions relate to route. It looks
> like Silk always breaks at / in path and matches, is that correct?
Yes. There is a URL type in Silk and matching is done against instances of
it. The path is represented as a vector of segments.
The readme is currently very deficient and I apologize for that.
There are some really good things in secretary. What do you think about
> them?
> Splat, regex, format matchers.
In terms of regex matching, Silk used to have a built-in regex pattern but
I removed it when I made a big architectural change. I forget why I removed
it, but I'll re-add it since it does seem like a very common requirement.
Currently, part of Secretary's splat exists as a built-in Silk pattern. For
example, `(silk/composite ["foo" :* "bar"])` would match "fooanythingbar"
and return `{:* "anything"}`. The `:*` isn't special; it's just a keyword.
Format is just a specific case of composite: `(silk/composite [:* "."
:format])`. Unlike Secretary, Silk does not have a built-in special syntax
for string patterns. This is because special syntax strings are not
composable and, since Silk matches against unencoded strings, who am I to
say you can't have ":" or "*" in your URL paths? ;)
Looking at the Secretary readme, there appear to be two ways to use splat
that Silk currently does not have built-in support for. In Secretary,
"/foo/*" would match "/foo/bar/baz" and return `{:* "bar/baz"}`. Also,
"/*/*" would match "/a/b" and return `{:* ["a" "b"]}`. I keep saying
"built-in" because, while multi-segment path patterns and binding the same
parameter key to multiple path segments does not currently exist in Silk,
it is very easy to extend Silk with that functionality. You could easily
create a pattern that did exactly what Secretary and Clout do by default
and use it to match a path instead of a vector. However, I do question the
utility of these two features. Are either of these common requirements and,
if so, could I see some examples of why they are necessary or helpful? This
isn't rhetorical; please let me know if Silk is missing something that is
within its scope and is useful to most consumers.
protocol based render function for multiple arity "unmatching." this is
> really great.
I don't think I fully understand the use cases for this protocol. Do you
want to be able to look routes up by types? If so, since route names in
Silk can be anything, you could use a type as a name. Anyway, I put
together this little gist
of ways in which Silk
could be used similarly to how I *think* someone might use Secretary's
IRenderRoute. Do these cover the use cases for that protocol?
I also agree with everything in Joel's response and look forward to working
with him on improving the routing story. :)
On Thu, Aug 7, 2014 at 2:52 PM, Joel Holdbrooks
wrote:
> I'm in agreement that Silk is a step in the right direction. I've reached
> out to Dom and I think we can learn a lot from each other and work together
> to improve the routing story in Clojure overall.
>
> > There are some really good things in secretary. What do you think about
> them?
> > Splat, regex, format matchers.
> > protocol based render function for multiple arity "unmatching." this is
> really great.
>
> These are definitely nice things and I'm willing to bet Silk would be
> capable of supporting some of them.
>
> It's obvious to me to that if we can iron out the details with Silk,
> Secretary could built on top of it as a higher level interface while at the
> same time taking advantage of what Silk has to offer. It might mean some
> breaking changes in Secretary but those were already slated anyway.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>
--
You received this message because you are subscribed to the Google
G
