Re: “compiling” stacktrace error

2016-02-12 Thread Scaramaccai


On Friday, February 12, 2016 at 9:51:50 AM UTC+1, Scaramaccai wrote:
>
>
>
> On Thursday, February 11, 2016 at 9:54:19 PM UTC+1, Sean Corfield wrote:
>>
>> Scaramaccai wrote on Thursday, February 11, 2016 at 8:32 AM: 
>> >I'm learning Clojure, and I find difficult to understand where a 
>> specific compiler error happens: 
>>
>> The stacktraces can be pretty daunting at first, unfortunately. 
>>
>> How are you compiling / running the code? That will have some bearing on 
>> how errors are reported. 
>>
>>
> Yes, the problem seems to be how I compiled the code. I was using 
> Vim+Fireplace, and doing a "cpr" (takes the content from the active buffer 
> and requires it inside the REPL) I had the error without a proper 
> stacktrace (see below). Running using "reipl run" gives the "proper" 
> stacktrace:
>


BTW using 

(.printStackTrace *e)

>From inside the REPL gave me the full stack... so I can actually keep using 
Fireplace and get the full stack when needed.

-- 
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: “compiling” stacktrace error

2016-02-12 Thread Scaramaccai


On Thursday, February 11, 2016 at 9:54:19 PM UTC+1, Sean Corfield wrote:
>
> Scaramaccai wrote on Thursday, February 11, 2016 at 8:32 AM: 
> >I'm learning Clojure, and I find difficult to understand where a specific 
> compiler error happens: 
>
> The stacktraces can be pretty daunting at first, unfortunately. 
>
> How are you compiling / running the code? That will have some bearing on 
> how errors are reported. 
>
>
Yes, the problem seems to be how I compiled the code. I was using 
Vim+Fireplace, and doing a "cpr" (takes the content from the active buffer 
and requires it inside the REPL) I had the error without a proper 
stacktrace (see below). Running using "reipl run" gives the "proper" 
stacktrace:

[...]
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
clojure.lang.IPersistentCollection
at clojure.core$conj__4345.invokeStatic(core.clj:82)
at clojure.core$conj__4345.invoke(core.clj:82)
at fwpd.core$fib_seq3.invokeStatic(core.clj:98)
at fwpd.core$fib_seq3.invoke(core.clj:92)
at fwpd.core$fib_seq3.invokeStatic(core.clj:94)
at fwpd.core$fib_seq3.invoke(core.clj:92)
at fwpd.core$eval70.invokeStatic(core.clj:105)
at fwpd.core$eval70.invoke(core.clj:105)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.load(Compiler.java:7379)


*Thank you!!!*


Fireplace+REPL stacktrace:

|| java.lang.ClassCastException: java.lang.Long cannot be cast to 
clojure.lang.IPersistentCollection, compiling:(fwpd/core.clj:100:1)
|| clojure.lang.Compiler.load(Compiler.java:7391)
|| clojure.lang.RT.loadResourceScript(RT.java:372)
|| clojure.lang.RT.loadResourceScript(RT.java:363)
|| clojure.lang.RT.load(RT.java:453)
|| clojure.lang.RT.load(RT.java:419)
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5893|
 
clojure.core$load$fn__5677.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5892|
 
clojure.core$load.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5876|
 
clojure.core$load.doInvoke
|| clojure.lang.RestFn.invoke(RestFn.java:408)
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5697|
 
clojure.core$load_one.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5692|
 
clojure.core$load_one.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5737|
 
clojure.core$load_lib$fn__5626.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5736|
 
clojure.core$load_lib.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5717|
 
clojure.core$load_lib.doInvoke
|| clojure.lang.RestFn.applyTo(RestFn.java:142)
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|648|
 
clojure.core$apply.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5774|
 
clojure.core$load_libs.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5758|
 
clojure.core$load_libs.doInvoke
|| clojure.lang.RestFn.applyTo(RestFn.java:137)
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|648|
 
clojure.core$apply.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5796|
 
clojure.core$require.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|5796|
 
clojure.core$require.doInvoke
|| clojure.lang.RestFn.invoke(RestFn.java:421)
|| fwpd.core$eval3604.invokeStatic(form-init936506867427907734.clj:1)
|| fwpd.core$eval3604.invoke(form-init936506867427907734.clj:1)
|| clojure.lang.Compiler.eval(Compiler.java:6927)
|| clojure.lang.Compiler.eval(Compiler.java:6890)
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|3105|
 
clojure.core$eval.invokeStatic
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\core.clj|3101|
 
clojure.core$eval.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\main.clj|240|
 
