Re: Transitive spec generation

[James Gatannah]

On Tuesday, February 27, 2018 at 12:45:26 AM UTC-6, Didier wrote:
>
> Don't fully understand what you are doing,
>

(Slightly) bigger picture, I have a pair of functions that 
serialize/deserialize maps where the values are mostly fixed-length byte 
arrays.

I want to verify that they round-trip correctly.

This specific example is about two of those fields which really have the 
same spec. I'm trying to define this in a way that's similar to a C typedef 
(or possibly just something like using OOP inheritance for the sake of 
documentation):

(s/def ::extension ...)
(s/def ::server-extension ::extension)
(s/def ::client-extension ::extension)

I'm doing this in an attempt to trying to reduce my nesting levels.

This is what the weird subject is about: I'm trying to take advantage of 
the transitive property of specs.

 

> but when you run test.check, it seems to not always be generating random 
> sample, it'll grow the samples. When you run sample, it'll always start 
> back from the beginning. 
>

> You can see that by running:
>
> (sgen/sample (s/gen ::test) 100)
>
> See how the generated samples are getting longer and longer?
>

Now instead try running this 10 times:
(sgen/sample (s/gen ::test) 10)

And notice how you always get the same short samples?

 

(I'm sorry about the quote mangling).

Since I have to have a specific length, I'm specifying that as a parameter 
to sgen/vector.

This part of it works. I can run s/sample on my generator and validate its 
output against the spec without any trouble.

Actually, if I define the ::extension spec using with-gen, it also looks as 
though it works (I just ran across this, so haven't tested it thoroughly). 
But then my library has a runtime dependency on test.check. That's not the 
end of the world, but it's a definite downside.

I haven't been able to find real documentation covering the arguments to 
s/gen. But it looks as though I can pass in a map of 0-arity functions to 
override the different generators. The keys to that map override specs 
being generated. I can't remember now where I found this, but it can't be 
totally undocumented. I haven't studied the source code thoroughly enough 
to have picked out that sort of detail.

So:

(s/gen (s/keys :req [::server-extension
 ::client-extension])
   {::server-extension #(gen/fmap byte-array (gen/vector (gen/choose 
-128 127) extension-length))
::client-extension #(gen/fmap byte-array (gen/vector (gen/choose 
-128 127) extension-length))})


calls the function in the value associated with each key to override the 
generator for that spec.

This is the part that seems to only work sometimes.

When I extend this to include all the keys in the full spec, these are the 
only two that have problems. They're also the only ones that are directly 
defined as another spec definition. (Which is why I'm pointing my finger at 
my attempt to use the "transitive" property, though that could totally be a 
red herring).

When I run this inside deftest, it seems fine. Really, that's all I need. 
But I'd really like to understand the seemingly non-deterministic failures.

I wrote a function called manual-check that takes that generator and calls 
sgen/sample on it.

When I call that function directly from the REPL, it very nearly always 
fails.

When I call it 40 times in a reduce inside deftest, I haven't seen it fail 
yet.

* While I was writing this, I stumbled across another piece that seems like 
an interesting clue:

If I override the generator for ::extension rather than the individual 
specs that I've defined transitively, it seems to start working.

i.e. 

(s/gen (s/keys :req [::server-extension
 ::client-extension])
   {::extension #(gen/fmap byte-array (gen/vector (gen/choose -128 127) 
extension-length))})
 
seems to work.

It's still less than ideal, in case I ever want to change the underlying 
spec that's the "base" definition, since I'll have to remember to change 
the base generator. But I really shouldn't have this sort of thing 
scattered around everywhere. Especially since it's most interesting inside 
deftest anyway, where both approaches always seem to work (I haven't tested 
this out thoroughly yet either).

My current hypothesis is that there's something about the deftest macro 
that interacts with test.check in a way that makes gen more capable in 
terms of resolving which spec I actually mean/want to override. I know 
(based on digging through internals) that it calls something (I think it's 
named specize) that resolves the spec's name. Then it has to use that 
name/those names in the overriding map parameter to pick out the 
appropriate function to call to get the generator.

