Re: varying realization of a lazy-seq of strings?

[Michał Marczyk]

That's right. This happens is because collection classes' toString
implementations currently delegate to RT.printString, which in turn is
affected by the value of *print-readably*.

Filed https://dev.clojure.org/jira/browse/CLJ-2248 with a fix.

Cheers,
Michał


On 18 September 2017 at 03:08, Justin Smith  wrote:

> my simplified reproduction of the issue:
>
> +user=> (let [mk-str (fn [] (lazy-seq [(str ["ZiZi"])]))
>   a (mk-str)
>   b (mk-str)]
>   (print-str a)
>   (pr-str b)
>   [a b])
> [("[ZiZi]") ("[\"ZiZi\"]")]
>
> isn't *print-readably* the difference between pr-str and print-str?
>
> On Sun, Sep 17, 2017 at 5:59 PM Didier  wrote:
>
>> Lazy sequences cache their values after the first time they are
>> evaluated. Since print alters the output of str by binding *print-readably*
>> to false, and also forces the sequence to realize itself, the values in
>> your sequence are now cached the the result of str without
>> *print-readably*. In subsequent calls to the sequence, you get the cache
>> results, so even if you change the setting of *print-readably* it doesn't
>> do anything.
>>
>> Either make sure that when you first access elements of the sequence, the
>> bindings are the way you want str to be configured, or have the bindings
>> set inside the lazy-seq.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help ship Clojure 1.9!

[Michał Marczyk]

I've run into a behaviour change that was actually already present in
alpha20 – with the CLJ-99 patch in place, {min,max}-key now return the
first argument with the minimum/maximum key, whereas previously they
returned the last such argument.

The new behaviour seems like the more natural one, but this is a breaking
change, so I filed https://dev.clojure.org/jira/browse/CLJ-2247 to track
this (with a patch that takes the "default" approach of restoring
established behaviour).

Cheers,
Michał


On 3 October 2017 at 21:11, Beau Fabry  wrote:

> 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 

Re: [core.spec] Stricter map validations?

[Beau Fabry]

Seems like that's the reasonable place to check it, otherwise you're forced 
into an ordering for your specs and cannot write recursive strict map specs.

On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
wrote:
>
> Thanks. This approach is also different from the macro because it will 
> check specs existence at the validation time, not at the s/def call.
>
> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>
>> Yuri Govorushchenko  writes: 
>>
>> > Thank you the pointers! So far I ended up with writing a small `map` 
>> macro 
>> > which is similar to `s/keys` but checks that keys are already in the 
>> > registry: 
>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>>
>> Note that you can simply combine a custom predicate and `s/keys` in 
>> clojure.spec to verify that all keys in a given map have a underlying 
>> spec: 
>>
>> ``` 
>> (s/def ::whatever (s/and (s/keys ...) 
>>  #(every? keyword? (keys %)) 
>>  #(every? (comp boolean s/get-spec) (keys %)) ) 
>> ``` 
>>
>

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

Thanks. This approach is also different from the macro because it will 
check specs existence at the validation time, not at the s/def call.

On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>
> Yuri Govorushchenko  writes: 
>
> > Thank you the pointers! So far I ended up with writing a small `map` 
> macro 
> > which is similar to `s/keys` but checks that keys are already in the 
> > registry: 
> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>
> Note that you can simply combine a custom predicate and `s/keys` in 
> clojure.spec to verify that all keys in a given map have a underlying 
> spec: 
>
> ``` 
> (s/def ::whatever (s/and (s/keys ...) 
>  #(every? keyword? (keys %)) 
>  #(every? (comp boolean s/get-spec) (keys %)) ) 
> ``` 
>

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

Here is the DSL documentation link if anyone interested in creating Clojure 
based courses: https://clojurecademy.github.io/dsl-documentation

On Monday, October 2, 2017 at 6:47:55 PM UTC+2, Ertuğrul Çetin wrote:
>
> 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 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?

[Moritz Ulrich]

Yuri Govorushchenko  writes:

> Thank you the pointers! So far I ended up with writing a small `map` macro 
> which is similar to `s/keys` but checks that keys are already in the 
> registry: 
> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2

Note that you can simply combine a custom predicate and `s/keys` in
clojure.spec to verify that all keys in a given map have a underlying
spec:

```
(s/def ::whatever (s/and (s/keys ...)
 #(every? keyword? (keys %))
 #(every? (comp boolean s/get-spec) (keys %)) )
```

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