ANN: FlowStorm 2.0, a Clojure debugger

[Juan Monetta]

I'm happy to share the latest version of FlowStorm debugger.

To see a small tutorial and a demo of it being use to analyze the 
ClojureScript compiler check https://www.youtube.com/watch?v=YnpQMrkj4v8

Version 2.0 is a complete rewrite of the original FlowStorm debugger with a 
bunch of enhancements. It currently supports Clojure local debugginig, but 
ClojureScript and remote debugging are on the roadmap.

https://github.com/jpmonettas/flow-storm-debugger/

Cheers!

Juan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/4df9fc00-3b9a-4bf2-b980-a760f8afe4dfn%40googlegroups.com.

Re: How to safely print structures that may contain infinite lazy seqs?

[Juan Monetta]

Hi Austin,

Since there is no way to know the length of a lazy-seq without realizing 
it, I think your only choice is to set a limit on it by binding 
*print-length* if you are not sure about the sequence. 

Other thing you can try is bounded-count like this :

(defn looks-finite? [xs]
  (let [limit 1000]
(< (bounded-count limit xs) limit)))

(looks-finite? (map inc (range))) ;; => false
(looks-finite? (map inc (range 100))) ;; => true

I hope that helps.

Juan
El domingo, 1 de noviembre de 2020 a las 20:06:39 UTC-3, Austin Haas 
escribió:

>
> How can I make sure that a logging function won't try to realize an 
> infinite lazy seq that could be anywhere in the arguments passed to the 
> logging function?
>
> Is there some way to guarantee that lazy seqs won't be realized when 
> converting to a string?
>
> I know I can bind *print-length*, but I don't want to constrain every 
> collection.
>
> And I know that lazy seqs aren't always realized, but that doesn't seem to 
> help if they are infinite:
>
> user=> (str (map inc (range 10)))
> "clojure.lang.LazySeq@c5d38b66"
>
> user=> (str (map inc (range)))
> 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5318a41e-7353-4c81-b1d4-99a3c54e3120n%40googlegroups.com.

Re: [ANN] clindex 0.2.3 - a Clojure[Script] source file indexer

[Juan Monetta]

No idea what can be causing this. Current master has a fix for honoring 
:mvn/repos in deps.edn, maybe that fixes it?