I'm very skeptical, but could that possibly hold water?

Thank you to anyone who actually took the time to read this!

 

>
>
> On Monday, 26 February 2018 21:39:09 UTC-8, James Gatannah wrote:
>>
>> Fairly minimalist example available at 
>> 

Re: [?] Adding my own function to clojure.core namespace

[Kurt Harriger]

You might also have a look at a library called vinyasa
 

> https://github.com/ardumont/vinyasa
>

You can can add it to your lein profile to copy functions into clojure.core 
and prefix them.  
The prefix makes it very clear that these are not part of standard 
clojure.core. 

(inject 'clojure.core '>> '[[clojure.repl doc [source source]]]) 

;; => will create the var #'clojure.core/>>doc and #'clojure.core/source
 


-- 
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: Why does the `def-` not exist?

[Alex Miller]

On Tuesday, February 27, 2018 at 1:13:52 PM UTC-6, Leon Grapenthin wrote:
>
> I'm sure you'd all use def- if it existed. Even if you could just type the 
> much simplified ^:private, use an editor snippet, refer your own macro, or 
> create a whole new namespace for it. You'd do none of that. You'd totally 
> fall for the trap and type def-, the syntactic aid that should not be there.
>

I'm sure I would. But I don't need it. If it was there, we'd be having the 
same discussion about defmacro- or defmulti- or whatever. There has to be a 
line somewhere, we drew before def-.
 

> There is "regret over even adding defn-"? You used defn- just recently in 
> the tools.deps.alpha core namespace 9 times. Rich used it in clojure.spec 
> core namespace 46 times. :)))
>

Sure, it's there. But if it wasn't, I'd use ^:private and never worry about 
it.
 

> Jokes aside, if Rich simply doesn't want it that's fine of course - it's 
> his language. However if people ask me again I will just say that instead. 
> Believe it or not, I got this question three times last year and the "copy 
> N things" argument failed 3/3.
>

Why even make the argument? If you want def- in your code, then add it. 
It's a Lisp - we can all have the language we want.

The impl ns pattern recommended by Timothy is truly a very good one that I 
> apply a lot myself, especially in larger projects and when "private" macro 
> helpers are involved (and probably the only solid workaround recommended 
> here because it has value in itself).
>

I use this one as well (I haven't doc'ed it all yet because I'm still 
fighting with autodoc) but I consider parts of tools.deps.alpha public and 
parts to be "impl".
 

> How much do I def things? - I haven't done the computation but I'm pretty 
> sure that I def more things ^:private than I def things public. Little 
> lookup tables etc.. Also I'd argue that def is the second most used top 
> level form after defn. If not, the ones that come before don't have 
> ^:private semantics. Well, if there was any chance for def- left I'd do a 
> statistic over available codebases - let me know.
>

Here's a quick and dirty stat based on the set of ~375 projects I have at 
hand:

[~/code]$ ack -c -h --clojure "\(defn- " */src
5106
[~/code]$ ack -c -h --clojure "\(defn " */src
14344
[~/code]$ ack -c -h --clojure "\(def " */src
3924
[~/code]$ ack -c -h --clojure "\(def \^:private" */src
559   # note this is a subset of prior, first pair are 
disjoint

defn is 5x more common than def. About 14% of def's are private and 26% of 
defns are private. On average I have <2 private defs per project. That 
doesn't do much to convince me it's a priority.

-- 
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: [?] Adding my own function to clojure.core namespace

[Colin Fleming]

On 25 February 2018 at 23:42, Gary Fredericks 
wrote:

> For clojure (not cljs, yet) I proxy all the dev utilities I might want to
> use in a namespace called `.` so I can refer to it everywhere no matter
> what the local namespace setup is: https://github.com/
> gfredericks/dot-slash-2
>

