How to get an error message from Elastisch?

[lawrence . krubner]

This is probably a stupid question, but is there an obvious way to get an 
error message out of Elastisch? I had an app that was working with MongoDB 
and I was then told I had to use ElasticSearch instead (something about 
only using AWS for everything) so now I'm trying to get an error message, 
because my code doesn't seem to work. I read through here without seeing 
anything obvious: 

http://clojureelasticsearch.info/articles/getting_started.htm

I rewrote my MongoDB function, so it should work with Elastisch: 

(defn push-item-to-persistence
  [item db]
  (let [
denormalized-id (get-in item [:denormalized-id] :no-id)
item (assoc item :updated-at (temporal/current-time-as-datetime))
item (assoc item :permanent-holding-id-for-item-instances 
(java.util.UUID/randomUUID))
item (assoc item :instance-id-for-this-one-item 
(java.util.UUID/randomUUID))
item (assoc item :item-type :deduplication)
]
(if (= denormalized-id :no-id)
  (slingshot/throw+ {
 :type 
::no-denormalized-id-in-push-item-into-database
 :item item
 })
  (slingshot/try+
   (put conn index mapping-type id document)
   (esd/put db "facts-over-time" "deduplicaton" (str denormalized-id) 
item)
   (println " done with put in push-item-to-persistence ")
   (catch Object o
 (slingshot/throw+ {
:type ::push-item-to-persistence
:error o
:item item
:db db
}
   ))


It doesn't seem that any documents are getting into ElasticSearch. I was 
hoping to the (throw) would reveal to me some useful debugging information, 
but that doesn't seem to happen. 

The connection appears to be valid, as I can do this:

 (let [conn (persistence/multi-thread-start config)
   res  (esd/search conn "facts-over-time" 
"deduplication" :query {:match_all {}})
   n(esrsp/total-hits res)
   hits (esrsp/hits-from res)]
   (clojure.pprint/pprint res))

and I get: 

{:took 1,
 :timed_out false,
 :_shards {:total 5, :successful 5, :failed 0},
 :hits {:total 0, :max_score nil, :hits []}}

So the connection is there. But no records are. 


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

Re: ANN: ClojureScript 1.9.946

[Nathan Fisher]

Hi David!

I'm seeing an issue in one of my larger projects. Will try to isolate
tomorrow and get back to you.

The simple project in lein-cljsbuild works fine for me with beta1 and this
release.

Saludos!
Nathan

On Tue, 3 Oct 2017 at 22:52 David Nolen  wrote:

> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "1.9.946"]
>
> This release contains many bug fixes and addresses feedback from the
> 1.9.908
> release. Important changes include parity with Clojure 1.9.0-beta1 and an
> updated Google Closure Compiler dependency. The later one in particular now
> means that ClojureScript has a dependency on JDK 8.
>
> As always feedback welcome!
>
> 1.9.946
>
> ### Changes
> * CLJS-2300: Delegate clojure.string/capitalize to goog.string/capitalize
> * CLJS-2374: Print js/Infinity, js/-Infinity, js/NaN using new reader
> literals
> * bump tools.reader (1.1.0)
> * CLJS-2372: update hash to use the new infinity literals
> * CLJS-2364: Bump Closure Compiler to the Sep 2017 version
> * CLJS-2340: Have js-keys delegate directly to good.object/getKeys
> * CLJS-2338: Support renamePrefix{Namespace} closure compiler option
>
> ### Fixes
> * CLJS-1576: fix source-map string encoding by applying encodeURIComponent
> and fixing string/replace call
> * CLJS-2294: Always use opts with implicit opts added
> * CLJS-2166: Add uri? predicate
> * CLJS-2368: Self-host: Never compile macro namespaces with
> `:optimize-constants true
> * CLJS-2367: Self-host: :def-emits-var leaks into loaded namespace
> processing
> * CLJS-2352: Emit valid JS for NaN etc. even when used w/ CLJ >=
> 1.9.0-alpha20
> * CLJS-2339: Significant code reload slowdown with :npm-deps
> * CLJS-2361: Self-host: circular dependency detection doesn't handle REPL
> self-require
> * CLJS-2356: Self-host: circular dependency detection is not correct
> * CLJS-2354: Self-host: `compile-str` doesn't handle `clojure` -> `cljs`
> aliasing
> * CLJS-2353: use portable `node-module-dep?` function in analyze-deps
> * CLJS-2345: escape paths emitted as args to cljs.core.load_file
> * CLJS-2349: Port reset-vals! and swap-vals! over from Clojure
> * CLJS-2336: Call alength once in areduce and amap
> * CLJS-2335: Avoid alength on strings
> * CLJS-2334: Also gather dependencies from foreign-libs that are modules
> * CLJS-2333: module-deps.js doesn't correctly compute `main` if aliased in
> browser field
> * CLJS-2332: module_deps.js doesn't process `export from` correctly
> * CLJS-2330: Don't set `"browser"` field for Closure if target is :nodejs
> * CLJS-2326: Indexing node_modules can't find `main` when it doesn't have
> an extension
> * CLJS-2328: Args are not provided to *main-cli-fn* with optimizations
> advanced
> * CLJS-2327: module_deps.js doesn't know about browser field advanced usage
>
> --
> 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.
>
-- 
- sent from my mobile

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

[Alan Thompson]

While it doesn't use spec, you can do this using the validate-map-keys
helper function in the Tupelo library .
It verify that a map does not contain any keys other than those you
specify.  The unit test shows it in action:

(ns tst.demo.core
  (:use demo.core tupelo.test )
  (:require
[tupelo.core :as t] ))
(t/refer-tupelo)

(dotest
  (let [map-ab   {:a 1 :b 2}
map-abc  {:a 1 :b 2 :c 3}]
(is= map-ab  (validate-map-keys map-ab [:a :b]))
(is= map-ab  (validate-map-keys map-ab [:a :b :x]))
(is= map-ab  (validate-map-keys map-ab #{:a :b}))
(is= map-ab  (validate-map-keys map-ab #{:a :b :x}))
(is= map-abc (validate-map-keys map-abc [:a :b :c :x]))

(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:a])))
(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:b])))
(is (thrown? IllegalArgumentException (validate-map-keys map-ab [:a
:x])))
(is (thrown? IllegalArgumentException (validate-map-keys map-abc [:a
:b])))
(is (thrown? IllegalArgumentException (validate-map-keys map-abc [:a :c
:x])


The API docs are hosted on Github Pages, but it seems to be down at the
moment.  You can find some older API docs (May 2017) on CrossClj:
https://crossclj.info/doc/tupelo/0.9.1/index.html

Alan





On Tue, Oct 3, 2017 at 2:37 PM, Didier  wrote:

> I'm loving Spec as an FYI, and I'll use it even if it stays as is, even in
> its alpha state it is a great tool. I also highly value the Clojure core
> value to avoid breakage, as the cost to enterprise of every migration is
> very high.
>
> I'm just wanting to give more data points to the Core team that I hope
> would be taken into consideration in the decisions of where to put the line
> on what Spec provides and doesn't.
>
> In my case, Spec has already not gone where my code base has. I'm sure
> there's use cases out there where a closed map spec would have been
> problematic, so I'm glad spec has an open map spec, but I've never had this
> problem, and I've failed to see anyone describe it to me where I felt the
> problem was real. What I do know is that I've experienced the problem of an
> open map spec that others have clearly described in this thread. When I
> need to validate for security that no extra keys were added to my maps, and
> when I want to be sure, for correctness, that my instrumentation is not
> accidentally not asserting my input because of a missing key spec, or if I
> want to be reminded that I forgot to update the spec when I extended the
> map to have additional keys, then clojure.spec falls short.
>
> I wouldn't ask of this to be taken into account by the core spec team, if
> it was easy to extend Spec to support this, but from what I could tell from
> the source, it is non trivial for me to add my own strict s/keys, and it
> doesn't seem possible to easily extend s/keys itself with more features.
> Especially if I want all the features of s/keys, except with strict key
> spec validation.
>
> I trust the core team to have good judgement, as they've shown to have
> with much of Clojure till date, but I think this is valuable data points
> for them to discuss and decide what's best. This was also part of a real
> enterprise project, that took 4 months with 5 engineers to develop. We're
> using it in production, so this is not feedback out of a toy project, or
> just experimentation.
>
> Maybe there's a better way to solve this problem then a strict spec, maybe
> we need a strict s/validate?, or some other more powerful and flexible
> construct. And maybe there are easy to extend spec for my needs, then I'd
> love to learn about those.
>
> Anyways, for the purpose of gathering data points about this use case. It
> currently seems like Me, Yury, Leon, Puzzler, and Tommi have all faced this
> issue. I've fixed it by doing my own validation on top of spec. So I only
> use spec as a data description language, and not as a validation tool. I
> use s/describe to get the keys, and then I resolve the specs, and assert
> that no more keys are on the map then what I got from s/describe. The
> downside is that I can't use instrumentation, assert, validate?, etc. So
> its hard to guarantee that the spec is always validated as my data should.
> The spec data description language is not powerful enough to be able to
> model invariants such as a closed set of keys, or keys which must have
> associated specs, unless I implement that predicate spec myself, which I
> couldn't figure out how to do.
>
> Since spec is still alpha, I think this is a great time to bring up these
> issues.
>
>
> On Tuesday, 3 October 2017 13:29:40 UTC-7, Tommi Reiman wrote:
>>
>> Open Specs seem like a good idea.
>>
>> In real life, we need to close our Data at system borders.
>>
>> With Java, there is Jackson, which fails by default on extra keys. The
>> Schema, the models are closed by default. JSON Schemas can be closed.
>>
>> Saying "use normal clojure" on 

Re: How to send a string to default system printer in Clojure

[Matching Socks]

Java says drawString while Clojure says drawstring. The compiler may be 
using introspection to find that method, and thus will not give you a 
compile-time message about the mismatch. I think you could avoid the 
introspection by using the "graphics" method argument instead of the "g2" 
variable, which isn't type hinted. Not finding .drawstring it will throw an 
exception. If AWT calls back on a thread other than your REPL thread then 
you might not notice the exception. Long story short, it can help to add 
try/catch. Then what to do in the catch? Log a message. println might or 
might not work, depending on the REPL and the threading. If println does 
not help then you can either open a file and write to it, or you might as 
well use a real logging library, e.g., clojure.tools.logging in conjunction 
with one of the Java libraries it deals with, such as Logback. Setting up 
logging in Java is tedious but very worth-while.

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

ANN: ClojureScript 1.9.946

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.946"]

This release contains many bug fixes and addresses feedback from the 1.9.908
release. Important changes include parity with Clojure 1.9.0-beta1 and an
updated Google Closure Compiler dependency. The later one in particular now
means that ClojureScript has a dependency on JDK 8.

As always feedback welcome!

1.9.946

### Changes
* CLJS-2300: Delegate clojure.string/capitalize to goog.string/capitalize
* CLJS-2374: Print js/Infinity, js/-Infinity, js/NaN using new reader
literals
* bump tools.reader (1.1.0)
* CLJS-2372: update hash to use the new infinity literals
* CLJS-2364: Bump Closure Compiler to the Sep 2017 version
* CLJS-2340: Have js-keys delegate directly to good.object/getKeys
* CLJS-2338: Support renamePrefix{Namespace} closure compiler option

### Fixes
* CLJS-1576: fix source-map string encoding by applying encodeURIComponent
and fixing string/replace call
* CLJS-2294: Always use opts with implicit opts added
* CLJS-2166: Add uri? predicate
* CLJS-2368: Self-host: Never compile macro namespaces with
`:optimize-constants true
* CLJS-2367: Self-host: :def-emits-var leaks into loaded namespace
processing
* CLJS-2352: Emit valid JS for NaN etc. even when used w/ CLJ >=
1.9.0-alpha20
* CLJS-2339: Significant code reload slowdown with :npm-deps
* CLJS-2361: Self-host: circular dependency detection doesn't handle REPL
self-require
* CLJS-2356: Self-host: circular dependency detection is not correct
* CLJS-2354: Self-host: `compile-str` doesn't handle `clojure` -> `cljs`
aliasing
* CLJS-2353: use portable `node-module-dep?` function in analyze-deps
* CLJS-2345: escape paths emitted as args to cljs.core.load_file
* CLJS-2349: Port reset-vals! and swap-vals! over from Clojure
* CLJS-2336: Call alength once in areduce and amap
* CLJS-2335: Avoid alength on strings
* CLJS-2334: Also gather dependencies from foreign-libs that are modules
* CLJS-2333: module-deps.js doesn't correctly compute `main` if aliased in
browser field
* CLJS-2332: module_deps.js doesn't process `export from` correctly
* CLJS-2330: Don't set `"browser"` field for Closure if target is :nodejs
* CLJS-2326: Indexing node_modules can't find `main` when it doesn't have
an extension
* CLJS-2328: Args are not provided to *main-cli-fn* with optimizations
advanced
* CLJS-2327: module_deps.js doesn't know about browser field advanced usage

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

[Didier]

I'm loving Spec as an FYI, and I'll use it even if it stays as is, even in 
its alpha state it is a great tool. I also highly value the Clojure core 
value to avoid breakage, as the cost to enterprise of every migration is 
very high.

I'm just wanting to give more data points to the Core team that I hope 
would be taken into consideration in the decisions of where to put the line 
on what Spec provides and doesn't.

In my case, Spec has already not gone where my code base has. I'm sure 
there's use cases out there where a closed map spec would have been 
problematic, so I'm glad spec has an open map spec, but I've never had this 
problem, and I've failed to see anyone describe it to me where I felt the 
problem was real. What I do know is that I've experienced the problem of an 
open map spec that others have clearly described in this thread. When I 
need to validate for security that no extra keys were added to my maps, and 
when I want to be sure, for correctness, that my instrumentation is not 
accidentally not asserting my input because of a missing key spec, or if I 
want to be reminded that I forgot to update the spec when I extended the 
map to have additional keys, then clojure.spec falls short.

I wouldn't ask of this to be taken into account by the core spec team, if 
it was easy to extend Spec to support this, but from what I could tell from 
the source, it is non trivial for me to add my own strict s/keys, and it 
doesn't seem possible to easily extend s/keys itself with more features. 
Especially if I want all the features of s/keys, except with strict key 
spec validation.

I trust the core team to have good judgement, as they've shown to have with 
much of Clojure till date, but I think this is valuable data points for 
them to discuss and decide what's best. This was also part of a real 
enterprise project, that took 4 months with 5 engineers to develop. We're 
using it in production, so this is not feedback out of a toy project, or 
just experimentation.

Maybe there's a better way to solve this problem then a strict spec, maybe 
we need a strict s/validate?, or some other more powerful and flexible 
construct. And maybe there are easy to extend spec for my needs, then I'd 
love to learn about those.

Anyways, for the purpose of gathering data points about this use case. It 
currently seems like Me, Yury, Leon, Puzzler, and Tommi have all faced this 
issue. I've fixed it by doing my own validation on top of spec. So I only 
use spec as a data description language, and not as a validation tool. I 
use s/describe to get the keys, and then I resolve the specs, and assert 
that no more keys are on the map then what I got from s/describe. The 
downside is that I can't use instrumentation, assert, validate?, etc. So 
its hard to guarantee that the spec is always validated as my data should. 
The spec data description language is not powerful enough to be able to 
model invariants such as a closed set of keys, or keys which must have 
associated specs, unless I implement that predicate spec myself, which I 
couldn't figure out how to do.

Since spec is still alpha, I think this is a great time to bring up these 
issues.

On Tuesday, 3 October 2017 13:29:40 UTC-7, Tommi Reiman wrote:
>
> Open Specs seem like a good idea.
>
> In real life, we need to close our Data at system borders.
>
> With Java, there is Jackson, which fails by default on extra keys. The 
> Schema, the models are closed by default. JSON Schemas can be closed.
>
> Saying "use normal clojure" on top of Spec mean double-validation, which 
> is both error-prone and boilerplate.
>
> Open/Closed is a great principle.
>
> Spec should be just more Open to allow people (or 3rd party libs) to 
> extend it to support "close my (open) specs" at runtime = coercion.
>
> If Runtime Transformations stay out of scope, It would be good to have a 
> guide on how to write Spec + (beautiful) clojure transformations for 
> web/ring apps. There might be tricks we just haven't thought of.
>
> cheers,
>
> Tommi
>
> tiistai 3. lokakuuta 2017 20.57.34 UTC+3 Alex Miller kirjoitti:
>>
>>
>>
>> On Tuesday, October 3, 2017 at 12:25:40 PM UTC-5, Didier wrote:
>>>
>>> | Spec-tools (https://github.com/metosin/spec-tools) has some tools for 
>>> this: the spec visitor (walking over all core specs, e.g. to collect all 
>>> registered specs) and map-conformers: fail-on-extra-keys and 
>>> strip-extra-keys.
>>>
>>> I understand the core team wanting to take a minimal approach to spec, 
>>> and that open is easier to restrict later. 
>>>
>>
>> It's not about easier, it's about possible. Open grows, closed breaks.
>>  
>>
>>> But I worry that already in alpha state, spec is unpractical for many 
>>> people as is
>>>
>>
>> This is demonstrably false. Many people are using it and happy with it 
>> now.
>>  
>>
>>> , and Orchestra and Spec-tools are already needed supplement. 
>>>
>>> For instrumentation, it's no big deal, but for specs I think it is. 
>>> Having a 

Re: [core.spec] Stricter map validations?

[Tommi Reiman]

Open Specs seem like a good idea.

In real life, we need to close our Data at system borders.

With Java, there is Jackson, which fails by default on extra keys. The 
Schema, the models are closed by default. JSON Schemas can be closed.

Saying "use normal clojure" on top of Spec mean double-validation, which is 
both error-prone and boilerplate.

Open/Closed is a great principle.

Spec should be just more Open to allow people (or 3rd party libs) to extend 
it to support "close my (open) specs" at runtime = coercion.

If Runtime Transformations stay out of scope, It would be good to have a 
guide on how to write Spec + (beautiful) clojure transformations for 
web/ring apps. There might be tricks we just haven't thought of.

cheers,

Tommi

tiistai 3. lokakuuta 2017 20.57.34 UTC+3 Alex Miller kirjoitti:
>
>
>
> On Tuesday, October 3, 2017 at 12:25:40 PM UTC-5, Didier wrote:
>>
>> | Spec-tools (https://github.com/metosin/spec-tools) has some tools for 
>> this: the spec visitor (walking over all core specs, e.g. to collect all 
>> registered specs) and map-conformers: fail-on-extra-keys and 
>> strip-extra-keys.
>>
>> I understand the core team wanting to take a minimal approach to spec, 
>> and that open is easier to restrict later. 
>>
>
> It's not about easier, it's about possible. Open grows, closed breaks.
>  
>
>> But I worry that already in alpha state, spec is unpractical for many 
>> people as is
>>
>
> This is demonstrably false. Many people are using it and happy with it now.
>  
>
>> , and Orchestra and Spec-tools are already needed supplement. 
>>
>> For instrumentation, it's no big deal, but for specs I think it is. 
>> Having a canonical set of specs accross Clojure shops is a way to form a 
>> common language. If I start having my custom map specs, and so does 
>> everyone, I'd be tempted to say something core is missing. Strict map specs 
>> which also vallidates each key has a registerer spec I think is a glaring 
>> omission.
>>
>
> I'm not sure how to say this other than that we are playing a longer game 
> than you, looking out into the future to other potential functionality and 
> where code bases are likely to go over time. 
>
> We have already seen a number of cases where strict map specs broke during 
> evolution both inside and outside Cognitect projects as people added keys. 
> Again, nothing prevents you from both validating your spec AND applying 
> whatever additional validation you wish to perform. But if you put the 
> strict check into the spec, you have poured concrete on the spec and it is 
> dead.
>  
>
>> Having used spec in one of my design, I've had to justify already to 6 
>> people, some being senior security engineers, why the validation allows for 
>> open keys. 
>>
>
> Those other people are right - you should check that if it's important. 
> But it doesn't have to be part of the spec. Specs should say what must be 
> true (open), not what MUSTN'T be true (closed). This is in some ways 
> another variant of the open/closed principle (the O in SOLID). 
>  
>
>> Other team members were just confused as to why that was, and the only 
>> argument I had was that Rich doesn't like to break APIs :p. 
>>
>
> This is an exceptionally good argument. Why would you dismiss it?
>  
>
>> But I've had to add validation on top to pass security audit. 
>>
>
> Good!
>  
>
>> So I think while not breaking APIs when incrementally adding specs to 
>> legacy code is a good use case, there's the security and safety use case 
>> which seems to be shared by a large swat of Clijurist, and I think spec is 
>> in need of a core support for it.
>>
>
> No, it doesn't! Spec doesn't have to do everything. We've got this whole 
> beautiful language to use.
>  
>

-- 
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: Help ship Clojure 1.9!

[Beau Fabry]

We've been using 1.9 in a small app for a while with no issues. After 
upgrading schema to the latest version (with the PR above) I've also 
successfully run our larger codebase with 1.9.

On Tuesday, October 3, 2017 at 4:41:14 AM UTC-7, stuart@gmail.com wrote:
>
> Hi Mark,
>
> I think this approach totally makes sense, and the alpha naming exists to 
> inform this kind of decision-making.
>
> For libraries where the use of spec does not have to be user-facing, I am 
> putting specs in separate (Clojure) namespaces, and loading them in such a 
> way that they can coexist with non (or maybe different) spec environments. 
> But that is extra work for sure.
>
> Stu
>
> On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg  > wrote:
>
>> On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway > > wrote:
>>
>>> Hi David,
>>>
>>> Spec will be in alpha for a while. That is part of the point of it being 
>>> a separate library. Can you say more about what problems this is causing?
>>>
>>> Stu
>>>
>>>
>> As a library maintainer, I am forced to upgrade and release my library 
>> any time something I depend upon makes a breaking change.  I don't get paid 
>> for maintaining open source libraries, it's something I do in my spare 
>> time, so I prefer to do it on my own schedule.  When an underlying library 
>> makes a breaking change, I get dozens of urgent requests from people who 
>> need me to cut a new release ASAP, and by Murphy's Law, that often happens 
>> when I have very little time to do it.  It's a nuisance.
>>
>> Clojure is pretty good about not making breaking changes, but it happens 
>> from time to time.  Clojurescript is less good about not making breaking 
>> changes, and therefore, maintaining Clojurescript libraries is more of a 
>> headache.  On the plus side, Clojurescript users seem to care very little 
>> about backwards compatibility (most keep up with the latest version), so 
>> sometimes it is easier to make a change to keep up with a change in 
>> Clojurescript than one in Clojure, where I am expected to not only support 
>> the latest breaking change, but also the last several releases.
>>
>> Anything that is labeled as "alpha" is waving a big red flag that there 
>> could be breaking changes at any time with little warning.  For my 
>> libraries which depend on spec, there's no way I'm going to bring them out 
>> of alpha status until spec comes out of alpha status.  If I make an 
>> official release of something that depends on spec, then I'm going to be on 
>> the hook to rapidly cut a new release every time spec changes, which could 
>> be at any time.  I don't want that hassle.  I don't want to make a promise 
>> to the community to maintain a stable product if the thing I depend upon 
>> has not made a similar promise.  When spec reaches a point where the API 
>> will not be changing, or rather, when we know that new changes will only be 
>> additive, I can begin to trust that it won't be a huge maintenance headache 
>> to release something based on spec.
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [core.spec] Stricter map validations?

[Alex Miller]

On Tuesday, October 3, 2017 at 12:25:40 PM UTC-5, Didier wrote:
>
> | Spec-tools (https://github.com/metosin/spec-tools) has some tools for 
> this: the spec visitor (walking over all core specs, e.g. to collect all 
> registered specs) and map-conformers: fail-on-extra-keys and 
> strip-extra-keys.
>
> I understand the core team wanting to take a minimal approach to spec, and 
> that open is easier to restrict later. 
>

It's not about easier, it's about possible. Open grows, closed breaks.
 

> But I worry that already in alpha state, spec is unpractical for many 
> people as is
>

This is demonstrably false. Many people are using it and happy with it now.
 

> , and Orchestra and Spec-tools are already needed supplement. 
>
> For instrumentation, it's no big deal, but for specs I think it is. Having 
> a canonical set of specs accross Clojure shops is a way to form a common 
> language. If I start having my custom map specs, and so does everyone, I'd 
> be tempted to say something core is missing. Strict map specs which also 
> vallidates each key has a registerer spec I think is a glaring omission.
>

I'm not sure how to say this other than that we are playing a longer game 
than you, looking out into the future to other potential functionality and 
where code bases are likely to go over time. 

We have already seen a number of cases where strict map specs broke during 
evolution both inside and outside Cognitect projects as people added keys. 
Again, nothing prevents you from both validating your spec AND applying 
whatever additional validation you wish to perform. But if you put the 
strict check into the spec, you have poured concrete on the spec and it is 
dead.
 

> Having used spec in one of my design, I've had to justify already to 6 
> people, some being senior security engineers, why the validation allows for 
> open keys. 
>

Those other people are right - you should check that if it's important. But 
it doesn't have to be part of the spec. Specs should say what must be true 
(open), not what MUSTN'T be true (closed). This is in some ways another 
variant of the open/closed principle (the O in SOLID). 
 

> Other team members were just confused as to why that was, and the only 
> argument I had was that Rich doesn't like to break APIs :p. 
>

This is an exceptionally good argument. Why would you dismiss it?
 

> But I've had to add validation on top to pass security audit. 
>

Good!
 

> So I think while not breaking APIs when incrementally adding specs to 
> legacy code is a good use case, there's the security and safety use case 
> which seems to be shared by a large swat of Clijurist, and I think spec is 
> in need of a core support for it.
>

No, it doesn't! Spec doesn't have to do everything. We've got this whole 
beautiful language to use.
 

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

[Alex Miller]

On Tuesday, October 3, 2017 at 11:48:04 AM UTC-5, Yuri Govorushchenko wrote:
>
> 3) I agree that my argumentation was vague but the sentiment still holds 
> true: I'd like to easily validate keyword args with the same level of 
> confidence as I can validate positional args. 
>

Nothing is preventing you from adding additional validation for your 
keyword args. But that doesn't have to be in spec.
 

> 1,2)
>
> > Because all map keys are independent and don't rely on each other for 
> ordering.
>
> > You can add additional checks to verify stricter things on top of open 
> specs. You can't add openness to something that is already closed.
>
> If I understand you correctly, library currently is only concerned with 
> doing simplest things and that's why `s/keys` is not very strict? But then 
> I'm not sure if it's the simplest behaviour though since `s/keys` specs 
> validate 2 things: keys AND (sometimes) values. And that "sometimes" part 
> makes production code more error-prone. 
>

No, this is not about "simple", it's about creating specs that can grow, 
rather than break. I would really urge you to watch the hour+ Spec-ulation 
keynote from Rich at last year's Conj that explains all of this. It doesn't 
make sense for me to repeat it. He explicitly cover this aspect in the talk.
 

> Is there any chance that in the future core.spec will have additional API 
> to allow specifying other levels of map validation strictness? Possible 
> options:
>

No, see above. It is possible that there will be a variant of keys that 
will tell you the parts that weren't validated or something like that.
 

>
> * Keyset validation strictness:
>   - open (current behavior, allows putting any additional keys into map)
>   - closed (map must contain only the listed keys)
>

not every going to do that for reasons above
 

> * Values validation strictness: 
>   - never validate (i.e. any values will pass, not sure about the use 
> cases though)
>

Can do this now with a `map?` or `s/map-of` spec.
 

>   - only if spec for key is registered (current behavior)
>   - always validate values (should fail if there's no spec for value 
> registered)
>
>

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

[Gary Trakhman]

I don't disagree that there might be a security use-case, and regardless of
how realistic it is businesses need people to tick boxes (that doesn't seem
like something core should worry about?), but what is the actual security
risk of an unspec'd map value, or things being referenced and unused?  The
ocaml (strict) type system allows for this for example with row polymorphic
records.

On Tue, Oct 3, 2017 at 1:25 PM Didier  wrote:

>  | Spec-tools (https://github.com/metosin/spec-tools) has some tools for
> this: the spec visitor (walking over all core specs, e.g. to collect all
> registered specs) and map-conformers: fail-on-extra-keys and
> strip-extra-keys.
>
> I understand the core team wanting to take a minimal approach to spec, and
> that open is easier to restrict later. But I worry that already in alpha
> state, spec is unpractical for many people as is, and Orchestra and
> Spec-tools are already needed supplement.
>
> For instrumentation, it's no big deal, but for specs I think it is. Having
> a canonical set of specs accross Clojure shops is a way to form a common
> language. If I start having my custom map specs, and so does everyone, I'd
> be tempted to say something core is missing. Strict map specs which also
> vallidates each key has a registerer spec I think is a glaring omission.
>
> Having used spec in one of my design, I've had to justify already to 6
> people, some being senior security engineers, why the validation allows for
> open keys. Other team members were just confused as to why that was, and
> the only argument I had was that Rich doesn't like to break APIs :p. But
> I've had to add validation on top to pass security audit. So I think while
> not breaking APIs when incrementally adding specs to legacy code is a good
> use case, there's the security and safety use case which seems to be shared
> by a large swat of Clijurist, and I think spec is in need of a core support
> for it.
>
> --
> 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: [core.spec] Stricter map validations?

[Didier]

 | Spec-tools (https://github.com/metosin/spec-tools) has some tools for this: 
the spec visitor (walking over all core specs, e.g. to collect all registered 
specs) and map-conformers: fail-on-extra-keys and strip-extra-keys.

I understand the core team wanting to take a minimal approach to spec, and that 
open is easier to restrict later. But I worry that already in alpha state, spec 
is unpractical for many people as is, and Orchestra and Spec-tools are already 
needed supplement. 

For instrumentation, it's no big deal, but for specs I think it is. Having a 
canonical set of specs accross Clojure shops is a way to form a common 
language. If I start having my custom map specs, and so does everyone, I'd be 
tempted to say something core is missing. Strict map specs which also 
vallidates each key has a registerer spec I think is a glaring omission. 

Having used spec in one of my design, I've had to justify already to 6 people, 
some being senior security engineers, why the validation allows for open keys. 
Other team members were just confused as to why that was, and the only argument 
I had was that Rich doesn't like to break APIs :p. But I've had to add 
validation on top to pass security audit. So I think while not breaking APIs 
when incrementally adding specs to legacy code is a good use case, there's the 
security and safety use case which seems to be shared by a large swat of 
Clijurist, and I think spec is in need of a core support for it.

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

[Didier]

 | I would have had to re-spec all the intermediate functions

I'm not able to follow how that is?

You would have only needed this if you are somewhere validating or have setup 
test.check to run. In both cases, if you wanted to validate, why don't you also 
want to validate this new field? Or why not test.check your code with it?

Also, if you had a keys spec for this map, it would only require you adding one 
key to that one spec. Why would all your intermediate functions not share the 
same map spec?

Anyhow, I'm not arguing against open key specs, I'm arguing for adding to spec 
a closed keys spec. Either as an option to s/keys or another spec macro. There 
clearly a large number of people who seem to have use cases for both, and 
implementing your own is non trivial, I think it would be a great addition to 
spec for practical completeness. 

-- 
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: Clojurecademy: Learning Clojure Made Easy

[Ertuğrul Çetin]

Thank you, Christopher!

I removed terms and user agreements, also changed every project's license 
under Clojurecademy to MIT, I hope it's all good now, if not I'll make it 
right until people have no concerns.

About CLJS UI, I'm also considering that thing because it might be really 
useful, Codecademy has some Javascript courses that have little Web View 
and users can manipulate Javascript/HTML code and get immediate 
effect/feedback on a Web Page, so I want to implement that. The thing is if 
project gets enough attention I will implement all those things as soon as 
possible :)

Best,

On Tuesday, October 3, 2017 at 6:48:36 PM UTC+2, Christopher Small wrote:
>
>
> Concerns over licensing and user agreements and logins aside...
>
> REALLY COOL WORK! I haven't dug deeply yet, but it seems you've built a 
> framework for building Clojure based courses here, not just a fixed set of 
> curriculum. And to this effort, bravo! I hope to see this become a very 
> useful tool for teaching Clojure, and help bring more new programmers to 
> the language.
>
> I've actually been wondering what it might be like to build something like 
> this for Cljs UI work. I know we have klipse and some related things, but 
> something that packaged that together with some real course structure would 
> be really phenomenal. Any ideas on that?
>
> With gratitude
>
> Chris
>
>
> On Monday, October 2, 2017 at 2:37:28 PM UTC-7, Ertuğrul Çetin wrote:
>>
>> Hi Bost,
>>
>> It's important for courses, I mean once your course get updated you will 
>> be notified, also you can continue to a course where you left off etc.
>> Of course this site is not the only platform that you can learn Clojure, 
>> it just has different approach. Also it is not just learning Clojure, with 
>> powerful Clojurecademy DSL(
>> https://clojurecademy.github.io/dsl-documentation/) Clojure developers 
>> can create any course they want and you can learn Algorithms & Data 
>> Structures, Data Science etc. in Clojure. It's related to content of course.
>>
>> Best,
>>
>> On Monday, October 2, 2017 at 10:30:01 PM UTC+2, Bost wrote:
>>>
>>> It looks like I can't learn clojure using your site unless I sign up 
>>> with my email and such. 
>>> Hmm... Until now I went pretty far with learning clojure without 
>>> signing up anywhere. 
>>> So what are your reasons for demanding a sign up? 
>>> Thanks. 
>>>
>>>
>>> 2017-10-02 18:47 GMT+02:00 Ertuğrul Çetin : 
>>> > Hi everyone, 
>>> > 
>>> > I've created site called Clojurecademy which seems like Codecademy for 
>>> > Clojure with powerful DSL to create courses. Feel free to provide 
>>> feedback 
>>> > so we can improve Clojure adoption together! 
>>> > 
>>> > Link: https://clojurecademy.com 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> > Groups "Clojure" group. 
>>> > To post to this group, send email to clo...@googlegroups.com 
>>> > Note that posts from new members are moderated - please be patient 
>>> with your 
>>> > first post. 
>>> > To unsubscribe from this group, send email to 
>>> > clojure+u...@googlegroups.com 
>>> > For more options, visit this group at 
>>> > http://groups.google.com/group/clojure?hl=en 
>>> > --- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups 
>>> > "Clojure" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an 
>>> > email to clojure+u...@googlegroups.com. 
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>

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

Re: Code Review -- Testing truthiness twice

[hiskennyness]

On Sunday, October 1, 2017 at 5:11:55 PM UTC-4, Scott Barrett wrote:
>
> Clojure noob, here. I'm very excited to be learning about this language 
> and becoming a part of this community :) I'm writing a function that works 
> well, but seems just a bit wrong to me, stylistically speaking. I was 
> hoping I could get some guidance from you all.
>
> Here's the code:
>
> (defn get-if
>   "Gets the value of a map if exactly one key matches a predicate, 
> otherwise nil"
>   ([m predicate?] (get-if nil m predicate?))
>   ([found m predicate?]
>(if-let [e (first m)]
>  (let [pred (predicate? (key e))]
>(if (not (and pred found))
>  (recur (if pred (val e) found) (rest m) predicate?))
>  found
>
> This has gone through a few revisions to get it as concise as possible, 
> but here are my questions/remarks:
>
>1. Is it idiomatic to use if-let to move through a collection the way 
>I have? In my experience with lispy languages, recursion over sequences 
>tend to take the form (if (null item) accumlated-value 
>(recur-over-rest)). This if-let form turns that on its head, which 
>looks a little backwards at first to me, but it saves a level of 
>indentation which is generally preferable in my experience.
>2. The main part of this code that's bugging me is the let form, which 
>is a total hack to keep from testing (predicate? (key e)) twice. Even 
>still, I have to test the truthiness of pred twice; once in the (not 
>(and ...)) form and once again in the if of the recur form. I feel 
>like a clever use of (and ...) or (or ...) would save me here, but I 
>haven't come upon a solution using those forms yet.
>
> I like to use multiple recur forms anyway to make clearer the different 
cases, and I like to use COND to flatten nested IFs:

(defn get-if
  "Gets the value of a map if exactly one key matches a predicate, otherwise 
nil"
  ([m predicate?]
   (loop [[e & rest] m
  found nil]
 (cond
   (nil? e) found
   (predicate? (key e)) (when-not found
  (recur rest (val e)))
   :default (recur rest found)


 Now you can test end-of-data up front, and by using LOOP for recursion we 
avoid a lot of noise, including repeatedly passing the predicate.

hth, hk

>
>

-- 
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: Clojurecademy: Learning Clojure Made Easy

[Christopher Small]

Concerns over licensing and user agreements and logins aside...

REALLY COOL WORK! I haven't dug deeply yet, but it seems you've built a 
framework for building Clojure based courses here, not just a fixed set of 
curriculum. And to this effort, bravo! I hope to see this become a very 
useful tool for teaching Clojure, and help bring more new programmers to 
the language.

I've actually been wondering what it might be like to build something like 
this for Cljs UI work. I know we have klipse and some related things, but 
something that packaged that together with some real course structure would 
be really phenomenal. Any ideas on that?

With gratitude

Chris


On Monday, October 2, 2017 at 2:37:28 PM UTC-7, Ertuğrul Çetin wrote:
>
> Hi Bost,
>
> It's important for courses, I mean once your course get updated you will 
> be notified, also you can continue to a course where you left off etc.
> Of course this site is not the only platform that you can learn Clojure, 
> it just has different approach. Also it is not just learning Clojure, with 
> powerful Clojurecademy DSL(
> https://clojurecademy.github.io/dsl-documentation/) Clojure developers 
> can create any course they want and you can learn Algorithms & Data 
> Structures, Data Science etc. in Clojure. It's related to content of course.
>
> Best,
>
> On Monday, October 2, 2017 at 10:30:01 PM UTC+2, Bost wrote:
>>
>> It looks like I can't learn clojure using your site unless I sign up 
>> with my email and such. 
>> Hmm... Until now I went pretty far with learning clojure without 
>> signing up anywhere. 
>> So what are your reasons for demanding a sign up? 
>> Thanks. 
>>
>>
>> 2017-10-02 18:47 GMT+02:00 Ertuğrul Çetin : 
>> > Hi everyone, 
>> > 
>> > I've created site called Clojurecademy which seems like Codecademy for 
>> > Clojure with powerful DSL to create courses. Feel free to provide 
>> feedback 
>> > so we can improve Clojure adoption together! 
>> > 
>> > Link: https://clojurecademy.com 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>> > Note that posts from new members are moderated - please be patient with 
>> your 
>> > first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@googlegroups.com 
>> > For more options, visit this group at 
>> > http://groups.google.com/group/clojure?hl=en 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "Clojure" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to clojure+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

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

Re: [core.spec] Stricter map validations?

[Yuri Govorushchenko]

3) I agree that my argumentation was vague but the sentiment still holds 
true: I'd like to easily validate keyword args with the same level of 
confidence as I can validate positional args. 

1,2)

> Because all map keys are independent and don't rely on each other for 
ordering.

> You can add additional checks to verify stricter things on top of open 
specs. You can't add openness to something that is already closed.

If I understand you correctly, library currently is only concerned with 
doing simplest things and that's why `s/keys` is not very strict? But then 
I'm not sure if it's the simplest behaviour though since `s/keys` specs 
validate 2 things: keys AND (sometimes) values. And that "sometimes" part 
makes production code more error-prone. 

Is there any chance that in the future core.spec will have additional API 
to allow specifying other levels of map validation strictness? Possible 
options:

* Keyset validation strictness:
  - open (current behavior, allows putting any additional keys into map)
  - closed (map must contain only the listed keys)
* Values validation strictness: 
  - never validate (i.e. any values will pass, not sure about the use cases 
though)
  - only if spec for key is registered (current behavior)
  - always validate values (should fail if there's no spec for value 
registered)

Thanks.

On Tuesday, October 3, 2017 at 6:43:56 PM UTC+3, Alex Miller wrote:
>
>
>
> On Tuesday, October 3, 2017 at 8:10:30 AM UTC-5, Yuri Govorushchenko wrote:
>>
>> 1) About `s/keys` silently ignoring missing value specs. My question was: 
>> "Is there any way to ensure that the keys I used in `s/keys` have the 
>> associated specs defined?."
>>
>>  Specs can be defined or added later, so there is no valid way to do this.
>>
>>
>> OK, so requiring that values are spec-ed can't be enforced at compilation 
>> time because this would make it impossible to define value specs after 
>> `s/keys`:
>>
>> ```
>> (s/def ::foo (s/keys :req [::bar]))
>> ,,,
>> (s/def ::bar ,,,)
>> ```
>>
>> This can explain why it's not built into the library. In such case I'm 
>> fine with using a custom macro instead of `s/keys` (see my gist in the 
>> previous post).
>>
>> But what about enforcing existence of value specs at runtime, during 
>> validation? `s/cat` does that, e.g.:
>>
>> ```
>> cljs.user=> (s/def ::foo (s/cat :bar ::baz))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo [123])
>> Unable to resolve spec: :cljs.user/baz
>> ```
>>
>>
> This is required because you are essentially parsing a sequential data 
> structure - one component could be a single value or many values, so you 
> must know it's definition.
>  
>
>> Why is it then not a default behaviour for `s/keys` as well? I.e.:
>>
>
> Because all map keys are independent and don't rely on each other for 
> ordering.
>  
>
>>
>> ```
>> ; current behavior
>> cljs.user=> (s/def ::foo (s/keys :req [::x]))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo {::x 123})
>> true
>>
>> ; desired behavior
>> cljs.user=> (s/def ::foo (s/keys :req [::x]))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo {::x 123})
>> Unable to resolve spec: :cljs.user/x
>> ```
>>
>> I don't think Spec-ulation Keynote addresses this behaviour.
>>
>> 2) There's no *built-in* way restrict the keyset of the map in 
>> `core.spec`.
>>
>> The reasoning for this seems to be based around the idea of backwards 
>> compatible evolving specs (see Spec-alution Keynote). But there are several 
>> good examples already covered in this thread which demonstrate that it 
>> would be very convenient to also have strict keyset validations available 
>> in `core.spec`. After all, the library is about specifying the structure of 
>> data and not only about specifying API contracts.
>>
>
> You can add additional checks to verify stricter things on top of open 
> specs. You can't add openness to something that is already closed.
>  
>
>>
>> 3) Thinking more about `s/keys` vs. `s/cat` *specifically* in the context 
>> of asserting API contracts (I'm stressing on the context here because 
>> `core.spec` is a general library and should take in account other use cases 
>> too).
>>
>> In this context it's even more apparent that `s/keys` should behave in 
>> the same way as `s/cat` because there's not much difference between 
>> positional arguments and keyword arguments. 
>>
>
> But there is - namely, the positional part. s/cat must know the spec for 
> every component to successfully conform the entire sequence. s/keys can 
> independently conform (or not conform) every key.
>  
>
>> I'll try to illustrate what I mean with an example. Let's say there's a 
>> function with positional arguments:
>>
>> ```
>> (defn foo-pos [x y z])
>>
>> ; call example:
>> (foo xxx yyy zzz)
>> ```
>>
>> I hope we can agree that it's more or less equivalent to this function 
>> with the keyword arguments where each keyword corresponds to the position 
>> number in `foo-pos`:
>>
>
> Yeah but it's NOT equivalent. s/cat allows 

Re: [core.spec] Stricter map validations?

[Yuri Govorushchenko]

Thank you, it looks handy!

On Tuesday, October 3, 2017 at 6:59:27 PM UTC+3, Tommi Reiman wrote:
>
> Hi.
>
> Spec-tools (https://github.com/metosin/spec-tools) has some tools for 
> this: the spec visitor (walking over all core specs, e.g. to collect all 
> registered specs) and map-conformers: fail-on-extra-keys and 
> strip-extra-keys. 
>
> Here's an example to strip away extra keys:
>
> (require '[clojure.spec.alpha :as s])
> (require '[spec-tools.core :as st])
>
> (s/def ::name string?)
> (s/def ::street string?)
> (s/def ::address (st/spec (s/keys :req-un [::street])))
> (s/def ::user (st/spec (s/keys :req-un [::name ::address])))
>
> (def inkeri
>   {:name "Inkeri"
>:age 102
>:address {:street "Satamakatu"
>  :city "Tampere"}})
>
> (st/select-spec ::user inkeri); {:name "Inkeri";  :address {:street 
> "Satamakatu"}}
>
>
> There is CLJ-2116 that would enable this without any wrapping of specs: 
> https://dev.clojure.org/jira/browse/CLJ-2116. Seems stalled.
>
> If runtime transformations would be supported (currently: out of scope), I 
> think we could go even further - we could rewrite conform* as walk* to 
> support all of fast coercion, explain and conform. We are using conform + 
> unform as a substitute of coercion but sadly, it's quite slow, especially 
> for maps.
>
> Tommi
>
> tiistai 3. lokakuuta 2017 16.10.30 UTC+3 Yuri Govorushchenko kirjoitti:
>>
>> 1) About `s/keys` silently ignoring missing value specs. My question was: 
>> "Is there any way to ensure that the keys I used in `s/keys` have the 
>> associated specs defined?."
>>
>>  Specs can be defined or added later, so there is no valid way to do this.
>>
>>
>> OK, so requiring that values are spec-ed can't be enforced at compilation 
>> time because this would make it impossible to define value specs after 
>> `s/keys`:
>>
>> ```
>> (s/def ::foo (s/keys :req [::bar]))
>> ,,,
>> (s/def ::bar ,,,)
>> ```
>>
>> This can explain why it's not built into the library. In such case I'm 
>> fine with using a custom macro instead of `s/keys` (see my gist in the 
>> previous post).
>>
>> But what about enforcing existence of value specs at runtime, during 
>> validation? `s/cat` does that, e.g.:
>>
>> ```
>> cljs.user=> (s/def ::foo (s/cat :bar ::baz))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo [123])
>> Unable to resolve spec: :cljs.user/baz
>> ```
>>
>> Why is it then not a default behaviour for `s/keys` as well? I.e.:
>>
>> ```
>> ; current behavior
>> cljs.user=> (s/def ::foo (s/keys :req [::x]))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo {::x 123})
>> true
>>
>> ; desired behavior
>> cljs.user=> (s/def ::foo (s/keys :req [::x]))
>> :cljs.user/foo
>> cljs.user=> (s/valid? ::foo {::x 123})
>> Unable to resolve spec: :cljs.user/x
>> ```
>>
>> I don't think Spec-ulation Keynote addresses this behaviour.
>>
>> 2) There's no *built-in* way restrict the keyset of the map in 
>> `core.spec`.
>>
>> The reasoning for this seems to be based around the idea of backwards 
>> compatible evolving specs (see Spec-alution Keynote). But there are several 
>> good examples already covered in this thread which demonstrate that it 
>> would be very convenient to also have strict keyset validations available 
>> in `core.spec`. After all, the library is about specifying the structure of 
>> data and not only about specifying API contracts.
>>
>> 3) Thinking more about `s/keys` vs. `s/cat` *specifically* in the context 
>> of asserting API contracts (I'm stressing on the context here because 
>> `core.spec` is a general library and should take in account other use cases 
>> too).
>>
>> In this context it's even more apparent that `s/keys` should behave in 
>> the same way as `s/cat` because there's not much difference between 
>> positional arguments and keyword arguments. I'll try to illustrate what I 
>> mean with an example. Let's say there's a function with positional 
>> arguments:
>>
>> ```
>> (defn foo-pos [x y z])
>>
>> ; call example:
>> (foo xxx yyy zzz)
>> ```
>>
>> I hope we can agree that it's more or less equivalent to this function 
>> with the keyword arguments where each keyword corresponds to the position 
>> number in `foo-pos`:
>>
>> ```
>> (defn foo-pos* [{x 1 y 2 z 3}])
>>
>> ; call example:
>> (foo-pos* {1 xxx 2 yyy 3 zzz})
>> ```
>>
>> And making a step further to better naming:
>>
>> ```
>> (defn foo-kw [{:keys [::x ::y ::z]}])
>>
>> ; call example:
>> (foo-kw {::x xxx ::y yyy ::z zzz})
>> ```
>>
>> So, the biggest difference is the syntax of function calls. Keyword 
>> arguments are usually more readable (esp. when there are several args) and 
>> easier to maintain (since they can be reordered at the call site and 
>> function definition safely). Let's now spec-ify the arguments using `s/cat` 
>> for positional args and `s/keys` for keyword args (as recommended in docs). 
>> These specs ensure that argument `x` is present and is of type `::x`, `y` 
>> is present and is of type `::y`, etc.:
>>
>> ```
>> 

Re: [core.spec] Stricter map validations?

[Tommi Reiman]

Hi.

Spec-tools (https://github.com/metosin/spec-tools) has some tools for this: 
the spec visitor (walking over all core specs, e.g. to collect all 
registered specs) and map-conformers: fail-on-extra-keys and 
strip-extra-keys. 

Here's an example to strip away extra keys:

(require '[clojure.spec.alpha :as s])
(require '[spec-tools.core :as st])

(s/def ::name string?)
(s/def ::street string?)
(s/def ::address (st/spec (s/keys :req-un [::street])))
(s/def ::user (st/spec (s/keys :req-un [::name ::address])))

(def inkeri
  {:name "Inkeri"
   :age 102
   :address {:street "Satamakatu"
 :city "Tampere"}})

(st/select-spec ::user inkeri); {:name "Inkeri";  :address {:street 
"Satamakatu"}}


There is CLJ-2116 that would enable this without any wrapping of specs: 
https://dev.clojure.org/jira/browse/CLJ-2116. Seems stalled.

If runtime transformations would be supported (currently: out of scope), I 
think we could go even further - we could rewrite conform* as walk* to 
support all of fast coercion, explain and conform. We are using conform + 
unform as a substitute of coercion but sadly, it's quite slow, especially 
for maps.

Tommi

tiistai 3. lokakuuta 2017 16.10.30 UTC+3 Yuri Govorushchenko kirjoitti:
>
> 1) About `s/keys` silently ignoring missing value specs. My question was: 
> "Is there any way to ensure that the keys I used in `s/keys` have the 
> associated specs defined?."
>
>  Specs can be defined or added later, so there is no valid way to do this.
>
>
> OK, so requiring that values are spec-ed can't be enforced at compilation 
> time because this would make it impossible to define value specs after 
> `s/keys`:
>
> ```
> (s/def ::foo (s/keys :req [::bar]))
> ,,,
> (s/def ::bar ,,,)
> ```
>
> This can explain why it's not built into the library. In such case I'm 
> fine with using a custom macro instead of `s/keys` (see my gist in the 
> previous post).
>
> But what about enforcing existence of value specs at runtime, during 
> validation? `s/cat` does that, e.g.:
>
> ```
> cljs.user=> (s/def ::foo (s/cat :bar ::baz))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo [123])
> Unable to resolve spec: :cljs.user/baz
> ```
>
> Why is it then not a default behaviour for `s/keys` as well? I.e.:
>
> ```
> ; current behavior
> cljs.user=> (s/def ::foo (s/keys :req [::x]))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo {::x 123})
> true
>
> ; desired behavior
> cljs.user=> (s/def ::foo (s/keys :req [::x]))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo {::x 123})
> Unable to resolve spec: :cljs.user/x
> ```
>
> I don't think Spec-ulation Keynote addresses this behaviour.
>
> 2) There's no *built-in* way restrict the keyset of the map in `core.spec`.
>
> The reasoning for this seems to be based around the idea of backwards 
> compatible evolving specs (see Spec-alution Keynote). But there are several 
> good examples already covered in this thread which demonstrate that it 
> would be very convenient to also have strict keyset validations available 
> in `core.spec`. After all, the library is about specifying the structure of 
> data and not only about specifying API contracts.
>
> 3) Thinking more about `s/keys` vs. `s/cat` *specifically* in the context 
> of asserting API contracts (I'm stressing on the context here because 
> `core.spec` is a general library and should take in account other use cases 
> too).
>
> In this context it's even more apparent that `s/keys` should behave in the 
> same way as `s/cat` because there's not much difference between positional 
> arguments and keyword arguments. I'll try to illustrate what I mean with an 
> example. Let's say there's a function with positional arguments:
>
> ```
> (defn foo-pos [x y z])
>
> ; call example:
> (foo xxx yyy zzz)
> ```
>
> I hope we can agree that it's more or less equivalent to this function 
> with the keyword arguments where each keyword corresponds to the position 
> number in `foo-pos`:
>
> ```
> (defn foo-pos* [{x 1 y 2 z 3}])
>
> ; call example:
> (foo-pos* {1 xxx 2 yyy 3 zzz})
> ```
>
> And making a step further to better naming:
>
> ```
> (defn foo-kw [{:keys [::x ::y ::z]}])
>
> ; call example:
> (foo-kw {::x xxx ::y yyy ::z zzz})
> ```
>
> So, the biggest difference is the syntax of function calls. Keyword 
> arguments are usually more readable (esp. when there are several args) and 
> easier to maintain (since they can be reordered at the call site and 
> function definition safely). Let's now spec-ify the arguments using `s/cat` 
> for positional args and `s/keys` for keyword args (as recommended in docs). 
> These specs ensure that argument `x` is present and is of type `::x`, `y` 
> is present and is of type `::y`, etc.:
>
> ```
> (s/def ::foo-pos-args (s/cat :x ::x :y ::y :z ::z))
> (s/def ::foo-kw-args (s/keys :req [::x ::y ::z]))
> ```
>
> Now (because the functions are equivalent) I'd expect their specs to 
> validate equivalent inputs in the similar way. But it's not the case if 
> developer forgets to 

Re: [core.spec] Stricter map validations?

[Alex Miller]

On Tuesday, October 3, 2017 at 8:10:30 AM UTC-5, Yuri Govorushchenko wrote:
>
> 1) About `s/keys` silently ignoring missing value specs. My question was: 
> "Is there any way to ensure that the keys I used in `s/keys` have the 
> associated specs defined?."
>
>  Specs can be defined or added later, so there is no valid way to do this.
>
>
> OK, so requiring that values are spec-ed can't be enforced at compilation 
> time because this would make it impossible to define value specs after 
> `s/keys`:
>
> ```
> (s/def ::foo (s/keys :req [::bar]))
> ,,,
> (s/def ::bar ,,,)
> ```
>
> This can explain why it's not built into the library. In such case I'm 
> fine with using a custom macro instead of `s/keys` (see my gist in the 
> previous post).
>
> But what about enforcing existence of value specs at runtime, during 
> validation? `s/cat` does that, e.g.:
>
> ```
> cljs.user=> (s/def ::foo (s/cat :bar ::baz))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo [123])
> Unable to resolve spec: :cljs.user/baz
> ```
>
>
This is required because you are essentially parsing a sequential data 
structure - one component could be a single value or many values, so you 
must know it's definition.
 

> Why is it then not a default behaviour for `s/keys` as well? I.e.:
>

Because all map keys are independent and don't rely on each other for 
ordering.
 

>
> ```
> ; current behavior
> cljs.user=> (s/def ::foo (s/keys :req [::x]))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo {::x 123})
> true
>
> ; desired behavior
> cljs.user=> (s/def ::foo (s/keys :req [::x]))
> :cljs.user/foo
> cljs.user=> (s/valid? ::foo {::x 123})
> Unable to resolve spec: :cljs.user/x
> ```
>
> I don't think Spec-ulation Keynote addresses this behaviour.
>
> 2) There's no *built-in* way restrict the keyset of the map in `core.spec`.
>
> The reasoning for this seems to be based around the idea of backwards 
> compatible evolving specs (see Spec-alution Keynote). But there are several 
> good examples already covered in this thread which demonstrate that it 
> would be very convenient to also have strict keyset validations available 
> in `core.spec`. After all, the library is about specifying the structure of 
> data and not only about specifying API contracts.
>

You can add additional checks to verify stricter things on top of open 
specs. You can't add openness to something that is already closed.
 

>
> 3) Thinking more about `s/keys` vs. `s/cat` *specifically* in the context 
> of asserting API contracts (I'm stressing on the context here because 
> `core.spec` is a general library and should take in account other use cases 
> too).
>
> In this context it's even more apparent that `s/keys` should behave in the 
> same way as `s/cat` because there's not much difference between positional 
> arguments and keyword arguments. 
>

But there is - namely, the positional part. s/cat must know the spec for 
every component to successfully conform the entire sequence. s/keys can 
independently conform (or not conform) every key.
 

> I'll try to illustrate what I mean with an example. Let's say there's a 
> function with positional arguments:
>
> ```
> (defn foo-pos [x y z])
>
> ; call example:
> (foo xxx yyy zzz)
> ```
>
> I hope we can agree that it's more or less equivalent to this function 
> with the keyword arguments where each keyword corresponds to the position 
> number in `foo-pos`:
>

Yeah but it's NOT equivalent. s/cat allows you to nest arbitrary sequential 
structure in a component. The spec for this could be:

(s/def ::last-args (s/cat :y any? :z any?))
(s/fdef foo :args (s/cat :x any? :last ::last-args))

Without knowing the structure of ::last-args, s/cat can't validate the 
input.

Not going to respond to the rest of this post, as it uses this false 
argument of equivalence.

 

>
> ```
> (defn foo-pos* [{x 1 y 2 z 3}])
>
> ; call example:
> (foo-pos* {1 xxx 2 yyy 3 zzz})
> ```
>
> And making a step further to better naming:
>
> ```
> (defn foo-kw [{:keys [::x ::y ::z]}])
>
> ; call example:
> (foo-kw {::x xxx ::y yyy ::z zzz})
> ```
>
> So, the biggest difference is the syntax of function calls. Keyword 
> arguments are usually more readable (esp. when there are several args) and 
> easier to maintain (since they can be reordered at the call site and 
> function definition safely). Let's now spec-ify the arguments using `s/cat` 
> for positional args and `s/keys` for keyword args (as recommended in docs). 
> These specs ensure that argument `x` is present and is of type `::x`, `y` 
> is present and is of type `::y`, etc.:
>
> ```
> (s/def ::foo-pos-args (s/cat :x ::x :y ::y :z ::z))
> (s/def ::foo-kw-args (s/keys :req [::x ::y ::z]))
> ```
>
> Now (because the functions are equivalent) I'd expect their specs to 
> validate equivalent inputs in the similar way. But it's not the case if 
> developer forgets to define the `::y` spec!
>
> ```
> ; ::y spec is missing
> (s/def ::x int?)
> (s/def ::z int?)
>
> ; positional args
> (def pos-inputs 

How to send a string to default system printer in Clojure

[Darnaroth Darnarowth]

Hello all I am trying to print a string to my printer. I know that if I 
want to do that from Clojure I need to use Java Interop, specifically the 
Printable interface and the classes Graphics/Graphics2D and PrinterJob,
but I have trouble to convert the equivelant Java code to Clojure. The java 
code and my attempt to Clojure are bellow. I have just started  Clojure and 
I would be grateful if anyone can explain.

//Java/

import java.awt.*;import java.awt.print.*;
public class foo implements Printable {
  private static Font sFont = new Font("Serif", Font.PLAIN , 64);

  public int print(Graphics g, PageFormat Pf, int pageIndex)
  throws PrinterException {
if (pageIndex > 0) return NO_SUCH_PAGE;
Graphics2D g2 = (Graphics2D)g;
g2.setFont(sFont);
g2.setPaint(Color.black);
g2.drawString("Save a tree!", 96, 144);
return PAGE_EXISTS;
  }

  public static void main(String[] args) {
PrinterJob job = PrinterJob.getPrinterJob( );
job.setPrintable(new foo( ));
if (job.printDialog( )) {
  try {
job.print( );
  }
  catch (PrinterException e) {}
}
System.exit(0);
  }}

;Clojure;;;

(ns controller.core

  (:gen-class)
  (:require [clj-http.client :as client]
[cheshire.core :refer :all]
[clojure.edn :as edn]
[clojure.java.io :as io]
[clojure.string :as str])
  (:import [java.awt.print PrinterJob Printable PrinterException]
   [java.awt Graphics]  
   )
  )
(defn make-page []
  (proxy [Printable] []
(print
  [graphics page-format page-index]
  (if (> page-index 0)
Printable/NO_SUCH_PAGE
(let [g2 graphics]
  (.drawstring g2 ("f" 96 144))
  Printable/PAGE_EXISTS

  ))
  )

(defn prnt []
  (let [print-j (PrinterJob/getPrinterJob)]
(.setPrintable print-j (make-page))
(.print print-j)))

(defn -main
  [& args]
  (prnt)
  )

-- 
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: Clojurecademy: Learning Clojure Made Easy

[Ertuğrul Çetin]

I removed Terms of Service from the site, also all Clojurecademy projects 
have MIT license(https://github.com/clojurecademy) and Clojurecademy Web 
App is going to be an open source project in near future. I hope everything 
is fine now, if not please let me know I'll do adjusments

Thank you...

On Tuesday, October 3, 2017 at 5:03:12 AM UTC+2, Sam Griffith wrote:
>
> Terms of service prevent me from helping. I'm not willing to write things 
> for the site and then have you own them like it says. That said, good luck. 
> It does look guise nice from looking at your GitHub.
>
> Sam
>

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

[Yuri Govorushchenko]

1) About `s/keys` silently ignoring missing value specs. My question was: 
"Is there any way to ensure that the keys I used in `s/keys` have the 
associated specs defined?."

 Specs can be defined or added later, so there is no valid way to do this.


OK, so requiring that values are spec-ed can't be enforced at compilation 
time because this would make it impossible to define value specs after 
`s/keys`:

```
(s/def ::foo (s/keys :req [::bar]))
,,,
(s/def ::bar ,,,)
```

This can explain why it's not built into the library. In such case I'm fine 
with using a custom macro instead of `s/keys` (see my gist in the previous 
post).

But what about enforcing existence of value specs at runtime, during 
validation? `s/cat` does that, e.g.:

```
cljs.user=> (s/def ::foo (s/cat :bar ::baz))
:cljs.user/foo
cljs.user=> (s/valid? ::foo [123])
Unable to resolve spec: :cljs.user/baz
```

Why is it then not a default behaviour for `s/keys` as well? I.e.:

```
; current behavior
cljs.user=> (s/def ::foo (s/keys :req [::x]))
:cljs.user/foo
cljs.user=> (s/valid? ::foo {::x 123})
true

; desired behavior
cljs.user=> (s/def ::foo (s/keys :req [::x]))
:cljs.user/foo
cljs.user=> (s/valid? ::foo {::x 123})
Unable to resolve spec: :cljs.user/x
```

I don't think Spec-ulation Keynote addresses this behaviour.

2) There's no *built-in* way restrict the keyset of the map in `core.spec`.

The reasoning for this seems to be based around the idea of backwards 
compatible evolving specs (see Spec-alution Keynote). But there are several 
good examples already covered in this thread which demonstrate that it 
would be very convenient to also have strict keyset validations available 
in `core.spec`. After all, the library is about specifying the structure of 
data and not only about specifying API contracts.

3) Thinking more about `s/keys` vs. `s/cat` *specifically* in the context 
of asserting API contracts (I'm stressing on the context here because 
`core.spec` is a general library and should take in account other use cases 
too).

In this context it's even more apparent that `s/keys` should behave in the 
same way as `s/cat` because there's not much difference between positional 
arguments and keyword arguments. I'll try to illustrate what I mean with an 
example. Let's say there's a function with positional arguments:

```
(defn foo-pos [x y z])

; call example:
(foo xxx yyy zzz)
```

I hope we can agree that it's more or less equivalent to this function with 
the keyword arguments where each keyword corresponds to the position number 
in `foo-pos`:

```
(defn foo-pos* [{x 1 y 2 z 3}])

; call example:
(foo-pos* {1 xxx 2 yyy 3 zzz})
```

And making a step further to better naming:

```
(defn foo-kw [{:keys [::x ::y ::z]}])

; call example:
(foo-kw {::x xxx ::y yyy ::z zzz})
```

So, the biggest difference is the syntax of function calls. Keyword 
arguments are usually more readable (esp. when there are several args) and 
easier to maintain (since they can be reordered at the call site and 
function definition safely). Let's now spec-ify the arguments using `s/cat` 
for positional args and `s/keys` for keyword args (as recommended in docs). 
These specs ensure that argument `x` is present and is of type `::x`, `y` 
is present and is of type `::y`, etc.:

```
(s/def ::foo-pos-args (s/cat :x ::x :y ::y :z ::z))
(s/def ::foo-kw-args (s/keys :req [::x ::y ::z]))
```

Now (because the functions are equivalent) I'd expect their specs to 
validate equivalent inputs in the similar way. But it's not the case if 
developer forgets to define the `::y` spec!

```
; ::y spec is missing
(s/def ::x int?)
(s/def ::z int?)

; positional args
(def pos-inputs [1 2 3])
(s/valid? ::foo-pos-args pos-inputs) ; => Unable to resolve spec: 
:cljs.user/y (good)

; keyword args
(def kw-inputs {::x 1 ::y 2 ::z 3})
(s/valid? ::foo-kw-args kw-inputs) ; => true (ouch!)
```

TL/DR: (specifically in the context of function contracts) `core.spec` 
shouldn't treat APIs with positional arguments and APIs with keyword 
arguments differently and thus `s/keys` should check arg values at keys in 
the same way `s/cat` checks arg values at positions.

On Tuesday, October 3, 2017 at 6:01:06 AM UTC+3, Alex Miller wrote:
>
>
>
> On Monday, October 2, 2017 at 10:37:31 AM UTC-5, Yuri Govorushchenko wrote:
>>
>> Hi!
>>
>> I have some noobie questions for which I couldn't google the compelling 
>> answers.
>>
>> 1) Is there any way to ensure that the keys I used in `s/keys` have the 
>> associated specs defined? 
>>
>
> Specs can be defined or added later, so there is no valid way to do this.
>  
>
>> At compile time or at least at runtime. Maybe via an additional library? 
>> I could imagine a macro (smt. like `s/keys-strict` or `s/map-pairs`, as 
>> maps can also be viewed as sets of spec'ed pairs) which additionally checks 
>> that all keys have specs registered. I'm OK with sacrificing some 
>> flexibility (e.g. being able to define key specs after map specs, 
>> dynamically, 

Re: Clojurecademy: Learning Clojure Made Easy

[Ertuğrul Çetin]

My goal is not earning money, this platform will remain free actually and 
be an open source project when I'm done with unit testing and 
documentation, my goal is making Clojure adoption as much easy as possible. 
I'll update Terms and consider your suggestion.

On Tuesday, October 3, 2017 at 1:31:04 PM UTC+2, Bost wrote:
>
> > Which part(s) is preventing you from contributing? 
>
> Please the remove that sign-up wall, Terms-of-service nonse and alike. 
>
> You know what we mean, don't you? 
>
> If you think your users (= us) need some kind notifications, 
> suspend-resume (i.e. save-load) functionality etc. then make it 
> optional please. 
> And if your real goal is earning money, then consider using some kind 
> of in-app-purchase mechanism. 
> Thanks. 
>

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

Re: Reading file to list as char array

[Peter Hull]

On Tuesday, 3 October 2017 12:39:47 UTC+1, Furkan Yıldız wrote:
>
> I am reading a txt file containing words. I need to add these words to the 
> list as char. For example
>
>  
>
> I think you need to split into words first using a regex then seq each word

(def words (clojure.string/split allstring #"\W"))


then 

(map seq words)

and of course you can put these together to avoid the intermediate 
definition(s)

(map seq (clojure.string/split (slurp fname) #"\W"))






-- 
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: Help ship Clojure 1.9!

[Stuart Halloway]

Hi Mark,

I think this approach totally makes sense, and the alpha naming exists to
inform this kind of decision-making.

For libraries where the use of spec does not have to be user-facing, I am
putting specs in separate (Clojure) namespaces, and loading them in such a
way that they can coexist with non (or maybe different) spec environments.
But that is extra work for sure.

Stu

On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg 
wrote:

> On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway  > wrote:
>
>> Hi David,
>>
>> Spec will be in alpha for a while. That is part of the point of it being
>> a separate library. Can you say more about what problems this is causing?
>>
>> Stu
>>
>>
> As a library maintainer, I am forced to upgrade and release my library any
> time something I depend upon makes a breaking change.  I don't get paid for
> maintaining open source libraries, it's something I do in my spare time, so
> I prefer to do it on my own schedule.  When an underlying library makes a
> breaking change, I get dozens of urgent requests from people who need me to
> cut a new release ASAP, and by Murphy's Law, that often happens when I have
> very little time to do it.  It's a nuisance.
>
> Clojure is pretty good about not making breaking changes, but it happens
> from time to time.  Clojurescript is less good about not making breaking
> changes, and therefore, maintaining Clojurescript libraries is more of a
> headache.  On the plus side, Clojurescript users seem to care very little
> about backwards compatibility (most keep up with the latest version), so
> sometimes it is easier to make a change to keep up with a change in
> Clojurescript than one in Clojure, where I am expected to not only support
> the latest breaking change, but also the last several releases.
>
> Anything that is labeled as "alpha" is waving a big red flag that there
> could be breaking changes at any time with little warning.  For my
> libraries which depend on spec, there's no way I'm going to bring them out
> of alpha status until spec comes out of alpha status.  If I make an
> official release of something that depends on spec, then I'm going to be on
> the hook to rapidly cut a new release every time spec changes, which could
> be at any time.  I don't want that hassle.  I don't want to make a promise
> to the community to maintain a stable product if the thing I depend upon
> has not made a similar promise.  When spec reaches a point where the API
> will not be changing, or rather, when we know that new changes will only be
> additive, I can begin to trust that it won't be a huge maintenance headache
> to release something based on spec.
>
> --
> 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.

Reading file to list as char array

[Furkan Yıldız]

 

I am reading a txt file containing words. I need to add these words to the 
list as char. For example

 

Example txt file:

 

this is a

simple

test

 

and the result should be the following:

 

'((t h i s) (i s) (a) (s i m p l e) (t e s t)

 

 

these are the codes I wrote,

 

(def allstring (slurp fname))

(def denemestring2 (seq allstring))

 

after these codes I put each word on a separate list, but how?

-- 
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: Clojurecademy: Learning Clojure Made Easy

[Rostislav Svoboda]

> Which part(s) is preventing you from contributing?

Please the remove that sign-up wall, Terms-of-service nonse and alike.

You know what we mean, don't you?

If you think your users (= us) need some kind notifications,
suspend-resume (i.e. save-load) functionality etc. then make it
optional please.
And if your real goal is earning money, then consider using some kind
of in-app-purchase mechanism.
Thanks.

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

Re: [core.spec] Stricter map validations?

[Leon Grapenthin]

My critique is not towards closed keysets but about being able to (s/keys 
:req [::some-kw]) without having defined the spec ::some-kw, but e.g. 
::soem-kw instead. This can trip you up badly, and not at compile time. I'd 
be surprised if this never happened to you.

Regarding open maps and keysets I'm fine with them. However, I use 
select-keys after validating data over the wire. Would be nice if there 
were some "select-spec" for open specs.

On Tuesday, October 3, 2017 at 5:03:01 AM UTC+2, Alex Miller wrote:
>
>
> On Monday, October 2, 2017 at 12:30:57 PM UTC-5, Leon Grapenthin wrote:
>>
>> I second this from my experience, using spec quite extensively since its 
>> release.
>>
>> We already had some invalid data passing silently because of this. It can 
>> easily happen if you have a typo in the spec.
>>
>> Also we never experienced benefits from being able to not spec keys 
>> required in s/keys. It appears to be a pretty obsolete feature, making 
>> vulnerabilities more likely.
>>
>
> It is more common to experience the negative effects of restricting key 
> sets as you evolve through versions, and in fact we have experienced on 
> virtually every consulting project we'd done including spec at Cognitect. 
> So I do not think it is at all obsolete.
>
>
>

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

Giving away conference passes to Clojure/Conj

[Srihari Sriraman]

Hello folks! 

We have 3 conference passes to Clojure/Conj to give away! We’ll go by the 
same selection and eligibility criteria as in 
http://2017.clojure-conj.org/opportunity-grants/. Send an email to 
divers...@nilenso.com to apply now!

Also, it'd be great if you could help spread the word: 
https://twitter.com/nilenso/status/915155703936958464

Cheers!
Srihari

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

[Leon Grapenthin]

My critique is not towards closed keysets but about being able to (s/keys :req 
[::some-kw]) without having defined the spec ::some-kw, but e.g. ::soem-kw 
instead. This can trip you up badly, and not at compile time. I'd be surprised 
if this never happened to you.

Regarding open maps and keysets I'm fine with them. However, I use select-keys 
after validating data over the wire. Would be nice if there were some 
"select-spec" for open specs.

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

[Mark Engelberg]

On Tue, Oct 3, 2017 at 2:55 AM, Peter Hull  wrote:

> On puzzler's database example, I would have thought that restricting the
> keys that go into the DB should not be the job of spec (since functions may
> not be instrumented anyway), but the job of the 'core logic'. Maybe I am
> misunderstanding though.
>


Even when functions are not instrumented, one powerful use of spec is to
call valid? or conform from within your code to test data against specs as
part of the function's logic.  One of the value propositions of spec is
that it handles a whole range of use cases.  You define your spec once, and
one of the many things you can do with it is to use it as part of your
validation logic.

-- 
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: Clojurecademy: Learning Clojure Made Easy

[Ertuğrul Çetin]

It's auto generated Terms of service, I should admit that I did not read 
all Terms. Which part(s) is preventing you from contributing? I can 
remove/change it, community's contribution is very important to platform.

On Tuesday, October 3, 2017 at 5:03:12 AM UTC+2, Sam Griffith wrote:
>
> Terms of service prevent me from helping. I'm not willing to write things 
> for the site and then have you own them like it says. That said, good luck. 
> It does look guise nice from looking at your GitHub.
>
> Sam
>

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

[Peter Hull]

I have found, as an application evolves, some extra data is required which 
comes from elsewhere. 

For example, I have an application where data is read from a network 
socket, transformed and stored. For auditing, I later decided it was useful 
to capture the remote address from the socket right at the start, and 
finally to log it. With restrictive specs, I would have had to re-spec all 
the intermediate functions. As it was, they didn't know or need to know 
about the extra key/value in the map, just pass it along.

On puzzler's database example, I would have thought that restricting the 
keys that go into the DB should not be the job of spec (since functions may 
not be instrumented anyway), but the job of the 'core logic'. Maybe I am 
misunderstanding though.

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