El martes, 5 de noviembre de 2019, 11:01:59 (UTC-3), Juraj Martinka 
escribió:
>
> Btw. I've also tried it on one of our closed source projects but there 
> it's failing in clojure.tools.deps.alpha.util.maven/make-session
> *Execution error (NullPointerException) at 
> clojure.tools.deps.alpha.util.maven/make-session (maven.clj:179).*
>
>  maven.clj:  179  
> clojure.tools.deps.alpha.util.maven/make-session
>  maven.clj:  176  
> clojure.tools.deps.alpha.util.maven/make-session
>  maven.clj:   94  
> clojure.tools.deps.alpha.extensions.maven/eval19538/fn/fn
>session.clj:   23  
> clojure.tools.deps.alpha.util.session/retrieve
>session.clj:   14  
> clojure.tools.deps.alpha.util.session/retrieve
>  maven.clj:   94  
> clojure.tools.deps.alpha.extensions.maven/eval19538/fn
>   MultiFn.java:  244  clojure.lang.MultiFn/invoke
>  alpha.clj:  185  clojure.tools.deps.alpha/expand-deps/fn
>  alpha.clj:  184  clojure.tools.deps.alpha/expand-deps
>  alpha.clj:  165  clojure.tools.deps.alpha/expand-deps
>  alpha.clj:  232  clojure.tools.deps.alpha/resolve-deps
>  alpha.clj:  214  clojure.tools.deps.alpha/resolve-deps
>scanner.clj:  108  clindex.scanner/scan-all-projects
>
> This ls likely because the *(maven/make-system) *call returns nil for 
> some reason but, unfortunately, I ran out of time before I could 
> investigate this further.
>
>
> On Tuesday, 5 November 2019 14:47:32 UTC+1, Juraj Martinka wrote:
>>
>> Thanks, adding exclusions helped: 
>> https://github.com/jumarko/clojure-experiments/commit/ad069fa1cc465874dce70d36a9d4d4b9244bb47e
>> .
>>
>> However, I'm now facing another issue and that is this [I added some 
>> debug output]:
>> *  full-path:  
>> /Users/jumar/workspace/clojure/clojure-experiments/src/clojure_experiments/books/sicp/ch2_abstractions_data/s1_intro.clj*
>> *  form:  1*
>> *  Execution error (IllegalArgumentException) at 
>> clindex.scanner/read-namespace-forms$fn 
>> (form-init934221917976668977.clj:181).*
>> *  Don't know how to create ISeq from: java.lang.Long*
>>
>> It seems that it has trouble parsing standalone numbers in the middle of 
>> a clojure file like this: 
>> https://github.com/jumarko/clojure-experiments/blob/master/src/clojure_experiments/books/sicp/ch1_abstractions_procedures/exercise.clj#L191
>> Is that a known limitation? I can see that's unusual in a production 
>> codebase but I guess this is a completely valid content.
>>
>>
>> On Tuesday, 5 November 2019 12:28:08 UTC+1, Juan Monetta wrote:
>>>
>>> Thanks Juraj!
>>>
>>> If I have to guess it is probably including a different version of 
>>> tools.namespace. 
>>> I forked tools.namespace to return some extra metadata when parsing 
>>> namespace declarations.
>>> You can try to run lein deps :tree and check the only tools.namespace is 
>>> `jpmonettas/tools.namespace 0.3.2`, if you see some 
>>> `org.clojure/tools.namespace` you can add it to that project exclusions.
>>>
>>> I hope that helps!
>>>
>>> Juan
>>>
>>> El martes, 5 de noviembre de 2019, 2:43:29 (UTC-3), Juraj Martinka 
>>> escribió:
>>>>
>>>> This looks really cool!
>>>>
>>>> I'm trying this on a leiningen project (
>>>> https://github.com/jumarko/clojure-experiments/) but I'm getting a NPE:
>>>> Reflector.java:  426  
>>>> clojure.lang.Reflector/invokeNoArgInstanceMember
>>>>  utils.clj:   11  clindex.utils/normalize-path
>>>>  utils.clj:   10  clindex.utils/normalize-path
>>>> ...
>>>>   REPL:  280  
>>>> clindex.scanner/eval22432/scan-namespace-decl
>>>>scanner.clj:  354  clindex.scanner/scan-namespaces/fn
>>>>   core.clj: 2755  clojure.core/map/fn
>>>>   LazySeq.java:   42  clojure.lang.LazySeq/sval
>>>>   LazySeq.java:   51  clojure.lang.LazySeq/seq
>>>>RT.java:  535  clojure.lang.RT/seq
>>>>   core.clj:  137  clojure.core/seq
>>>>  protocols.clj:   24  clojure.core.protocols/seq-reduce
>>>>  protocols.clj:   75 

Re: [ANN] clindex 0.2.3 - a Clojure[Script] source file indexer

[Juan Monetta]

Thanks for reporting that!, it should be fixed in latest master commit. I 
tried your clojure-experiments repo and it is indexing fine now.

