date:20170713

Re: lein autodoc failed in clojure.java.jdbc

2017-07-13 Thread Xiangtao Zhou

Thanks Alex.  so that's also the reason of  404 
of https://clojure.github.io/spec.alpha/.

Joe

On Friday, July 14, 2017 at 12:34:07 PM UTC+8, Alex Miller wrote:
>
> The Clojure team uses the latest version of autodoc (
> https://github.com/tomfaulhaber/autodoc and 
> https://github.com/tomfaulhaber/autodoc-collect are the repos). lein 
> autodoc (https://github.com/tomfaulhaber/lein-autodoc) is hard pegged to 
> autodoc 1.1.1. 
>
> The official build file for java.jdbc (and all Clojure contrib projects) 
> is the Maven pom.xml, not project.clj. Some possibilities:
>
> - The project.clj is not up to date wrt the official dependencies in the 
> pom.xml. The project.clj is there for convenience and is manually kept up 
> to date but could be out of sync.
> - The version used by lein autodoc is older and could easily be 
> encountering a bug that has been resolved already in autodoc.
> - The batch process that generates the official API docs uses autodoc and 
> autodoc-collect, but does not use leiningen or lein autodoc at all. It's 
> entirely possible something is different between those two processes.
> - Something else I haven't thought of.
>
> I don't have time to figure out what the difference is right now, but feel 
> free to dig into it more if you're interested. The exception seems to be 
> during reading, so I would try to understand more about what is being read 
> and why it's failing to read.
>
> Alex
>
>
> On Thursday, July 13, 2017 at 9:42:53 PM UTC-5, Xiangtao Zhou wrote:
>>
>> hi Sean,
>>
>> The official site of java.jdbc is generated by autodoc,  does that mean 
>> the clojure team use a different autodoc?  
>>
>> please see this.  https://clojure.github.io/java.jdbc/
>>
>> Joe 
>>
>> On Thursday, July 13, 2017 at 12:17:45 PM UTC+8, Sean Corfield wrote:
>>>
>>> Autodoc is not declared in java.jdbc’s project.clj, I’ve never run 
>>> autodoc on that project (or any other, to be honest), so I have no 
>>> expectation about which projects autodoc works on an which it doesn’t, but 
>>> *if 
>>> it can’t read valid Clojure source code, that’s a bug in autodoc as far as 
>>> I’m concerned.*
>>>
>>>  
>>>
>>> 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
>>>
>>>  
>>>
>>> *From: *Xiangtao Zhou
>>> *Sent: *Wednesday, July 12, 2017 6:50 PM
>>> *To: *Clojure
>>> *Subject: *lein autodoc failed in clojure.java.jdbc
>>>
>>>  
>>>
>>> hi clojure.java.jdbc's contributor,  
>>>
>>>  
>>>
>>> I checkout master, and run lein autodoc failed with following errors. 
>>> And there is no error for version java.jdbc-0.6.1.  Any detailed infomation 
>>> about this is appreciated.
>>>
>>>  
>>>
>>> Joe
>>>
>>>  
>>>
>>> Exception in thread "main" java.lang.RuntimeException: EOF while reading
>>>
>>> at clojure.lang.Util.runtimeException(Util.java:221)
>>>
>>> at clojure.lang.LispReader.read(LispReader.java:246)
>>>
>>> at clojure.lang.LispReader.read(LispReader.java:196)
>>>
>>> at clojure.lang.LispReader.read(LispReader.java:190)
>>>
>>> at clojure.core$read.invoke(core.clj:3640)
>>>
>>> at clojure.core$read.invoke(core.clj:3638)
>>>
>>> at clojure.core$read.invoke(core.clj:3636)
>>>
>>> at clojure.core$read.invoke(core.clj:3634)
>>>
>>> at 
>>> autodoc.collect_info_wrapper$do_collect.invoke(collect_info_wrapper.clj:95)
>>>
>>> at autodoc.autodoc$build_html.doInvoke(autodoc.clj:26)
>>>
>>> at clojure.lang.RestFn.invoke(RestFn.java:397)
>>>
>>> at clojure.lang.Var.invoke(Var.java:375)
>>>
>>> at clojure.lang.AFn.applyToHelper(AFn.java:152)
>>>
>>> at clojure.lang.Var.applyTo(Var.java:700)
>>>
>>> at clojure.core$apply.invoke(core.clj:630)
>>>
>>> at autodoc.autodoc$autodoc.doInvoke(autodoc.clj:102)
>>>
>>> at clojure.lang.RestFn.invoke(RestFn.java:425)
>>>
>>> at autodoc.autodoc$autodoc.invoke(autodoc.clj:76)
>>>
>>> at clojure.lang.AFn.applyToHelper(AFn.java:154)
>>>
>>> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>>>
>>> at clojure.core$apply.invoke(core.clj:632)
>>>
>>> at autodoc.autodoc$execute.doInvoke(autodoc.clj:116)
>>>
>>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>>
>>> at clojure.core$apply.invoke(core.clj:630)
>>>
>>> at autodoc.autodoc$_main.doInvoke(autodoc.clj:120)
>>>
>>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>>
>>> at autodoc.autodoc.main(Unknown Source)
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> -- 
>>> 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.
>>>

Re: lein autodoc failed in clojure.java.jdbc

2017-07-13 Thread Xiangtao Zhou

Thanks Sean.  Now I know I need to dig into autodoc.

On Friday, July 14, 2017 at 10:57:20 AM UTC+8, Sean Corfield wrote:
>
> I asked Alex Miller about this on Slack and he said (paraphrasing):
>
>  
>
> Something in clojure.spec broke autodoc a while back and then the split of 
> spec to spec.alpha threw a further wrench in the automated doc generation. 
> That means at least some of the API documentation has been stale for a 
> while since the doc-gen task can’t run. Right now, Alex is waiting for Tom 
> Faulhaber to find enough time to fix whatever is causing the problem.
>
>  
>
> So – the problem is autodoc doesn’t like something in clojure.spec and 
> that affects several Clojure projects (I had wondered why the clojure.spec 
> docs had seemed so out of date!). 
>
>  
>
> 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
>
>  
>
> *From: *Xiangtao Zhou 
> *Sent: *Thursday, July 13, 2017 7:43 PM
> *To: *Clojure 
> *Subject: *Re: lein autodoc failed in clojure.java.jdbc
>
>  
>
> hi Sean,
>
>  
>
> The official site of java.jdbc is generated by autodoc,  does that mean 
> the clojure team use a different autodoc?  
>
>  
>
> please see this.  https://clojure.github.io/java.jdbc/
>
>  
>
> Joe 
>
>
> On Thursday, July 13, 2017 at 12:17:45 PM UTC+8, Sean Corfield wrote:
>
> Autodoc is not declared in java.jdbc’s project.clj, I’ve never run autodoc 
> on that project (or any other, to be honest), so I have no expectation 
> about which projects autodoc works on an which it doesn’t, but *if it 
> can’t read valid Clojure source code, that’s a bug in autodoc as far as I’m 
> concerned.*
>
>  
>
> 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
>
>  
>
> *From: *Xiangtao Zhou
> *Sent: *Wednesday, July 12, 2017 6:50 PM
> *To: *Clojure
> *Subject: *lein autodoc failed in clojure.java.jdbc
>
>  
>
> hi clojure.java.jdbc's contributor,  
>
>  
>
> I checkout master, and run lein autodoc failed with following errors. And 
> there is no error for version java.jdbc-0.6.1.  Any detailed infomation 
> about this is appreciated.
>
>  
>
> Joe
>
>  
>
> Exception in thread "main" java.lang.RuntimeException: EOF while reading
>
> at clojure.lang.Util.runtimeException(Util.java:221)
>
> at clojure.lang.LispReader.read(LispReader.java:246)
>
> at clojure.lang.LispReader.read(LispReader.java:196)
>
> at clojure.lang.LispReader.read(LispReader.java:190)
>
> at clojure.core$read.invoke(core.clj:3640)
>
> at clojure.core$read.invoke(core.clj:3638)
>
> at clojure.core$read.invoke(core.clj:3636)
>
> at clojure.core$read.invoke(core.clj:3634)
>
> at 
> autodoc.collect_info_wrapper$do_collect.invoke(collect_info_wrapper.clj:95)
>
> at autodoc.autodoc$build_html.doInvoke(autodoc.clj:26)
>
> at clojure.lang.RestFn.invoke(RestFn.java:397)
>
> at clojure.lang.Var.invoke(Var.java:375)
>
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
>
> at clojure.lang.Var.applyTo(Var.java:700)
>
> at clojure.core$apply.invoke(core.clj:630)
>
> at autodoc.autodoc$autodoc.doInvoke(autodoc.clj:102)
>
> at clojure.lang.RestFn.invoke(RestFn.java:425)
>
> at autodoc.autodoc$autodoc.invoke(autodoc.clj:76)
>
> at clojure.lang.AFn.applyToHelper(AFn.java:154)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>
> at clojure.core$apply.invoke(core.clj:632)
>
> at autodoc.autodoc$execute.doInvoke(autodoc.clj:116)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>
> at clojure.core$apply.invoke(core.clj:630)
>
> at autodoc.autodoc$_main.doInvoke(autodoc.clj:120)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>
> at autodoc.autodoc.main(Unknown Source)
>
>  
>
>  
>
>  
>
> -- 
> 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 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
>

Re: lein autodoc failed in clojure.java.jdbc

2017-07-13 Thread Alex Miller

The Clojure team uses the latest version of autodoc 
(https://github.com/tomfaulhaber/autodoc 
and https://github.com/tomfaulhaber/autodoc-collect are the repos). lein 
autodoc (https://github.com/tomfaulhaber/lein-autodoc) is hard pegged to 
autodoc 1.1.1. 

The official build file for java.jdbc (and all Clojure contrib projects) is 
the Maven pom.xml, not project.clj. Some possibilities:

- The project.clj is not up to date wrt the official dependencies in the 
pom.xml. The project.clj is there for convenience and is manually kept up 
to date but could be out of sync.
- The version used by lein autodoc is older and could easily be 
encountering a bug that has been resolved already in autodoc.
- The batch process that generates the official API docs uses autodoc and 
autodoc-collect, but does not use leiningen or lein autodoc at all. It's 
entirely possible something is different between those two processes.
- Something else I haven't thought of.

I don't have time to figure out what the difference is right now, but feel 
free to dig into it more if you're interested. The exception seems to be 
during reading, so I would try to understand more about what is being read 
and why it's failing to read.

Alex


On Thursday, July 13, 2017 at 9:42:53 PM UTC-5, Xiangtao Zhou wrote:
>
> hi Sean,
>
> The official site of java.jdbc is generated by autodoc,  does that mean 
> the clojure team use a different autodoc?  
>
> please see this.  https://clojure.github.io/java.jdbc/
>
> Joe 
>
> On Thursday, July 13, 2017 at 12:17:45 PM UTC+8, Sean Corfield wrote:
>>
>> Autodoc is not declared in java.jdbc’s project.clj, I’ve never run 
>> autodoc on that project (or any other, to be honest), so I have no 
>> expectation about which projects autodoc works on an which it doesn’t, but 
>> *if 
>> it can’t read valid Clojure source code, that’s a bug in autodoc as far as 
>> I’m concerned.*
>>
>>  
>>
>> 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
>>
>>  
>>
>> *From: *Xiangtao Zhou
>> *Sent: *Wednesday, July 12, 2017 6:50 PM
>> *To: *Clojure
>> *Subject: *lein autodoc failed in clojure.java.jdbc
>>
>>  
>>
>> hi clojure.java.jdbc's contributor,  
>>
>>  
>>
>> I checkout master, and run lein autodoc failed with following errors. And 
>> there is no error for version java.jdbc-0.6.1.  Any detailed infomation 
>> about this is appreciated.
>>
>>  
>>
>> Joe
>>
>>  
>>
>> Exception in thread "main" java.lang.RuntimeException: EOF while reading
>>
>> at clojure.lang.Util.runtimeException(Util.java:221)
>>
>> at clojure.lang.LispReader.read(LispReader.java:246)
>>
>> at clojure.lang.LispReader.read(LispReader.java:196)
>>
>> at clojure.lang.LispReader.read(LispReader.java:190)
>>
>> at clojure.core$read.invoke(core.clj:3640)
>>
>> at clojure.core$read.invoke(core.clj:3638)
>>
>> at clojure.core$read.invoke(core.clj:3636)
>>
>> at clojure.core$read.invoke(core.clj:3634)
>>
>> at 
>> autodoc.collect_info_wrapper$do_collect.invoke(collect_info_wrapper.clj:95)
>>
>> at autodoc.autodoc$build_html.doInvoke(autodoc.clj:26)
>>
>> at clojure.lang.RestFn.invoke(RestFn.java:397)
>>
>> at clojure.lang.Var.invoke(Var.java:375)
>>
>> at clojure.lang.AFn.applyToHelper(AFn.java:152)
>>
>> at clojure.lang.Var.applyTo(Var.java:700)
>>
>> at clojure.core$apply.invoke(core.clj:630)
>>
>> at autodoc.autodoc$autodoc.doInvoke(autodoc.clj:102)
>>
>> at clojure.lang.RestFn.invoke(RestFn.java:425)
>>
>> at autodoc.autodoc$autodoc.invoke(autodoc.clj:76)
>>
>> at clojure.lang.AFn.applyToHelper(AFn.java:154)
>>
>> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>>
>> at clojure.core$apply.invoke(core.clj:632)
>>
>> at autodoc.autodoc$execute.doInvoke(autodoc.clj:116)
>>
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>
>> at clojure.core$apply.invoke(core.clj:630)
>>
>> at autodoc.autodoc$_main.doInvoke(autodoc.clj:120)
>>
>> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>>
>> at autodoc.autodoc.main(Unknown Source)
>>
>>  
>>
>>  
>>
>>  
>>
>> -- 
>> 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

RE: lein autodoc failed in clojure.java.jdbc

2017-07-13 Thread Sean Corfield

I asked Alex Miller about this on Slack and he said (paraphrasing):

Something in clojure.spec broke autodoc a while back and then the split of spec 
to spec.alpha threw a further wrench in the automated doc generation. That 
means at least some of the API documentation has been stale for a while since 
the doc-gen task can’t run. Right now, Alex is waiting for Tom Faulhaber to 
find enough time to fix whatever is causing the problem.

So – the problem is autodoc doesn’t like something in clojure.spec and that 
affects several Clojure projects (I had wondered why the clojure.spec docs had 
seemed so out of date!). 

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

From: Xiangtao Zhou
Sent: Thursday, July 13, 2017 7:43 PM
To: Clojure
Subject: Re: lein autodoc failed in clojure.java.jdbc

hi Sean,

The official site of java.jdbc is generated by autodoc,  does that mean the 
clojure team use a different autodoc?  

please see this.  https://clojure.github.io/java.jdbc/

Joe 

On Thursday, July 13, 2017 at 12:17:45 PM UTC+8, Sean Corfield wrote:
Autodoc is not declared in java.jdbc’s project.clj, I’ve never run autodoc on 
that project (or any other, to be honest), so I have no expectation about which 
projects autodoc works on an which it doesn’t, but if it can’t read valid 
Clojure source code, that’s a bug in autodoc as far as I’m concerned.
 
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
 
From: Xiangtao Zhou
Sent: Wednesday, July 12, 2017 6:50 PM
To: Clojure
Subject: lein autodoc failed in clojure.java.jdbc
 
hi clojure.java.jdbc's contributor,  
 
I checkout master, and run lein autodoc failed with following errors. And there 
is no error for version java.jdbc-0.6.1.  Any detailed infomation about this is 
appreciated.
 
Joe
 
Exception in thread "main" java.lang.RuntimeException: EOF while reading
at clojure.lang.Util.runtimeException(Util.java:221)
at clojure.lang.LispReader.read(LispReader.java:246)
at clojure.lang.LispReader.read(LispReader.java:196)
at clojure.lang.LispReader.read(LispReader.java:190)
at clojure.core$read.invoke(core.clj:3640)
at clojure.core$read.invoke(core.clj:3638)
at clojure.core$read.invoke(core.clj:3636)
at clojure.core$read.invoke(core.clj:3634)
at autodoc.collect_info_wrapper$do_collect.invoke(collect_info_wrapper.clj:95)
at autodoc.autodoc$build_html.doInvoke(autodoc.clj:26)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.core$apply.invoke(core.clj:630)
at autodoc.autodoc$autodoc.doInvoke(autodoc.clj:102)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at autodoc.autodoc$autodoc.invoke(autodoc.clj:76)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.core$apply.invoke(core.clj:632)
at autodoc.autodoc$execute.doInvoke(autodoc.clj:116)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:630)
at autodoc.autodoc$_main.doInvoke(autodoc.clj:120)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at autodoc.autodoc.main(Unknown Source)
 
 
 
-- 
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.

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

Re: lein autodoc failed in clojure.java.jdbc

2017-07-13 Thread Xiangtao Zhou

hi Sean,

The official site of java.jdbc is generated by autodoc,  does that mean the 
clojure team use a different autodoc?  

please see this.  https://clojure.github.io/java.jdbc/

Joe 

On Thursday, July 13, 2017 at 12:17:45 PM UTC+8, Sean Corfield wrote:
>
> Autodoc is not declared in java.jdbc’s project.clj, I’ve never run autodoc 
> on that project (or any other, to be honest), so I have no expectation 
> about which projects autodoc works on an which it doesn’t, but *if it 
> can’t read valid Clojure source code, that’s a bug in autodoc as far as I’m 
> concerned.*
>
>  
>
> 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
>
>  
>
> *From: *Xiangtao Zhou 
> *Sent: *Wednesday, July 12, 2017 6:50 PM
> *To: *Clojure 
> *Subject: *lein autodoc failed in clojure.java.jdbc
>
>  
>
> hi clojure.java.jdbc's contributor,  
>
>  
>
> I checkout master, and run lein autodoc failed with following errors. And 
> there is no error for version java.jdbc-0.6.1.  Any detailed infomation 
> about this is appreciated.
>
>  
>
> Joe
>
>  
>
> Exception in thread "main" java.lang.RuntimeException: EOF while reading
>
> at clojure.lang.Util.runtimeException(Util.java:221)
>
> at clojure.lang.LispReader.read(LispReader.java:246)
>
> at clojure.lang.LispReader.read(LispReader.java:196)
>
> at clojure.lang.LispReader.read(LispReader.java:190)
>
> at clojure.core$read.invoke(core.clj:3640)
>
> at clojure.core$read.invoke(core.clj:3638)
>
> at clojure.core$read.invoke(core.clj:3636)
>
> at clojure.core$read.invoke(core.clj:3634)
>
> at 
> autodoc.collect_info_wrapper$do_collect.invoke(collect_info_wrapper.clj:95)
>
> at autodoc.autodoc$build_html.doInvoke(autodoc.clj:26)
>
> at clojure.lang.RestFn.invoke(RestFn.java:397)
>
> at clojure.lang.Var.invoke(Var.java:375)
>
> at clojure.lang.AFn.applyToHelper(AFn.java:152)
>
> at clojure.lang.Var.applyTo(Var.java:700)
>
> at clojure.core$apply.invoke(core.clj:630)
>
> at autodoc.autodoc$autodoc.doInvoke(autodoc.clj:102)
>
> at clojure.lang.RestFn.invoke(RestFn.java:425)
>
> at autodoc.autodoc$autodoc.invoke(autodoc.clj:76)
>
> at clojure.lang.AFn.applyToHelper(AFn.java:154)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:132)
>
> at clojure.core$apply.invoke(core.clj:632)
>
> at autodoc.autodoc$execute.doInvoke(autodoc.clj:116)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>
> at clojure.core$apply.invoke(core.clj:630)
>
> at autodoc.autodoc$_main.doInvoke(autodoc.clj:120)
>
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
>
> at autodoc.autodoc.main(Unknown Source)
>
>  
>
>  
>
>  
>
> -- 
> 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.

[JOB] Wanted Clojure/Lisp Job

2017-07-13 Thread jongwon.choi

 Hi,

I am in Sydney Australia, and looking for a job.



My current interests and skills/abilities are:

   - 
   
   Design and implementation of reusable team libraries using Clojure
   - 
   
   Design and implementation of microservices with Restful API using Clojure
   - 
   
   Design and implementation of SW develop process using Git and AWS
   - 
   
   Design and implementation of CI/CD using Jenkins, Git and AWS
   - 
   
   Design and implementation of automation using various scripts and AWS
   - 
   
   Design and implementation of advanced DB schema using PostgreSQL
   - 
   
   Design and implementation of a general Machine Learning architecture 
   using R and AWS
   
Most of above points are not individual level targets, but team level 
contribution. I am kin to build an “engineering shop” not a “sweat shop”. 



The main strength of me is, of course, Lisp programming. I love to express 
my ideas in Lisp programming languages(and to make myself and other 
colleagues free from non-programming tasks, I started working on SW 
development process, CI/CD, and automation).

I am very fluent with Clojure, Common Lisp, and Scheme. I can freely 
express my ideas with these Lisp dialects. 

My programming style is “make machines repeats” rather than “punch-in 
duplication using human labors”. Therefore, my code usually does not have 
any concept level duplication as well as implementation level duplication. 



Please feel free to ask my code examples to "oz dot jongwon dot choi" at 
Google Mail.



Thanks


- Jong-won Choi

-- 
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: Trouble understanding clojure.spec.alpha/problems :path :via :in

2017-07-13 Thread Ben Brinckerhoff

> I'm currently trying something very similar to expound but with a GUI 
approach to explore errors.

I look forward to seeing what you come up with!

Ben

On Thursday, July 13, 2017 at 8:48:45 AM UTC-6, Juan Monetta wrote:
>
> Yeah, I read your expound code, really nice btw.
>
> I'm currently trying something very similar to expound but with a GUI 
> approach to explore errors.
>
> I think encoding map paths as [key pos-in-map-entry] should work in all 
> cases as is currently doing in s/map-of. I can't see any issues if s/keys 
> explains in the same way, which it currently doesn't because it just 
> reports [key].
>
> Juan
>
> El jueves, 13 de julio de 2017, 11:27:44 (UTC-3), Ben Brinckerhoff 
> escribió:
>>
>> No, you're not missing anything. I've run into the same issue. I see 
>> you've found the related JIRA issue, but for those who haven't it's 
>> https://dev.clojure.org/jira/browse/CLJ-2192
>>
>> > So the thing is that if you see a problem in [::k 1] you don't know if 
>> its the ::k value, or the value is a sequence and the problem is its 
>> element at pos 1.
>>
>> Yes, you're correct, this is ambiguous right now. In Expound (
>> https://github.com/bhb/expound) I have some code that tries to determine 
>> which case it is, based upon some heuristics, but I'm sure there are cases 
>> in which I'll get it wrong.
>>
>> There are two other interesting related cases I've run into related to 
>> the `:in` path.
>>
>> First, there is the case where the key is wrong, not the value:
>>
>>   (s/def ::spec-1 (s/map-of keyword? int?))
>>
>>   (-> (s/explain-data ::spec-1 {"foobar" 5})
>>   :clojure.spec.alpha/problems
>>   first
>>   :in)
>>   ;; ["foobar" 0]
>>
>> This is also ambiguous in the way you've noted above, but it's not clear 
>> how to construct this path - how do we "point to" a key of a map?
>>
>> Second, there is the case where we want to use 'coll-of' with a map. In 
>> this case, the `in` path is just [0]
>>
>>   (s/def ::coll-of (s/coll-of int? :kind map?))
>>   (-> (s/explain-data ::coll-of {"foobar" 5})
>>   :clojure.spec.alpha/problems
>>   first
>>   :in)
>>   ;; [0]
>>
>> AFAICT, we don't know from looking at that path whether it means: "look 
>> up the key `0` in the map" (incorrect) or "convert the map to a sequence, 
>> then get the 0th element" (correct). Again, Expound has some heuristics to 
>> try to figure this out.
>>
>> Right now, this logic is buried in the (messy) internals of Expound, but 
>> I will soon be providing a cleaner set of functions that allows clients to 
>> do more with the :clojure.spec.alpha/problems, including one that will 
>> provide a `in` path that works around these issues (in most common cases).
>>
>> Ben
>>
>> On Wednesday, July 12, 2017 at 8:50:19 AM UTC-6, Juan Monetta wrote:
>>>
>>> Hi everyone,
>>>
>>> I started exploring the clojure.spec "better user errors" thing and I'm 
>>> having some trouble matching clojure.spec.alpha/problems inside
>>> :clojure.spec.alpha/value in explain-data.
>>>
>>> I'm trying to understand if there is currently a way of using problem to 
>>> directly find the part of the value that is causing the issue independent of
>>> the spec that failed.
>>>
>>> For example given a spec :
>>>
>>> (s/def ::spec-1 (s/map-of keyword? int?))
>>>
>>> (-> (s/explain-data ::spec-1 {::k 8.8})
>>>  :clojure.spec.alpha/problems
>>>  first
>>>  :in)
>>> => [::k 1]   ;; which means the problem was with the value, not the key
>>>
>>> but given a different spec for the same data :
>>>
>>> (s/def ::k int?)
>>> (s/def ::spec-2 (s/keys :req [::k]))
>>>
>>> (-> (s/explain-data ::spec-2 {::k 8.8})
>>>  :clojure.spec.alpha/problems
>>>  first
>>>  :in)
>>> => [::k]
>>>
>>> So the thing is that if you see a problem in [::k 1] you don't know if 
>>> its the ::k value, or the value is a sequence and 
>>> the problem is its element at pos 1.
>>>
>>> Does it make sense or I'm missing something?
>>>
>>> I'm trying with [org.clojure/clojure "1.9.0-alpha17"]
>>>
>>>

-- 
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] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Yup; I'm aware. That's what tipped me off. Didn't see the comment
mentioning OWL until I'd already posted, hence the second message.

Again, intriguied to look into this further now.

On Thu, Jul 13, 2017 at 2:01 PM, ru  wrote:

> Christopher!
>
> OWL is extention of RDF.
>
> --Ru
>
> четверг, 13 июля 2017 г., 21:21:59 UTC+3 пользователь Christopher Small
> написал:
>
>> Are these ontologies as in RDF ontologies?
>>
>> On Monday, July 10, 2017 at 6:41:32 AM UTC-7, ru wrote:
>>>
>>> Hi,
>>>
>>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>>
>>> Integrated Development Environment for [rete4frames](https://github.c
>>> om/rururu/rete4frames) rule engine and expert system shell based on
>>> [Protege-3.5 ontology editor](http://protege.stanford.edu) supplemented
>>> with visual creation of algorithms. It combines two well-known paradigms of
>>> software development: algorithms for strictly defined processes and rules
>>> for fuzzy, fragmentarily defined processes and phenomenons.
>>>
>>> New feature: Algorithms.
>>>
>>> Algorithms are created using drag-and-drop of standard blocks from a
>>> palette on a canvas of a flow-chart and following connection them by stream
>>> lines. After that the standard blocks are filled with *Clojure* code as
>>> of "let" macro body.
>>> Important distinction of these algorithms from a common notion of
>>> algorithm in that they can represent *parallel processes*.
>>>
>>> Sincerely,
>>>   Ru
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/OG-kV8q9854/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: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread ru

Christopher!

OWL is extention of RDF.

--Ru

четверг, 13 июля 2017 г., 21:21:59 UTC+3 пользователь Christopher Small 
написал:
>
> Are these ontologies as in RDF ontologies?
>
> On Monday, July 10, 2017 at 6:41:32 AM UTC-7, ru wrote:
>>
>> Hi,
>>
>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>
>> Integrated Development Environment for [rete4frames](
>> https://github.com/rururu/rete4frames) rule engine and expert system 
>> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
>> supplemented with visual creation of algorithms. It combines two well-known 
>> paradigms of software development: algorithms for strictly defined 
>> processes and rules for fuzzy, fragmentarily defined processes and 
>> phenomenons.
>>
>> New feature: Algorithms.
>>
>> Algorithms are created using drag-and-drop of standard blocks from a 
>> palette on a canvas of a flow-chart and following connection them by stream 
>> lines. After that the standard blocks are filled with *Clojure* code as 
>> of "let" macro body.  
>> Important distinction of these algorithms from a common notion of 
>> algorithm in that they can represent *parallel processes*. 
>>
>> Sincerely,
>>   Ru
>>
>

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

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Hah; This answers part of my question (had a tab open, and didn't see the 
"1 new pending message"). I've been vaguely curious about this project, and 
didn't realize there was a connection ideas from RDF. I'm interested to 
learn more now.

On Thursday, July 13, 2017 at 9:45:15 AM UTC-7, ru wrote:
>
> Arthur!
>
> By the way, I must notice that Protege exists in two flavors: 
> Protege-frames and Protege-OWL. Protege-frames historically precedes 
> Protege-OWL. Protege-OWL theoretically is more powerful, but from practical 
> point of view Protege-frames has more comprehensive application area (not 
> only my opinion). So, I develop this variant of Protege.
>
> Sincerely,
>Ru
>
> среда, 12 июля 2017 г., 21:58:11 UTC+3 пользователь art...@signafire.com 
> написал:
>>
>> Hey, this is pretty neat thanks for sharing. I've had to research 
>> Ontologies for work the last few weeks, it'll help to dive into the source. 
>> Very cool.
>>
>> On Monday, July 10, 2017 at 9:41:32 AM UTC-4, ru wrote:
>>>
>>> Hi,
>>>
>>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>>
>>> Integrated Development Environment for [rete4frames](
>>> https://github.com/rururu/rete4frames) rule engine and expert system 
>>> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
>>> supplemented with visual creation of algorithms. It combines two well-known 
>>> paradigms of software development: algorithms for strictly defined 
>>> processes and rules for fuzzy, fragmentarily defined processes and 
>>> phenomenons.
>>>
>>> New feature: Algorithms.
>>>
>>> Algorithms are created using drag-and-drop of standard blocks from a 
>>> palette on a canvas of a flow-chart and following connection them by stream 
>>> lines. After that the standard blocks are filled with *Clojure* code as 
>>> of "let" macro body.  
>>> Important distinction of these algorithms from a common notion of 
>>> algorithm in that they can represent *parallel processes*. 
>>>
>>> Sincerely,
>>>   Ru
>>>
>>

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

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread Christopher Small

Are these ontologies as in RDF ontologies?

On Monday, July 10, 2017 at 6:41:32 AM UTC-7, ru wrote:
>
> Hi,
>
> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>
> Integrated Development Environment for [rete4frames](
> https://github.com/rururu/rete4frames) rule engine and expert system 
> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
> supplemented with visual creation of algorithms. It combines two well-known 
> paradigms of software development: algorithms for strictly defined 
> processes and rules for fuzzy, fragmentarily defined processes and 
> phenomenons.
>
> New feature: Algorithms.
>
> Algorithms are created using drag-and-drop of standard blocks from a 
> palette on a canvas of a flow-chart and following connection them by stream 
> lines. After that the standard blocks are filled with *Clojure* code as 
> of "let" macro body.  
> Important distinction of these algorithms from a common notion of 
> algorithm in that they can represent *parallel processes*. 
>
> Sincerely,
>   Ru
>

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

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

2017-07-13 Thread ru

Arthur!

By the way, I must notice that Protege exists in two flavors: 
Protege-frames and Protege-OWL. Protege-frames historically precedes 
Protege-OWL. Protege-OWL theoretically is more powerful, but from practical 
point of view Protege-frames has more comprehensive application area (not 
only my opinion). So, I develop this variant of Protege.

Sincerely,
   Ru

среда, 12 июля 2017 г., 21:58:11 UTC+3 пользователь art...@signafire.com 
написал:
>
> Hey, this is pretty neat thanks for sharing. I've had to research 
> Ontologies for work the last few weeks, it'll help to dive into the source. 
> Very cool.
>
> On Monday, July 10, 2017 at 9:41:32 AM UTC-4, ru wrote:
>>
>> Hi,
>>
>> Update to r4f-pro project: https://github.com/rururu/r4f-pro
>>
>> Integrated Development Environment for [rete4frames](
>> https://github.com/rururu/rete4frames) rule engine and expert system 
>> shell based on [Protege-3.5 ontology editor](http://protege.stanford.edu) 
>> supplemented with visual creation of algorithms. It combines two well-known 
>> paradigms of software development: algorithms for strictly defined 
>> processes and rules for fuzzy, fragmentarily defined processes and 
>> phenomenons.
>>
>> New feature: Algorithms.
>>
>> Algorithms are created using drag-and-drop of standard blocks from a 
>> palette on a canvas of a flow-chart and following connection them by stream 
>> lines. After that the standard blocks are filled with *Clojure* code as 
>> of "let" macro body.  
>> Important distinction of these algorithms from a common notion of 
>> algorithm in that they can represent *parallel processes*. 
>>
>> Sincerely,
>>   Ru
>>
>

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

Re: Trouble understanding clojure.spec.alpha/problems :path :via :in

2017-07-13 Thread Juan Monetta

Yeah, I read your expound code, really nice btw.

I'm currently trying something very similar to expound but with a GUI 
approach to explore errors.

I think encoding map paths as [key pos-in-map-entry] should work in all 
cases as is currently doing in s/map-of. I can't see any issues if s/keys 
explains in the same way, which it currently doesn't because it just 
reports [key].

Juan

El jueves, 13 de julio de 2017, 11:27:44 (UTC-3), Ben Brinckerhoff escribió:
>
> No, you're not missing anything. I've run into the same issue. I see 
> you've found the related JIRA issue, but for those who haven't it's 
> https://dev.clojure.org/jira/browse/CLJ-2192
>
> > So the thing is that if you see a problem in [::k 1] you don't know if 
> its the ::k value, or the value is a sequence and the problem is its 
> element at pos 1.
>
> Yes, you're correct, this is ambiguous right now. In Expound (
> https://github.com/bhb/expound) I have some code that tries to determine 
> which case it is, based upon some heuristics, but I'm sure there are cases 
> in which I'll get it wrong.
>
> There are two other interesting related cases I've run into related to the 
> `:in` path.
>
> First, there is the case where the key is wrong, not the value:
>
>   (s/def ::spec-1 (s/map-of keyword? int?))
>
>   (-> (s/explain-data ::spec-1 {"foobar" 5})
>   :clojure.spec.alpha/problems
>   first
>   :in)
>   ;; ["foobar" 0]
>
> This is also ambiguous in the way you've noted above, but it's not clear 
> how to construct this path - how do we "point to" a key of a map?
>
> Second, there is the case where we want to use 'coll-of' with a map. In 
> this case, the `in` path is just [0]
>
>   (s/def ::coll-of (s/coll-of int? :kind map?))
>   (-> (s/explain-data ::coll-of {"foobar" 5})
>   :clojure.spec.alpha/problems
>   first
>   :in)
>   ;; [0]
>
> AFAICT, we don't know from looking at that path whether it means: "look up 
> the key `0` in the map" (incorrect) or "convert the map to a sequence, then 
> get the 0th element" (correct). Again, Expound has some heuristics to try 
> to figure this out.
>
> Right now, this logic is buried in the (messy) internals of Expound, but I 
> will soon be providing a cleaner set of functions that allows clients to do 
> more with the :clojure.spec.alpha/problems, including one that will provide 
> a `in` path that works around these issues (in most common cases).
>
> Ben
>
> On Wednesday, July 12, 2017 at 8:50:19 AM UTC-6, Juan Monetta wrote:
>>
>> Hi everyone,
>>
>> I started exploring the clojure.spec "better user errors" thing and I'm 
>> having some trouble matching clojure.spec.alpha/problems inside
>> :clojure.spec.alpha/value in explain-data.
>>
>> I'm trying to understand if there is currently a way of using problem to 
>> directly find the part of the value that is causing the issue independent of
>> the spec that failed.
>>
>> For example given a spec :
>>
>> (s/def ::spec-1 (s/map-of keyword? int?))
>>
>> (-> (s/explain-data ::spec-1 {::k 8.8})
>>  :clojure.spec.alpha/problems
>>  first
>>  :in)
>> => [::k 1]   ;; which means the problem was with the value, not the key
>>
>> but given a different spec for the same data :
>>
>> (s/def ::k int?)
>> (s/def ::spec-2 (s/keys :req [::k]))
>>
>> (-> (s/explain-data ::spec-2 {::k 8.8})
>>  :clojure.spec.alpha/problems
>>  first
>>  :in)
>> => [::k]
>>
>> So the thing is that if you see a problem in [::k 1] you don't know if 
>> its the ::k value, or the value is a sequence and 
>> the problem is its element at pos 1.
>>
>> Does it make sense or I'm missing something?
>>
>> I'm trying with [org.clojure/clojure "1.9.0-alpha17"]
>>
>>

-- 
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: Trouble understanding clojure.spec.alpha/problems :path :via :in

2017-07-13 Thread Ben Brinckerhoff

No, you're not missing anything. I've run into the same issue. I see you've 
found the related JIRA issue, but for those who haven't it's 
https://dev.clojure.org/jira/browse/CLJ-2192

> So the thing is that if you see a problem in [::k 1] you don't know if 
its the ::k value, or the value is a sequence and the problem is its 
element at pos 1.

Yes, you're correct, this is ambiguous right now. In Expound 
(https://github.com/bhb/expound) I have some code that tries to determine 
which case it is, based upon some heuristics, but I'm sure there are cases 
in which I'll get it wrong.

There are two other interesting related cases I've run into related to the 
`:in` path.

First, there is the case where the key is wrong, not the value:

  (s/def ::spec-1 (s/map-of keyword? int?))

  (-> (s/explain-data ::spec-1 {"foobar" 5})
  :clojure.spec.alpha/problems
  first
  :in)
  ;; ["foobar" 0]

This is also ambiguous in the way you've noted above, but it's not clear 
how to construct this path - how do we "point to" a key of a map?

Second, there is the case where we want to use 'coll-of' with a map. In 
this case, the `in` path is just [0]

  (s/def ::coll-of (s/coll-of int? :kind map?))
  (-> (s/explain-data ::coll-of {"foobar" 5})
  :clojure.spec.alpha/problems
  first
  :in)
  ;; [0]

AFAICT, we don't know from looking at that path whether it means: "look up 
the key `0` in the map" (incorrect) or "convert the map to a sequence, then 
get the 0th element" (correct). Again, Expound has some heuristics to try 
to figure this out.

Right now, this logic is buried in the (messy) internals of Expound, but I 
will soon be providing a cleaner set of functions that allows clients to do 
more with the :clojure.spec.alpha/problems, including one that will provide 
a `in` path that works around these issues (in most common cases).

Ben

On Wednesday, July 12, 2017 at 8:50:19 AM UTC-6, Juan Monetta wrote:
>
> Hi everyone,
>
> I started exploring the clojure.spec "better user errors" thing and I'm 
> having some trouble matching clojure.spec.alpha/problems inside
> :clojure.spec.alpha/value in explain-data.
>
> I'm trying to understand if there is currently a way of using problem to 
> directly find the part of the value that is causing the issue independent of
> the spec that failed.
>
> For example given a spec :
>
> (s/def ::spec-1 (s/map-of keyword? int?))
>
> (-> (s/explain-data ::spec-1 {::k 8.8})
>  :clojure.spec.alpha/problems
>  first
>  :in)
> => [::k 1]   ;; which means the problem was with the value, not the key
>
> but given a different spec for the same data :
>
> (s/def ::k int?)
> (s/def ::spec-2 (s/keys :req [::k]))
>
> (-> (s/explain-data ::spec-2 {::k 8.8})
>  :clojure.spec.alpha/problems
>  first
>  :in)
> => [::k]
>
> So the thing is that if you see a problem in [::k 1] you don't know if its 
> the ::k value, or the value is a sequence and 
> the problem is its element at pos 1.
>
> Does it make sense or I'm missing something?
>
> I'm trying with [org.clojure/clojure "1.9.0-alpha17"]
>
>

-- 
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] Onyx 0.10 final release

2017-07-13 Thread Bruce Durling

w00t! Congrats!

cheers,
Bruce

On Wed, Jul 12, 2017 at 9:53 PM, Michael Drogalis  wrote:
> We're happy to announce the final release of Onyx 0.10. Onyx is a scalable,
> distributed, fault tolerant, high performance data processing platform for
> handling batch and streaming workloads. It's written purely in Clojure, and
> supports idiomatic Clojure programs on top of it. This version upgrades the
> internal streaming engine for significantly increased performance, adds
> support for in-order message processing, and improves support for stateful
> stream processing.
>
> Read about the release:
> http://www.onyxplatform.org/jekyll/update/2017/07/10/Onyx-Asynchronous-Barrier-Snapshotting.html
> GitHub: https://github.com/onyx-platform/onyx
> Website: http://www.onyxplatform.org
> Learn: https://github.com/onyx-platform/learn-onyx
>
> --
> 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: lein autodoc failed in clojure.java.jdbc

Re: lein autodoc failed in clojure.java.jdbc

Re: lein autodoc failed in clojure.java.jdbc

RE: lein autodoc failed in clojure.java.jdbc

Re: lein autodoc failed in clojure.java.jdbc

[JOB] Wanted Clojure/Lisp Job

Re: Trouble understanding clojure.spec.alpha/problems :path :via :in

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

Re: [ANN] r4f-pro: IDE for visual ontology-based, rule-based and algorithm-based software development

Re: Trouble understanding clojure.spec.alpha/problems :path :via :in

Re: Trouble understanding clojure.spec.alpha/problems :path :via :in

Re: [ANN] Onyx 0.10 final release

15 matches

Site Navigation

Mail list logo

Footer information