clojure.main$repl$read_eval_print__7408$fn__7411.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\main.clj|240|
 
clojure.main$repl$read_eval_print__7408.invoke
zipfile:C:\Users\105066315\.m2\repository\org\clojure\clojure\1.8.0\clojure-1.8.0.jar::clojure\main.clj|258|
 
clojure.main$repl$fn__7417.invoke

Re: “compiling” stacktrace error

2016-02-12 Thread Stuart Sierra
(.printStackTrace *e) 
will print the full stacktrace of the most recent exception to the standard 
error stream (STDERR) of the Java process.

Depending on your REPL / tooling environment, stuff printed to standard 
error may not show up in your REPL. If that happens, try this:
(.printStackTrace *e *out*)

*out* is Clojure's thread-local binding for standard output (STDOUT), which 
tools like nREPL rebind to capture output and display in the REPL.

–S

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [ANN] dali SVG library 0.7.0

2016-02-12 Thread James Elliott
I agree, lovely indeed--I am already being tempted to learn to use it to 
just create some diagrams for my own documentation! Thank you.

On Wednesday, February 10, 2016 at 7:40:57 PM UTC-6, Colin Fleming wrote:
>
> This looks really lovely, thanks!
>
> On 11 February 2016 at 13:51, Stathis Sideris  > wrote:
>
>> ...aaand the link to the repo: https://github.com/stathissideris/dali
>>
>>
>> On Thursday, 11 February 2016 00:49:54 UTC, Stathis Sideris wrote:
>>>
>>> Hello all,
>>>
>>> dali is a Clojure library for representing the SVG graphics format. It 
>>> allows the creation and manipulation of SVG files. The syntax 
>>>  used 
>>> to describe the graphical elements is based on hiccup 
>>>  with a few extensions.
>>>
>>> The main advantage of dali is that it provides facilities to perform 
>>> complex layouts 
>>>  
>>> without having to position elements explicitly.
>>>
>>> The 0.7.0 brings a lot of new features and very complete documentation 
>>> to get you started.
>>>
>>> All feedback very welcome.
>>>
>>>
>>> Thanks,
>>>
>>> Stathis Sideris
>>>
>> -- 
>> 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: “compiling” stacktrace error

2016-02-12 Thread Sean Corfield
Scaramaccai wrote on Friday, February 12, 2016 at 1:01 AM:
On Friday, February 12, 2016 at 9:51:50 AM UTC+1, Scaramaccai wrote:
Yes, the problem seems to be how I compiled the code. I was using 
Vim+Fireplace, and doing a "cpr" (takes the content from the active buffer and 
requires it inside the REPL) I had the error without a proper stacktrace (see 
below). Running using "reipl run" gives the "proper" stacktrace:
BTW using 

(.printStackTrace *e)

>From inside the REPL gave me the full stack... so I can actually keep using 
>Fireplace and get the full stack when needed.

Excellent!

Welcome to the Clojure community BTW.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood




-- 
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.


Trouble replacing deprecated map< function

2016-02-12 Thread James Reeves
I currently have some core.async code that looks like:

(map< :foo ch)

However, map< and map> are now deprecated, with the suggestion to use
transducers instead. Unfortunately it's not obvious how to go about that.

At first I thought that I could use a pipe and a new channel:

(pipe ch (chan 1 (map :foo)))

But there's no distinction between channel input and output here. This
matters because I'm using a bidirectional channel from Chord
.

I'm thinking that it would be nice to have some functions like:

(eduction< ch xform)
(eduction> ch xform)
(eduction ch xform)

So I could write something like:

(eduction< ch (map :foo))

Have I missed anything? Is there some equivalent to this functionality
already in core.async that I haven't noticed?

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: (type ...) vs (class ...)

2016-02-12 Thread Kevin Downey
On 02/12/2016 01:37 PM, Alan Thompson wrote:
> Hey - Just saw something on the clojure.core/type function:
> 
> 
> 
> (defn type
>   "Returns the :type metadata of x, or its Class if none"
>   {:added "1.0"
>   :static true}
>   [x]
>   (or (get (meta x) :type) (class x)))
> 
> 
> 
> I have never seen this before, and it appears the :type metadata is not
> used in the clojure.core source code itself.  Is this ever used for
> anything or is it just a vestigial remnant from long ago?
> 
> Alan

It is used by the printing system (see core_print.clj). If I write a
multimethod that is dispatching on type/class whatever, `type` is the
first function I reach for.

> 
> -- 
> 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.


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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.


(type ...) vs (class ...)

2016-02-12 Thread Alan Thompson
Hey - Just saw something on the clojure.core/type function:



(defn type
"Returns the :type metadata of x, or its Class if none"
{:added "1.0"
:static true}
[x]
(or (get (meta x) :type) (class x)))


I have never seen this before, and it appears the :type metadata is not
used in the clojure.core source code itself.  Is this ever used for
anything or is it just a vestigial remnant from long ago?

Alan

-- 
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.


Chaining compojure routes

2016-02-12 Thread JvJ
I'm just starting to use ring/compojure to create web apps.

One thing I would like to do is have an updatable collection of apps that 
can be accessed based on the URL input.

For example, if I have an app named "foo", then website.com/foo would 
redirect to that app.

So far, I have the following implementation:

(def route-m
  {"foo" (routes (GET "/foo" [] "Hello Foo!"))
   "bar" (routes
  (GET "/bar/baz" [] "Hello Foo!")
  (GET "/bar/quux" [] "Hello Quux!"))})

(def test-r
  (routes
   (GET "/hey"
[]
"HEY!")
   (GET "/:app*" [app]
(route-m app


The issue with this method is the fact that the "sub-routes" need to have 
the full path instead of just the sub-path.  For example, "foo" needs to 
define its routes in terms of "foo/..." instead of just "/...".

Is there any way around this?

Thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: (type ...) vs (class ...)

2016-02-12 Thread Kevin Downey
On 02/12/2016 01:47 PM, Kevin Downey wrote:
> On 02/12/2016 01:37 PM, Alan Thompson wrote:
>> Hey - Just saw something on the clojure.core/type function:
>>
>>
>>
>> (defn type
>>  "Returns the :type metadata of x, or its Class if none"
>>  {:added "1.0"
>>  :static true}
>>  [x]
>>  (or (get (meta x) :type) (class x)))
>>
>>
>>
>> I have never seen this before, and it appears the :type metadata is not
>> used in the clojure.core source code itself.  Is this ever used for
>> anything or is it just a vestigial remnant from long ago?
>>
>> Alan
> 
> It is used by the printing system (see core_print.clj). If I write a
> multimethod that is dispatching on type/class whatever, `type` is the
> first function I reach for.

Oh, my mistake, print-method actually re-implements `type`, with the
added restriction that is has to be a keyword.

> 
>>
>> -- 
>> 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.
> 
> 


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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.


Concurrency Threads

2016-02-12 Thread Fernando Abrao
Hello All,

I 'm doing a program that have to:
- Read a file with list of hosts ip
- Start pinging from n threads pool or whatever
- Cycle the pinging again after thread sleep
What is the best way doing it? Producer and consumer to use queue? One 
thread by ip? 
Any advice about it?

Regards,

Fernando

-- 
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: Concurrency Threads

2016-02-12 Thread Mike Sassak
Hi Fernando,

You could try agents, but I'm not sure they're a good fit for periodic
execution. I suggest looking at the scheduled Executors in
java.util.concurrent, and then using them in your Clojure code. Mixes
pretty much seamlessly with Clojure's refs and functions (indeed much of
Clojure's concurrency on the JVM is built on top of j.u.concurrent).

Mike

On Fri, Feb 12, 2016, 4:59 PM Fernando Abrao  wrote:

> Hello All,
>
> I 'm doing a program that have to:
> - Read a file with list of hosts ip
> - Start pinging from n threads pool or whatever
> - Cycle the pinging again after thread sleep
> What is the best way doing it? Producer and consumer to use queue? One
> thread by ip?
> Any advice about it?
>
> Regards,
>
> Fernando
>
> --
> 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: Chaining compojure routes

2016-02-12 Thread Gregg Reynolds
On Feb 12, 2016 4:40 PM, "JvJ"  wrote:
>
> I'm just starting to use ring/compojure to create web apps.
>
> One thing I would like to do is have an updatable collection of apps that
can be accessed based on the URL input.
>
> For example, if I have an app named "foo", then website.com/foo would
redirect to that app.
>
> So far, I have the following implementation:
>
> (def route-m
>   {"foo" (routes (GET "/foo" [] "Hello Foo!"))
>"bar" (routes
>   (GET "/bar/baz" [] "Hello Foo!")
>   (GET "/bar/quux" [] "Hello Quux!"))})
>
> (def test-r
>   (routes
>(GET "/hey"
> []
> "HEY!")
>(GET "/:app*" [app]
> (route-m app
>
>
> The issue with this method is the fact that the "sub-routes" need to have
the full path instead of just the sub-path.  For example, "foo" needs to
define its routes in terms of "foo/..." instead of just "/...".
>
> Is there any way around this?
>

core/context?

> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
"Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.