El martes, 5 de noviembre de 2019, 10:47:32 (UTC-3), Juraj Martinka 
escribió:
>
> Thanks, adding exclusions helped: 
> https://github.com/jumarko/clojure-experiments/commit/ad069fa1cc465874dce70d36a9d4d4b9244bb47e
> .
>
> However, I'm now facing another issue and that is this [I added some debug 
> output]:
> *  full-path:  
> /Users/jumar/workspace/clojure/clojure-experiments/src/clojure_experiments/books/sicp/ch2_abstractions_data/s1_intro.clj*
> *  form:  1*
> *  Execution error (IllegalArgumentException) at 
> clindex.scanner/read-namespace-forms$fn 
> (form-init934221917976668977.clj:181).*
> *  Don't know how to create ISeq from: java.lang.Long*
>
> It seems that it has trouble parsing standalone numbers in the middle of a 
> clojure file like this: 
> https://github.com/jumarko/clojure-experiments/blob/master/src/clojure_experiments/books/sicp/ch1_abstractions_procedures/exercise.clj#L191
> Is that a known limitation? I can see that's unusual in a production 
> codebase but I guess this is a completely valid content.
>
>
> On Tuesday, 5 November 2019 12:28:08 UTC+1, Juan Monetta wrote:
>>
>> Thanks Juraj!
>>
>> If I have to guess it is probably including a different version of 
>> tools.namespace. 
>> I forked tools.namespace to return some extra metadata when parsing 
>> namespace declarations.
>> You can try to run lein deps :tree and check the only tools.namespace is 
>> `jpmonettas/tools.namespace 0.3.2`, if you see some 
>> `org.clojure/tools.namespace` you can add it to that project exclusions.
>>
>> I hope that helps!
>>
>> Juan
>>
>> El martes, 5 de noviembre de 2019, 2:43:29 (UTC-3), Juraj Martinka 
>> escribió:
>>>
>>> This looks really cool!
>>>
>>> I'm trying this on a leiningen project (
>>> https://github.com/jumarko/clojure-experiments/) but I'm getting a NPE:
>>> Reflector.java:  426  
>>> clojure.lang.Reflector/invokeNoArgInstanceMember
>>>  utils.clj:   11  clindex.utils/normalize-path
>>>  utils.clj:   10  clindex.utils/normalize-path
>>> ...
>>>   REPL:  280  
>>> clindex.scanner/eval22432/scan-namespace-decl
>>>scanner.clj:  354  clindex.scanner/scan-namespaces/fn
>>>   core.clj: 2755  clojure.core/map/fn
>>>   LazySeq.java:   42  clojure.lang.LazySeq/sval
>>>   LazySeq.java:   51  clojure.lang.LazySeq/seq
>>>RT.java:  535  clojure.lang.RT/seq
>>>   core.clj:  137  clojure.core/seq
>>>  protocols.clj:   24  clojure.core.protocols/seq-reduce
>>>  protocols.clj:   75  clojure.core.protocols/fn
>>>  protocols.clj:   75  clojure.core.protocols/fn
>>>  protocols.clj:   13  clojure.core.protocols/fn/G
>>>   core.clj: 6828  clojure.core/reduce
>>>   core.clj: 6810  clojure.core/reduce
>>>scanner.clj:  313  clindex.scanner/merge-namespaces
>>>scanner.clj:  309  clindex.scanner/merge-namespaces
>>>scanner.clj:  358  clindex.scanner/scan-namespaces
>>>scanner.clj:  346  clindex.scanner/scan-namespaces
>>>api.clj:  142  clindex.api/index-project!
>>>    api.clj:  128  clindex.api/index-project!
>>>   REPL:   11  
>>> clojure-experiments.parsers.clindex/eval22438
>>>
>>> It looks like the `meta` on `ns-decl` returns nil here: 
>>> https://github.com/jpmonettas/clindex/blob/master/src/clindex/scanner.clj#L278
>>>
>>> Is that something that's a result of my setup (using leiningen)?
>>>
>>>
>>>
>>> On Monday, 4 November 2019 13:37:49 UTC+1, Juan Monetta wrote:
>>>>
>>>> https://github.com/jpmonettas/clindex
>>>>
>>>> Clindex is a general and extensible Clojure[Script] source file indexer.
>>>>
>>>> It scans a Clojure[Script] project together with all its dependencies 
>>>> and generates a datascript database with facts about them.
>>>>
>>>> It is intended to be used as a platform for building dev tools so they 
>>>> don't have to deal with the complexities of understanding Clojure code by 
>>>> reading the filesystem.
>>>>
&g

Re: [ANN] clindex 0.2.3 - a Clojure[Script] source file indexer

[Juan Monetta]

Thanks Juraj!

If I have to guess it is probably including a different version of 
tools.namespace. 
I forked tools.namespace to return some extra metadata when parsing 
namespace declarations.
You can try to run lein deps :tree and check the only tools.namespace is 
`jpmonettas/tools.namespace 0.3.2`, if you see some 
`org.clojure/tools.namespace` you can add it to that project exclusions.

I hope that helps!

Juan