Note that the reader doc (https://clojure.org/reference/reader) says that
"Symbols beginning or ending with '.' are reserved by Clojure". It's not
enforced of course, but it might break things. It might be a good idea to
use some other single char prefix.




> On Sunday, February 25, 2018 at 11:45:41 AM UTC-6, Philos Kim wrote:
>>
>> I have another question. Debux library supports ClojureScript as well.
>> Similarly, I want to add my own function or macro to cljs.core as in
>> Clojure. Can I use the same strategy in ClojureScript as in Clojure if I
>> use it in the  ClojureScript source code, not in REPL?
>
> --
> 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: Why does the `def-` not exist?

[Leon Grapenthin]

I'm sure you'd all use def- if it existed. Even if you could just type the 
much simplified ^:private, use an editor snippet, refer your own macro, or 
create a whole new namespace for it. You'd do none of that. You'd totally 
fall for the trap and type def-, the syntactic aid that should not be there.

There is "regret over even adding defn-"? You used defn- just recently in 
the tools.deps.alpha core namespace 9 times. Rich used it in clojure.spec 
core namespace 46 times. :)))

Jokes aside, if Rich simply doesn't want it that's fine of course - it's 
his language. However if people ask me again I will just say that instead. 
Believe it or not, I got this question three times last year and the "copy 
N things" argument failed 3/3.

The impl ns pattern recommended by Timothy is truly a very good one that I 
apply a lot myself, especially in larger projects and when "private" macro 
helpers are involved (and probably the only solid workaround recommended 
here because it has value in itself).

How much do I def things? - I haven't done the computation but I'm pretty 
sure that I def more things ^:private than I def things public. Little 
lookup tables etc.. Also I'd argue that def is the second most used top 
level form after defn. If not, the ones that come before don't have 
^:private semantics. Well, if there was any chance for def- left I'd do a 
statistic over available codebases - let me know.


On Tuesday, February 27, 2018 at 2:41:15 AM UTC+1, Alex Miller wrote:
>
> We're not going to add def-. There is regret over even adding defn-, but 
> we don't take things away...
>
> At one point all of the current metadata niceties didn't exist (used to be 
> #^{:private true} some may recall) and defn- seemed worth doing I presume 
> (pre-dates my involvementT). But then that was all simplified down to just 
> ^:private and it's preferred to compose the pieces rather than copy N 
> things. 
>
> There used to be a slew of these in the old clojure-contrib (
> https://github.com/clojure/clojure-contrib/blob/master/modules/def/src/main/clojure/clojure/contrib/def.clj
>  
> - but no def- !). 
>
> How often do you def things anyway (much less private things)? 
>
> On Monday, February 26, 2018 at 1:50:40 PM UTC-6, Leon Grapenthin wrote:
>>
>> I have written enough Clojure so that I can assure you that every few 
>> days when I type ^:private again I am still annoyed by it. Not every time, 
>> but probably every second or third time.
>>
>> Its just in the way of the prototyping typing (micro-)flow. SHIFT-6 you 
>> don't hit so often so you have to hit it right. On german keyboards, by the 
>> way, ^ is a much more annoying character to type. Then a colon, did I miss 
>> the colon? What did I want to do again?
>>
>> When prototyping an API ns its important to distinguish what is private 
>> and what isn't. If only I could just write def- without any overhead.
>>
>> First world aka best language problems, I know...
>>
>> But whats left for an enthusiast except bikeshedding? We both know that a 
>> JIRA discussion on this will not happen due to a lack of importance. And 
>> unless somebody manages to convince Rich, this feature won't happen.
>>
>> Fair enough. I'd consider myself a power user since 1.5.1 and value its 
>> conservative governance above every other kind.  
>> The "lets not start postfixing lots of macros with -" argument a good one 
>> in general and probably was a good one at the time. But not in this case 
>> because defn and def are the two most used and most elementary top level 
>> forms. 
>>
>> This argument didn't convince anyone who has asked me about this. The 
>> counter argument goes "I don't want the - postfix for anything else, just 
>> for def because I use it a lot" -rightfully so.
>>
>> The lack of def- is just unnecessary typing overhead in lots of cases. It 
>> could be removed at the cost 5m on a beautiful day. I'd appreciate it :)
>>
>> On Monday, February 26, 2018 at 6:52:51 PM UTC+1, Alexander Yakushev 
>> wrote:
>>>
>>> - Not that often. When I know for certain, I add ^:private. Not like 
>>> it's much more work. If I didn't know ahead of time, I would forget to add 
>>> the private flag in either case.
>>> - Never.
>>> - Can't recollect such an event.
>>> - A few times. As far as I can tell, people appreciate the metadata 
>>> approach since it is unique and powerful. The lack of one particular 
>>> non-critical syntactic sugar is never an issue.
>>>
>>> I won't mind having def- as much as I don't mind not having it. Pretty 
>>> much the same as for defn- – Earth wouldn't stop turning if you had to type 
>>> defn ^:private once in a while.
>>>
>>> And while I agree with you that it would be somewhat useful, 
>>> bikeshedding only gets you so far.
>>>
>>> On Monday, February 26, 2018 at 7:17:05 PM UTC+2, Leon Grapenthin wrote:

 - How many times do you just write (def ...) instead of (def ^:private 
 ...) because you are not sure whether you need the definition yet, 

