Re: foo.spec?

[Jamie English]

It's reassuring to hear there's interest! A précis sounds like a good idea. 
The API is pretty close to Clojure's right now but once the rest of the 
functionality is ported over I'll make it more Ruby-like and do a write-up. 
I'll reply here when I push a usable release.

On Thursday, 29 December 2016 19:14:49 UTC-8, Rich Morin wrote:
>
> On Thursday, December 29, 2016 at 6:24:39 PM UTC-8, Jamie English wrote:
>>
>> I've spent some time over the holidays working on a Ruby port of 
>> clojure.spec: ...
>>
>
> I'm delighted to hear this.  One of the things I've been wondering about 
> is how a Ruby API for spec would look.  Could you provide a *precis* 
> (e.g., some simple cases, annotated for noobs, in both clojure.spec and 
> speculation)?
>
> -r
>
>  
>

-- 
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: Deploying multiple Clojure apps on one server using Reagent, Nginx, and Supervisor (Solved)

[William la Forge]

>
> Seth, something seems amiss. 1,000 GB is 1,000,000 MB. At 84 mb per jar, 
>>> you can spin up 11,904 jar files. Which is worse than only being able to 
>>> run only dozens of PHP apps.
>>>
>>
--b 

-- 
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: clojure.spec bug?

[John Schmidt]

No worries! Big thanks for digging into this, I saw your update on the JIRA 
as well and it certainly seems like you've found the likely culprit.

On Monday, January 2, 2017 at 4:47:53 PM UTC+1, miner wrote:
>
>
> On Jan 1, 2017, at 7:13 PM, John Schmidt  > wrote:
>
> Steve: both ::game3 and ::game4 from your suggestions result in the same 
> error.
>
>
> Sorry for my mistaken conjecture.  My issue with the macroexpansion looks 
> like a red herring.  I guess I confused myself with quick tests in the 
> REPL. 
>
> The problem seems to be sensitive to the order of the declaration of the 
> predicates versus the protocol extension.  That is, it seems to work for me 
> if I do the extend-type Foo before defining the predicates that refer to 
> the protocol.  I probably did this accidentally while playing in the REPL. 
>
> So now I think the issue is that one version of the protocol was captured 
> by the “early" predicates, and then the protocol itself was changed so 
> references to the “old” protocol (with the same name) no longer worked.
>
> The #(…) closure seems to do the right thing as the protocol symbol 
> doesn’t get evaluated at definition time.
>
>

-- 
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: Deploying multiple Clojure apps on one server using Reagent, Nginx, and Supervisor (Solved)

[Seth Archambault]

A new issue with this. I'm running on a Ubuntu server with 1000 gigs of ram 
- this has been enough in the past for dozens of php apps - however I'm 
finding with each jar I spin up on the server, it uses ~ 84mb each. At this 
rate it will become expensive to constantly create new apps. 

PHP's memory usage seems to be dictated by traffic, not by how many 
websites you have running, is Java's memory use different?

I am using supervisor + nginx to serve the Clojure Uberjars - is there 
anything I can do to make this more efficient / not increase with each new 
site? Is there any technology I should look into, or practices I should 
implement for this?

Being able to run many websites on one server is a critical issue for me... 
Anyone have any advice? Thanks!