El martes, 5 de noviembre de 2019, 2:43:29 (UTC-3), Juraj Martinka escribió:
>
> This looks really cool!
>
> I'm trying this on a leiningen project (
> https://github.com/jumarko/clojure-experiments/) but I'm getting a NPE:
> Reflector.java:  426  
> clojure.lang.Reflector/invokeNoArgInstanceMember
>  utils.clj:   11  clindex.utils/normalize-path
>  utils.clj:   10  clindex.utils/normalize-path
> ...
>   REPL:  280  
> clindex.scanner/eval22432/scan-namespace-decl
>scanner.clj:  354  clindex.scanner/scan-namespaces/fn
>   core.clj: 2755  clojure.core/map/fn
>   LazySeq.java:   42  clojure.lang.LazySeq/sval
>   LazySeq.java:   51  clojure.lang.LazySeq/seq
>RT.java:  535  clojure.lang.RT/seq
>   core.clj:  137  clojure.core/seq
>  protocols.clj:   24  clojure.core.protocols/seq-reduce
>  protocols.clj:   75  clojure.core.protocols/fn
>  protocols.clj:   75  clojure.core.protocols/fn
>  protocols.clj:   13  clojure.core.protocols/fn/G
>   core.clj: 6828  clojure.core/reduce
>   core.clj: 6810  clojure.core/reduce
>scanner.clj:  313  clindex.scanner/merge-namespaces
>scanner.clj:  309  clindex.scanner/merge-namespaces
>scanner.clj:  358  clindex.scanner/scan-namespaces
>scanner.clj:  346  clindex.scanner/scan-namespaces
>api.clj:  142  clindex.api/index-project!
>api.clj:  128  clindex.api/index-project!
>   REPL:   11  
> clojure-experiments.parsers.clindex/eval22438
>
> It looks like the `meta` on `ns-decl` returns nil here: 
> https://github.com/jpmonettas/clindex/blob/master/src/clindex/scanner.clj#L278
>
> Is that something that's a result of my setup (using leiningen)?
>
>
>
> On Monday, 4 November 2019 13:37:49 UTC+1, Juan Monetta wrote:
>>
>> https://github.com/jpmonettas/clindex
>>
>> Clindex is a general and extensible Clojure[Script] source file indexer.
>>
>> It scans a Clojure[Script] project together with all its dependencies and 
>> generates a datascript database with facts about them.
>>
>> It is intended to be used as a platform for building dev tools so they 
>> don't have to deal with the complexities of understanding Clojure code by 
>> reading the filesystem.
>>
>> Instead as an api for talking about your code it gives you a datascript 
>> db full of facts you can use together with d/q, d/pull, d/entity, etc.
>>
>> --
>> Juan Monetta
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/0a865bca-918b-4fcf-ac85-3a2aba1d97bf%40googlegroups.com.

[ANN] clindex 0.2.3 - a Clojure[Script] source file indexer

[Juan Monetta]

https://github.com/jpmonettas/clindex

Clindex is a general and extensible Clojure[Script] source file indexer.

It scans a Clojure[Script] project together with all its dependencies and 
generates a datascript database with facts about them.

It is intended to be used as a platform for building dev tools so they 
don't have to deal with the complexities of understanding Clojure code by 
reading the filesystem.

Instead as an api for talking about your code it gives you a datascript db 
full of facts you can use together with d/q, d/pull, d/entity, etc.

--
Juan Monetta

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/d8dccb88-6023-428c-ba6e-c2c59bb9eefc%40googlegroups.com.

[ANN] magic-sheet 0.1.0

[Juan Monetta]

Make all those Clojure[Script] repeating repl commands one keystroke away.
Connect to any repl server (lein repl, fighwheel nrepl so far), define some 
commands and run them with a keystroke.

Lots of times when developing or dev testing Clojure[Script] applications I 
find myself at the repl firing a bunch of commands 
only with the purpose of checking or changing the state of the app. For 
example : querying some db tables, checking the state of the cache,
checking blockchain time or account balances, restaring your components, 
incrementing time, clearing your cache, etc.

If that workflow sounds familiar, magic-sheet can help you.

https://github.com/jpmonettas/magic-sheet

Cheers!
Juan

-- 
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: Two Senior Clojure developers based in Moscow looking for the interesting challenges and possibility for remote work

[Juan Monetta]

Hi Sergey,

Can you send your CV to tal...@district0x.io? We are looking for remote 
Clojure developers.
Also you can apply 
here 
https://remoteok.io/remote-jobs/66945-remote-clojurescript-developer-district0x

Regards,
Juan

El jueves, 2 de agosto de 2018, 12:56:19 (UTC-3), Sergey Tashbayev escribió:
>
> Two Senior Clojure developers based in Moscow looking for the interesting 
> challenges and possibility for remote work for the details please contact 
> me here or on telegram @kaizenst
>

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