Re: [ANN] clj 1.9.0.348 and tools.deps.alpha 0.5.398

[Alex Miller]

On Tue, Feb 27, 2018 at 12:36 AM, Didier  wrote:

> Another question, after installing it, if I run clj and then do:
>
> (require '[clojure.spec.aplha :as s])
>
>
^^ typo: aplha


> I get:
>
> FileNotFoundException Could not locate clojure/spec/aplha__init.class or
> clojure/spec/aplha.clj on classpath.  clojure.lang.RT.load (RT.java:463)
>
> So I have to explicitly add it as a dependency with:
>
> clj -Sdeps "{:deps {org.clojure/spec.alpha {:mvn/version \"0.1.143\"}}}"
>
> But I thought Spec was part of Clojure 1.9, and should be auto-imported no?
>

It is, and will be automatically included as a dependency.

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

Re: [ANN] clj 1.9.0.348 and tools.deps.alpha 0.5.398

[Alex Miller]

On Tue, Feb 27, 2018 at 12:23 AM, Didier  wrote:

> There was a small bug with the install script around the man pages for me
> on a fresh openSuse Tumbleweed install.
>
> /usr/local/share/man/man1 did not exist. Specifically,
> /usr/local/share/man did not exist, so I had to manually mkdir it first,
> and re-run the installer, which only checked for the existence of man1 and
> created that one if missing. I think it should check for /man also, and
> create that one too if missing.
>

Thanks! Will fix.

-- 
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: Russ olsen's Clojure Book

[Alex Miller]

The books page only lists books after their final release. I found that many 
books have drifting publish dates and don’t always proceed to completion so 
decided on this guide for when to add things.

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

[ANN] Another one implementation of JSR 223 (Java Scripting API) for Clojure

[Oleg Vershinin]

Here is a link: 

https://github.com/overshinin/clojure-jsr223

-- 
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: Is there some central information available on Java 9 compatibility for Clojure and tools

[Ivan Pierre]

There are already some posts about the work to do (a little bit)

Java 9 was recently released on September 21st, 2017. If you’re a Clojure 
developer, you’re probably keen to try it out to see some of the new 
features and performance improvements available. To do so, you need to do a 
few things. For most projects, this will be a small to moderate amount of 
work. 
https://www.deps.co/blog/how-to-upgrade-clojure-projects-to-use-java-9/
An old video where the problems are described
https://www.youtube.com/watch?v=4fevIDAxQAM

You have to use last Clojure and Leiningen version, so use of library is 
dependent on the update thereof... ;)

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