On Friday, December 23, 2016 at 11:56:19 AM UTC-5, Seth Archambault wrote:
>
> :-O 
> That just blew my mind - Thanks! :)
>
> On Friday, December 23, 2016 at 11:01:28 AM UTC-5, James Reeves wrote:
>>
>> I think this is something a lot of web developers take for granted, so 
>> perhaps it isn't mentioned as much as it could be.
>>
>> The usual convention in Linux environments is to set the port via the 
>> PORT environment variable. So on the command line it would be:
>>
>>   PORT=3001 java -jar yourapp.jar
>>
>> That's what this line does in your source code:
>>
>> (Integer/parseInt (or (env :port) "3000"))
>>
>> It looks for the "PORT" environment variable, and if it doesn't find it 
>> then it defaults to "3000". Then it converts the resulting string into an 
>> integer.
>>
>> You may want to take a look at the Luminus deployment guide 
>> . Luminus is a commonly 
>> used project template, but the deployment docs apply to most Clojure web 
>> projects and cover a range of setups.
>>
>> - James
>>
>>
>> On 23 December 2016 at 14:11, Seth Archambault  wrote:
>>
>>> I'm posting this because right now someone is scrounging the internet 
>>> for 3 hours to find this simple solution, I hope that they find this post 
>>> sooner rather than later, and can move on to their next project!
>>>
>>> *TLDR*
>>>
>>> Goto /src/clj/myapp/server.clj
>>>
>>> Edit "3000" to be whatever you want:
>>>
>>>  (defn -main [& args]
>>>(let [port (Integer/parseInt (or (env :port) "3000"))]
>>>  (run-jetty app {:port port :join? false})))
>>>
>>> Now Here's the journey of a new user to find this information...
>>>
>>> Let's say you installed Clojure with:
>>>
>>> lein new reagent myapp
>>>
>>> You built out your app, and everything went well! Time to deploy.
>>>
>>> You may have stumbled upon this DigitalOcean guide, How To Deploy a 
>>> Clojure Web Application on Ubuntu 14.04 
>>> 
>>>
>>> It worked mostly, though your app wants to run on port 3000, not 5000. 
>>> No problem, just changed it in the nginx config
>>>
>>> 6 server { 
>>>   7 listen 80;
>>>   8 server_name www.myapp.us myapp.us;
>>>   9 location / {
>>>  10 proxy_pass http://127.0.0.1:3000;
>>>  11 proxy_http_version 1.1;
>>>  12 proxy_set_header Connection "";
>>>  13 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>>>  14 proxy_set_header Host $http_host;
>>>  15 access_log /var/www/myapp/logs/myapp.access.log;
>>>  16 error_log /var/www/myapp/logs/myapp.error.log;
>>>  17 }
>>>  18 }
>>>
>>> The recommended /etc/supervisor/conf.d/myapp.conf file worked great. 
>>> Your site is launched and all is well!
>>>
>>> Okay so with that resounding success you decide you want to launch a 
>>> second clojure app. 
>>>
>>> First, if you're used to using php and nginx, you might be thinking you 
>>> may be able to have your app run on the default port buy "look" for another 
>>> url, maybe it's something you can easily change in the nginx config, or the 
>>> supervisor config, or maybe the project.clj file. But a search on google 
>>> seems to be focused on using separate port numbers:
>>>
>>> How can I run multiple Ring apps on the same server? 
>>> 
>>>  
>>>
>>> You don't necessarily think of your app as a "Ring" app - sure it's a 
>>> library, but isn't this just Clojure? Anyways, this seems to be the 
>>> solution, but how do we change the port? 
>>>
>>> Searching google some more:
>>>
>>> Offical Lein Ring Instructions 
>>>  - not helpful
>>> How to set ring port based on profile 
>>> 
>>>  - 
>>> something about profiles, not helpful 
>>> You browser the rest of the front page of google and continue to get 
>>> posts like this.
>>>
>>> If you come from a mainstream language like PHP, you're thinking "Hmm, 
>>> deploying multiple apps 

Re: Destructing lists using -> Difference between '(:opt1 true) and [:opt1 true]

[Nicola Mometto]

AFAIK treating kv lists as maps in destructuring was only introduced to 
support kwargs destructuring, hence why it's not supported for vectors.


On 02/01/17 18:00, Sean Corfield wrote:


This one had me scratching my head a bit too… here’s what I _/think/_ 
is going on:


First off, note that the most usual way to use the :keys destructuring 
is with a map:


(let [{:keys [opt1]}  {:opt1 true}] [opt1]) ==> [true]

As you noted, the guide explicitly calls out “lists” and in this case 
you are passing a literal list:


(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

You’d also get the same answer with:

(let [{:keys [opt1]} (list :opt1 true)] [opt1]) ==> [true]

But in this code, you have a vector, not a list:

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

If you turn your vector into a sequence, it _/does/_ work:

(let [{:keys [opt1]}  (seq [:opt1 true])] [opt1]) ==> 
[true]


So it allows lists and sequences but not vectors here.

I’d be interested to know why vector isn’t treated the same as list / 
sequence here...?


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

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

On 1/2/17, 2:41 AM, "mattias w"  on behalf of matti...@gmail.com 
> wrote:


Could someone explain why the first doesn't work and the 2nd does?

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

According to http://clojure.org/guides/destructuring

"Associative destructuring also works with lists of key-value pairs 
for keyword-arg parsing."


If I read the definition literally, I see, it says "lists" and not 
"sequences", so the behaviour is correct, so maybe a better question 
is why the definitions isn't


"Associative destructuring also works with sequences of key-value 
pairs for keyword-arg parsing."


It this specific case, when you destructor the args, it looks like a 
vector, but internally it is a list, so it works.


Happy New Year!

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Destructing lists using -> Difference between '(:opt1 true) and [:opt1 true]

[Sean Corfield]

This one had me scratching my head a bit too… here’s what I _think_ is going on:

 

First off, note that the most usual way to use the :keys destructuring is with 
a map:

 

    (let [{:keys [opt1]}  {:opt1 true}] [opt1]) ==> [true]

 

As you noted, the guide explicitly calls out “lists” and in this case you are 
passing a literal list:

 

    (let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

 

You’d also get the same answer with:

 

    (let [{:keys [opt1]} (list :opt1 true)] [opt1]) ==> [true]

 

But in this code, you have a vector, not a list:

 

    (let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

 

If you turn your vector into a sequence, it _does_ work:

    

    (let [{:keys [opt1]}  (seq [:opt1 true])] [opt1]) ==> [true]

 

So it allows lists and sequences but not vectors here. 

 

I’d be interested to know why vector isn’t treated the same as list / sequence 
here...?

 

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

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

 

On 1/2/17, 2:41 AM, "mattias w"  wrote:

 

Could someone explain why the first doesn't work and the 2nd does?

 

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

 

(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

 

According to http://clojure.org/guides/destructuring

 

"Associative destructuring also works with lists of key-value pairs for 
keyword-arg parsing."

 

If I read the definition literally, I see, it says "lists" and not "sequences", 
so the behaviour is correct, so maybe a better question is why the definitions 
isn't

 

"Associative destructuring also works with sequences of key-value pairs for 
keyword-arg parsing."

 

It this specific case, when you destructor the args, it looks like a vector, 
but internally it is a list, so it works. 

 

Happy New Year!

-- 
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: clojure.spec bug?

[Steve Miner]

> On Jan 1, 2017, at 7:13 PM, John Schmidt  wrote:
> 
> Steve: both ::game3 and ::game4 from your suggestions result in the same 
> error.
> 

Sorry for my mistaken conjecture.  My issue with the macroexpansion looks like 
a red herring.  I guess I confused myself with quick tests in the REPL. 

The problem seems to be sensitive to the order of the declaration of the 
predicates versus the protocol extension.  That is, it seems to work for me if 
I do the extend-type Foo before defining the predicates that refer to the 
protocol.  I probably did this accidentally while playing in the REPL. 

So now I think the issue is that one version of the protocol was captured by 
the “early" predicates, and then the protocol itself was changed so references 
to the “old” protocol (with the same name) no longer worked.

The #(…) closure seems to do the right thing as the protocol symbol doesn’t get 
evaluated at definition time.

-- 
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] data.xml 0.2.0-alpha1

[Herwig Hochleitner]

2017-01-02 15:29 GMT+01:00 Matching Socks :

> Whereas RFC3986 presents a bunch of options, the W3C has chosen one for
> use with XML:
>
> "Namespaces in XML 1.0 (Third Edition)", section 2.3
> https://www.w3.org/TR/REC-xml-names/#NSNameComparison
>
> 2.3 Comparing URI References
>
> URI references identifying namespaces are compared when determining
> whether a name belongs to a given namespace, and whether two names belong
> to the same namespace. [Definition: The two URIs are treated as strings,
> and they are identical if and only if the strings are identical, that is,
> if they are the same sequence of characters.  The comparison is
> case-sensitive, and no %-escaping is done or undone.
>
> It continues from there, with emphatic reinforcement of the point.
>
> OK!
>

That's about as specific of a scope as one can hope for :)
It seems, that we got namespace comparison right by chance, on the first
try, as they specify exactly our approach (dumb string comparison).

If I read that right, the only thing left to do, is to verify that our
underlying xml parser handles normalization correctly, as per
https://www.w3.org/TR/REC-xml/#AVNormalize

-- 
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] data.xml 0.2.0-alpha1

[Matching Socks]

Whereas RFC3986 presents a bunch of options, the W3C has chosen one for use 
with XML:

"Namespaces in XML 1.0 (Third Edition)", section 2.3
https://www.w3.org/TR/REC-xml-names/#NSNameComparison

2.3 Comparing URI References

URI references identifying namespaces are compared when determining whether 
a name belongs to a given namespace, and whether two names belong to the 
same namespace. [Definition: The two URIs are treated as strings, and they 
are identical if and only if the strings are identical, that is, if they 
are the same sequence of characters.  The comparison is case-sensitive, and 
no %-escaping is done or undone. 

It continues from there, with emphatic reinforcement of the point.

OK!

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

Destructing lists using -> Difference between '(:opt1 true) and [:opt1 true]

[mattias w]

Could someone explain why the first doesn't work and the 2nd does?

(let [{:keys [opt1]}  [:opt1 true]] [opt1]) ==> [nil]

(let [{:keys [opt1]} '(:opt1 true)] [opt1]) ==> [true]

According to http://clojure.org/guides/destructuring

"Associative destructuring also works with lists of key-value pairs for 
keyword-arg parsing."

If I read the definition literally, I see, it says "lists" and not 
"sequences", so the behaviour is correct, so maybe a better question is why 
the definitions isn't

"Associative destructuring also works with sequences of key-value pairs for 
keyword-arg parsing."

It this specific case, when you destructor the args, it looks like a 
vector, but internally it is a list, so it works. 

Happy New Year!

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

cljc aot compilation fails on Windows

[Torsten Uhlmann]

Hi,

I was trying to build my ClojureScript project on Windows 10 instead of 
Linux or Mac, and I run into this problem.

When running "lein uberjar" with ":aot :all"  for every cljc file I have in 
my project it reports something like:

Reloading Clojure file "\robur\middleware.cljc" failed.
java.lang.NoClassDefFoundError: \robur\middleware__init (wrong name: 
robur/middleware__init)

At first I thought that's the known problem with case insensitive file 
names, but I don't have functions that only differ in the case, and that 
error seems to indicate something's wrong with the "__init" class, which 
seems auto generated by Clojure.

Looking into my "target/classes" directory a file named "
middleware__init.class" does exist, on Windows as well as Unix. Both have 
the exact same size.

I'm using leiningen 2.7.1 and my project uses clojure 1.8.0

Did anyone run into similar problems before?

Thanks,
Torsten.

-- 
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] clj-cbor - Concise Binary Object Representation

[John Schmidt]

Looks neat! What would you say are the pros and cons of CBOR compared to 
Fressian , which seems to have similar 
goals?

On Thursday, December 29, 2016 at 5:34:36 AM UTC+1, Gregory Look wrote:
>
> mvxcvi/clj-cbor  is a native 
> Clojure implementation of the Concise Binary Object Representation 
>  format specified in RFC 7049 
> .
>
> CBOR is a binary encoding with the goal of small code size, compact 
> messages, and extensibility without the need for version negotiation. This 
> makes it a good alternative to EDN  
> for storing and transmitting Clojure data in a more compact form.
>
> I've been itching to write this library since first reading through the 
> CBOR spec, which is clear and well thought out. This is a native 
> implementation and the library has no dependencies other than Clojure 
> itself, and the current code is 100% covered by tests. I wanted to write 
> this over using one of the existing two or three libraries because they 
> were either based on Jackson, wrapped a Java lib and required interop, were 
> insufficiently flexible with adding new type extensions, or some 
> combination of the three.
>
> clj-cbor uses a read- and write-handler approach similar to the ones in 
> EDN and Transit, so type extension is simple. The library uses this same 
> mechanism to provide default support for common types like Dates, Instants, 
> Patterns, UUIDs, URIs, BigIntegers, BigDecimals, Ratios, Keywords, Symbols, 
> TaggedLiterals, and sets.
>

-- 
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: Recursive specs & forward declarations

[John Schmidt]

Ahh, thanks for the heads up!

This is the minimal failing example I could come up with extracted from a 
larger spec. In the original spec both ::a and ::b contain several other 
keys with with simple predicates like string?, pos-int? etc. FWIW, adding 
some additional keys like this to ::a and ::b in the example still results 
the same error.

On Monday, January 2, 2017 at 5:12:27 AM UTC+1, Alex Miller wrote:
>
> FYI, s/fdef takes a qualified symbol, not a keyword, and it should refer 
> to a function of the same qualified name. But you could do this instead to 
> address that:
>
> (s/def ::a-fn
>   (s/fspec
> :args (s/cat :arg ::a)
> :ret ::a))
>
> How could this even generate anything? That is, what would you expect it 
> to generate? There's no spec here that says anything about how to actually 
> create a concrete piece of data (there are no preds!). Because the maps are 
> using required keys, it has to try to create them. 
>
>
> On Sunday, January 1, 2017 at 9:04:20 PM UTC-6, John Schmidt wrote:
>>
>> I just ran in to a similar issue:
>>
>> -
>>
>> (require '[clojure.spec :as s])
>>
>> (s/def ::a (s/keys :req [::b]))
>>
>> (s/fdef ::a-fn
>>   :args (s/cat :arg ::a)
>>   :ret ::a)
>>
>> (s/def ::b (s/keys :req [::a-fn]))
>>
>> ;; All of these fail even with s/*recursion-limit* bound to 1.
>>
>> (s/exercise ::a) ;; StackOverflowError   
>> clojure.test.check.rose-tree/pure (rose_tree.cljc:-1)
>> (s/exercise ::b) ;; StackOverflowError   
>> clojure.lang.Numbers$LongOps.isPos (Numbers.java:447)
>> (s/exercise ::a-fn) ;; StackOverflowError   
>> clojure.lang.AFn.applyToHelper (AFn.java:148)
>>
>>

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