[ANN] clj-tree-layout

[Juan Monetta]

Hi everybody!

Maybe someone else find this useful.

clj-tree-layout  A library 
for laying out tree nodes in 2D space for Clojure and ClojureScript.

Since in Clojure we are surrounded by trees (deps, specs, namespaces, sexp, 
execution flow, etc) I think having a way to represent them graphically 
could lead to interesting tools.

Juan

-- 
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: [core.spec] Stricter map validations?

[Juan Monetta]

I added some stuff on 
https://gist.github.com/stuarthalloway/f4c4297d344651c99827769e1c3d34e9 

 that 
makes your example work I think.

We can use in Clojure and ClojureScript something like:

(defn multi-spec-sub-specs
  "Given a multi-spec form, call its multi method methods to retrieve
  its subspecs in the form of [multi-method-key sub-spec-form]."
  [multi-spec-form]
  (let [[_ multi-method-symbol & _] multi-spec-form]
(->> (resolve multi-method-symbol)
 deref
 methods 
 (map (fn [[spec-k method]]
[spec-k (s/form (method nil))])

to go down inside multi-specs.

Juan

-- 
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] expound 0.1.2

[Juan Monetta]

That was a great description Ben! So agree with everything there.

One important difference is that inspectable doesn't support clojurescript 
yet, since it's using a swing interface to draw the ui I'm trying to figure 
out the best way to support it.

My idea on inspectable is putting there a bunch of experiments on 
visualizing specs and specs fails using a GUI.I decided to try this path 
after using spec with something like a compiler and 
having a hard time inspecting spec fails when big and nested data 
structures were involved. If you want to inspect big data structures with 
context you need some kind of gui that supports collapsing etc.

I haven't tried expound yet, but for what I've seen I'll be trying it soon. 
I almost always prefer simple text interfaces since it's much easier to 
copy and paste instead of start sharing screenshots etc.

So I think if you don't need data context and exploring capabilities 
expound integrates better your repl experience since it just prints 
information in the repl instead of opening an external window,  
I'll keep doing experiments with GUIs since I think there is some value 
there.  

As Ben said inspectable also includes a spec browser. If you are a CIDER 
user, its latest release includes exactly the same functionality 
(cider-browse-spec), in which I also worked on before inspectable. 

Juan

-- 
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] inspectable 0.1.0 Improve your repl experience when usingclojure.spec

[Juan Monetta]

Hi Sean, great you like it!

Yeah, was inspired exactly by that talk!

Will keep experimenting with ideas around that.

Appreciate any suggestions, ideas, whatever.

On Tue, Jul 25, 2017 at 5:22 PM, Sean Corfield <s...@corfield.org> wrote:

> This looks very cool! A response to Stu’s recent talk about REPL-Driven
> Development and pluggable inspectors etc?
>
>
>
> 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: *Juan Monetta <jpmonet...@gmail.com>
> *Sent: *Monday, July 24, 2017 8:41 AM
> *To: *Clojure <clojure@googlegroups.com>
> *Subject: *[ANN] inspectable 0.1.0 Improve your repl experience when
> usingclojure.spec
>
>
>
> What?
>
>
>
> A couple of tools for Clojure to help you work with clojure.spec in the
> repl with the spirit of improving error
>
> messages.
>
>
>
> Where?
>
>
>
> [inspectable "0.1.0"]
>
> https://github.com/jpmonettas/inspectable
>
>
>
> Summary?
>
>
>
> Inspectable 0.1.0 contains two tools
>
>
>
> - borwse-spec : A GUI spec registry browser.
>
> - why : A GUI that explains spec fails in a bunch of different situations.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/BJvHz1XRHMU/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.

[ANN] inspectable 0.1.0 Improve your repl experience when using clojure.spec

[Juan Monetta]

What?

A couple of tools for Clojure to help you work with clojure.spec in the 
repl with the spirit of improving error
messages.

Where?

[inspectable "0.1.0"]
https://github.com/jpmonettas/inspectable

Summary?

Inspectable 0.1.0 contains two tools

- borwse-spec : A GUI spec registry browser.
- why : A GUI that explains spec fails in a bunch of different situations.

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

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

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

[Juan Monetta]

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.