Question about tightly couple spec interactions

[James Gatannah]

Background:

I'm in the process of translating a fairly low-level and messy C
networking library. The original involves lots of bit-twiddling and
global variables.

My first pass (which has been in the "real soon now" state for months
now...in hind-sight, I have some regrets about starting this at all,
much less trying to go straight from C to clojure) tried to stick
fairly close to the original as I figured out what it was doing.

I also used this project as an excuse to start learning about spec.
Right now, I'm basically just using it to document parameters and
return values. I've started doing a little generative testing, but
that part's just icing, really.

I wound up with some uncomfortably large top-level maps. So I have
specs like ::server/state, ::client/state, and ::ioloop/state. Those
in turn contain maps like ::log/state and ::flow-control/state.

There's nothing really exciting/surprising about any of that. There
are a couple of places where the tree gets 3 or 4 layers deep, but it
doesn't seem awful.

In my original version, I basically just passed the top-level state
maps around everywhere. A function takes that as one of its
parameters, and it probably returns the same thing where 1 or 2 of the
values have been updated.

Now I think I want to get more specific about the spec for each of
those functions so I have a better feel for what each is doing.

And I almost feel like I'm dealing with java checked exceptions.

Say I have (-> x foo bar baz qux), and qux is the hairy part that
actually uses all the complicated values (and there are also plenty of
byte-arrays, just to make life really interesting) stored in x.

The details don't matter, but just to make the problem a little more concrete:

foo, bar, and baz have their own hairiness. In the specific scenario
that I'm looking at right now, foo is the boundary-function event
handler that pulls byte buffers off the network socket, bar is the
function that decides how to handle each incoming packet, baz is the
function that handles this particular packet type, and then qux is the
part that opens the encryption box that contains the actual payload.

I decided last night to extend some ongoing refactoring to qux. It now
uses a new key that I recently introduced. Except that I don't seem to
have added it to the top-level state map that I'm passing around
everywhere. In disgust, I started dabbling with the idea of being
explicit about which keys it actually needs.

In order to make that work, it seems like I need to update the specs
for baz and bar to specify their exact parameters/return values. And
possibly exactly which members of the top-level state I expect to
change. So when the spec for one changes, it trickles up to everything
that calls it.

I wouldn't mind too terribly much making them as tightly coupled as
this implies. They already are, really, and they're all so specialized
that they really don't make any sense in isolation. I really just
broke them into smaller pieces out of a single gigantic main()
function for the sake of my own sanity.

And this is strictly internal. The library interface is just a
function/callback thing to read/write.

How do other people approach the sort of big-picture problem I'm describing?

Thanks in advance,
James

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

Proper way to write EDN file, after production bug

[Didier]

Ya, I'd write a wrapping fn, like ->edn which internally binds everything to 
what it should be, maybe even declares some extra print defmethod if you need 
custom edn serialization, and returns the edn.

-- 
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: Proper way to write EDN file, after production bug

[LaurentJ]

I guess we will do that and provide an helper function in an util namespace 
to write an EDN file safely :/

By the way does binding *print-dup* to true isn't enough to prevent any 
interaction of other options like : *print-length* *print-level* ?



Le jeudi 29 mars 2018 21:16:54 UTC+2, Rick Moynihan a écrit :
>
> I'd suggest wrapping the code that writes via prn to the file with a 
> dynamic binding:
>
> e.g. at a REPL:
>
> user=> (set! *print-length* 5)
> 5
> user=> (prn (range 10))
> (0 1 2 3 4 ...)
> nil
> user=> (binding [*print-length* nil] (prn (range 11)))
> (0 1 2 3 4 5 6 7 8 9 10)
> nil
> user=> (prn (range 10))
> (0 1 2 3 4 ...)
>
> If you don't know how this works (or differs to lexical binding via let) 
> you can read up on vars here:
>
> https://clojure.org/reference/vars
>
> Hope this helps!
>
> R.
>
> On 29 March 2018 at 15:57, LaurentJ  
> wrote:
>
>> Hello,
>>
>> A funny bug today, our pipeline was broken because of an EDN file with 
>> ellipsis in it.
>>
>> It appears that the file was generated from a Clojure env with 
>> *print-length* configured.
>> So as many have asked, do we have a better way to write EDN file other 
>> than using prn ?
>>
>> For the moment what is the best strategy to fix this issue and keep our 
>> coders happy with their local repl configuration ?
>>   - ask them to limit the scope of such configuration, in for example the 
>> lein repl profile ?
>>   - wrap prn calls with rebinding of any dynamic vars modifing the 
>> outpout ?
>>
>> Regards
>> Laurent
>> -- 
>> 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: Writing a text adventure in Clojure

[James Reeves]

Often it's better to store the entire game state as one large, immutable
data structure.

Atoms are usually preferred over refs in most cases.

When you want polymorphism over a map, the most common solution is to use
protocols and records.


On 29 March 2018 at 23:45, Will Duquette  wrote:

> I'm an experienced programmer, but a Clojure newbie; as a beginner
> project, I'm looking into how one would idiomatically write a text
> adventure of sorts in Clojure.  I'm less interested in producing a playable
> game than I am in learning how to do such a thing in a proper functional
> style.
>
> Suppose in this game I have a room whose description changes based on a
> global flag.  For example, there's something in the Fancy Room that you
> won't notice until you've reached the major plot point.
>
> The world map is (for the sake of argument) a hash-map whose keys are the
> room IDs and whose values are room records, where each record is a hash-map.
>
> (def world {:fancy-room {:name "Fancy Room" :description "This is a fancy
> room." ...}})
>
> I'm aware that I could use a (defstruct) or (defrecord); I'm keeping it
> simple for now.  Then, the flags are saved in a ref; the intent is that
> mutable set is segregated, so that it can more easily be written to a save
> file.
>
> ;; Global set of flags
> (def flags (ref #{})
>
> (defn flag-set [flag]
>(dosync (alter flags conj flag))
>
> ;; When the major plot point is reached
> (flag-set :major-plot-point-reached)
>
> Normally, to describe a room you just return its :description.
>
> (defn describe [room] (:description (world get room)))
>
> But for the :fancy-room, the returned description depends on the global
> flag, and it will be specific to :fancy-room.  I could add this logic
> directly to the (describe) function's body, but that would be ugly.  What
> I'd like to do is attach a lambda to the :fancy-room in some way.  The
> (describe) function looks for a :describer, and if it's there it calls it;
> and if not it just returns the :description:
>
> (defn describe [entity]
> (if (:describer entity)
>   ((:describer entity) entity)
>   (:description entity)))
>
> *Question 1*: this works, but it looks ugly to me; I figure there's a
> better, more idiomatic way to do this kind of thing that's probably obvious
> to anyone with any real experience.  Multimethods, maybe?  Define a Room
> protocol, then let most rooms be NormalRoom records, but let :fancy-room be
> a FancyRoom record?
>
> *Question 2*: Whatever code actually computes the description, it will
> need access to the :major-plot-point-reached flag.  What's the cleanest way
> to give the description code access to the flags ref?  It could simply
> access "@flags" directly:
>
> (if (:major-plot-point-reached @flags)
>   "This is a fancy room.  Hey, that light sconce looks movable!"
>   "This is a fancy room.")
>
> But that doesn't seem properly functional.  Would it be better to pass the
> game state into each method?
>
> (defn describe [entity state]
>   (if (:describer entity)
>  ((:describer entity) entity state)
>  (:description entity)))
>
> Any ideas?
>
> --
> 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.
>



-- 
James Reeves
booleanknot.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: Nesting test.check's defspec tests like deftest/testing

[Gary Fredericks]

There's nothing like that in test.check proper, but you might find this 
 
useful.

On Thursday, March 29, 2018 at 7:36:15 AM UTC-5, Khalid Jebbari wrote:
>
> Hello everyone,
>
> Is there a way to nest defspec tests like we can with deftest and testing 
> ? I'm porting some tests from deftest to defspec but losing the ability to 
> nest them make them a bit less readable.
>
> Thanks in advance
>

-- 
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: Writing a text adventure in Clojure

[Timothy Baldridge]

You often don't even need functions for this sort of thing. This is what is
often called "data driven" programs. Simply define this as a hashmap with
:description, :items, etc and then a single function that introspects this
data and figures out how to describe the room.

Also you might want to read up on Entity Component Systems. They are often
implemented in OOP languages, but they really are not OOP at all. Here's a
good talk on the subject: https://www.youtube.com/watch?v=TW1ie0pIO_E

On Thu, Mar 29, 2018 at 5:00 PM, Will Duquette  wrote:

> Aha!  How about this, to cut the Gordian knot:
>
>
>1. The fancy room's :description isn't necessarily a simple string.
>It can be a vector of specs, where each spec is a text snippet or a pair
>containing a predicate function and a text snippet.
>2. The (describe) function takes two arguments, the global state and
>the room record.
>3. It steps through the specs, including only those snippets whose
>predicate is true.  The predicates, of course, are predicates on the global
>state.
>
> The room is then a simple object; and the describe method remains purely
> functional.
>
> On Thursday, March 29, 2018 at 3:45:02 PM UTC-7, Will Duquette wrote:
>>
>> I'm an experienced programmer, but a Clojure newbie; as a beginner
>> project, I'm looking into how one would idiomatically write a text
>> adventure of sorts in Clojure.  I'm less interested in producing a playable
>> game than I am in learning how to do such a thing in a proper functional
>> style.
>>
>> Suppose in this game I have a room whose description changes based on a
>> global flag.  For example, there's something in the Fancy Room that you
>> won't notice until you've reached the major plot point.
>>
>> The world map is (for the sake of argument) a hash-map whose keys are the
>> room IDs and whose values are room records, where each record is a hash-map.
>>
>> (def world {:fancy-room {:name "Fancy Room" :description "This is a fancy
>> room." ...}})
>>
>> I'm aware that I could use a (defstruct) or (defrecord); I'm keeping it
>> simple for now.  Then, the flags are saved in a ref; the intent is that
>> mutable set is segregated, so that it can more easily be written to a save
>> file.
>>
>> ;; Global set of flags
>> (def flags (ref #{})
>>
>> (defn flag-set [flag]
>>(dosync (alter flags conj flag))
>>
>> ;; When the major plot point is reached
>> (flag-set :major-plot-point-reached)
>>
>> Normally, to describe a room you just return its :description.
>>
>> (defn describe [room] (:description (world get room)))
>>
>> But for the :fancy-room, the returned description depends on the global
>> flag, and it will be specific to :fancy-room.  I could add this logic
>> directly to the (describe) function's body, but that would be ugly.  What
>> I'd like to do is attach a lambda to the :fancy-room in some way.  The
>> (describe) function looks for a :describer, and if it's there it calls it;
>> and if not it just returns the :description:
>>
>> (defn describe [entity]
>> (if (:describer entity)
>>   ((:describer entity) entity)
>>   (:description entity)))
>>
>> *Question 1*: this works, but it looks ugly to me; I figure there's a
>> better, more idiomatic way to do this kind of thing that's probably obvious
>> to anyone with any real experience.  Multimethods, maybe?  Define a Room
>> protocol, then let most rooms be NormalRoom records, but let :fancy-room be
>> a FancyRoom record?
>>
>> *Question 2*: Whatever code actually computes the description, it will
>> need access to the :major-plot-point-reached flag.  What's the cleanest way
>> to give the description code access to the flags ref?  It could simply
>> access "@flags" directly:
>>
>> (if (:major-plot-point-reached @flags)
>>   "This is a fancy room.  Hey, that light sconce looks movable!"
>>   "This is a fancy room.")
>>
>> But that doesn't seem properly functional.  Would it be better to pass
>> the game state into each method?
>>
>> (defn describe [entity state]
>>   (if (:describer entity)
>>  ((:describer entity) entity state)
>>  (:description entity)))
>>
>> Any ideas?
>>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no 

Re: Writing a text adventure in Clojure

[Will Duquette]

Aha!  How about this, to cut the Gordian knot:


   1. The fancy room's :description isn't necessarily a simple string.  It 
   can be a vector of specs, where each spec is a text snippet or a pair 
   containing a predicate function and a text snippet.
   2. The (describe) function takes two arguments, the global state and the 
   room record.
   3. It steps through the specs, including only those snippets whose 
   predicate is true.  The predicates, of course, are predicates on the global 
   state.

The room is then a simple object; and the describe method remains purely 
functional.

On Thursday, March 29, 2018 at 3:45:02 PM UTC-7, Will Duquette wrote:
>
> I'm an experienced programmer, but a Clojure newbie; as a beginner 
> project, I'm looking into how one would idiomatically write a text 
> adventure of sorts in Clojure.  I'm less interested in producing a playable 
> game than I am in learning how to do such a thing in a proper functional 
> style.
>
> Suppose in this game I have a room whose description changes based on a 
> global flag.  For example, there's something in the Fancy Room that you 
> won't notice until you've reached the major plot point.
>
> The world map is (for the sake of argument) a hash-map whose keys are the 
> room IDs and whose values are room records, where each record is a hash-map.
>
> (def world {:fancy-room {:name "Fancy Room" :description "This is a fancy 
> room." ...}})
>
> I'm aware that I could use a (defstruct) or (defrecord); I'm keeping it 
> simple for now.  Then, the flags are saved in a ref; the intent is that 
> mutable set is segregated, so that it can more easily be written to a save 
> file.
>
> ;; Global set of flags
> (def flags (ref #{})
>
> (defn flag-set [flag]
>(dosync (alter flags conj flag))
>
> ;; When the major plot point is reached
> (flag-set :major-plot-point-reached)
>  
> Normally, to describe a room you just return its :description.
>
> (defn describe [room] (:description (world get room)))
>
> But for the :fancy-room, the returned description depends on the global 
> flag, and it will be specific to :fancy-room.  I could add this logic 
> directly to the (describe) function's body, but that would be ugly.  What 
> I'd like to do is attach a lambda to the :fancy-room in some way.  The 
> (describe) function looks for a :describer, and if it's there it calls it; 
> and if not it just returns the :description:
>
> (defn describe [entity]
> (if (:describer entity) 
>   ((:describer entity) entity)
>   (:description entity)))
>
> *Question 1*: this works, but it looks ugly to me; I figure there's a 
> better, more idiomatic way to do this kind of thing that's probably obvious 
> to anyone with any real experience.  Multimethods, maybe?  Define a Room 
> protocol, then let most rooms be NormalRoom records, but let :fancy-room be 
> a FancyRoom record?
>
> *Question 2*: Whatever code actually computes the description, it will 
> need access to the :major-plot-point-reached flag.  What's the cleanest way 
> to give the description code access to the flags ref?  It could simply 
> access "@flags" directly:
>
> (if (:major-plot-point-reached @flags) 
>   "This is a fancy room.  Hey, that light sconce looks movable!"
>   "This is a fancy room.")
>
> But that doesn't seem properly functional.  Would it be better to pass the 
> game state into each method?
>
> (defn describe [entity state]
>   (if (:describer entity)
>  ((:describer entity) entity state)
>  (:description entity)))
>
> Any ideas?
>

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

Writing a text adventure in Clojure

[Will Duquette]

I'm an experienced programmer, but a Clojure newbie; as a beginner project, 
I'm looking into how one would idiomatically write a text adventure of 
sorts in Clojure.  I'm less interested in producing a playable game than I 
am in learning how to do such a thing in a proper functional style.

Suppose in this game I have a room whose description changes based on a 
global flag.  For example, there's something in the Fancy Room that you 
won't notice until you've reached the major plot point.

The world map is (for the sake of argument) a hash-map whose keys are the 
room IDs and whose values are room records, where each record is a hash-map.

(def world {:fancy-room {:name "Fancy Room" :description "This is a fancy 
room." ...}})

I'm aware that I could use a (defstruct) or (defrecord); I'm keeping it 
simple for now.  Then, the flags are saved in a ref; the intent is that 
mutable set is segregated, so that it can more easily be written to a save 
file.

;; Global set of flags
(def flags (ref #{})

(defn flag-set [flag]
   (dosync (alter flags conj flag))

;; When the major plot point is reached
(flag-set :major-plot-point-reached)
 
Normally, to describe a room you just return its :description.

(defn describe [room] (:description (world get room)))

But for the :fancy-room, the returned description depends on the global 
flag, and it will be specific to :fancy-room.  I could add this logic 
directly to the (describe) function's body, but that would be ugly.  What 
I'd like to do is attach a lambda to the :fancy-room in some way.  The 
(describe) function looks for a :describer, and if it's there it calls it; 
and if not it just returns the :description:

(defn describe [entity]
(if (:describer entity) 
  ((:describer entity) entity)
  (:description entity)))

*Question 1*: this works, but it looks ugly to me; I figure there's a 
better, more idiomatic way to do this kind of thing that's probably obvious 
to anyone with any real experience.  Multimethods, maybe?  Define a Room 
protocol, then let most rooms be NormalRoom records, but let :fancy-room be 
a FancyRoom record?

*Question 2*: Whatever code actually computes the description, it will need 
access to the :major-plot-point-reached flag.  What's the cleanest way to 
give the description code access to the flags ref?  It could simply access 
"@flags" directly:

(if (:major-plot-point-reached @flags) 
  "This is a fancy room.  Hey, that light sconce looks movable!"
  "This is a fancy room.")

But that doesn't seem properly functional.  Would it be better to pass the 
game state into each method?

(defn describe [entity state]
  (if (:describer entity)
 ((:describer entity) entity state)
 (:description entity)))

Any ideas?

-- 
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: Proper way to write EDN file, after production bug

[Rick Moynihan]

I'd suggest wrapping the code that writes via prn to the file with a
dynamic binding:

e.g. at a REPL:

user=> (set! *print-length* 5)
5
user=> (prn (range 10))
(0 1 2 3 4 ...)
nil
user=> (binding [*print-length* nil] (prn (range 11)))
(0 1 2 3 4 5 6 7 8 9 10)
nil
user=> (prn (range 10))
(0 1 2 3 4 ...)

If you don't know how this works (or differs to lexical binding via let)
you can read up on vars here:

https://clojure.org/reference/vars

Hope this helps!

R.

On 29 March 2018 at 15:57, LaurentJ  wrote:

> Hello,
>
> A funny bug today, our pipeline was broken because of an EDN file with
> ellipsis in it.
>
> It appears that the file was generated from a Clojure env with
> *print-length* configured.
> So as many have asked, do we have a better way to write EDN file other
> than using prn ?
>
> For the moment what is the best strategy to fix this issue and keep our
> coders happy with their local repl configuration ?
>   - ask them to limit the scope of such configuration, in for example the
> lein repl profile ?
>   - wrap prn calls with rebinding of any dynamic vars modifing the outpout
> ?
>
> Regards
> Laurent
> --
> 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.

Proper way to write EDN file, after production bug

[LaurentJ]

Hello,

A funny bug today, our pipeline was broken because of an EDN file with 
ellipsis in it.

It appears that the file was generated from a Clojure env with 
*print-length* configured.
So as many have asked, do we have a better way to write EDN file other than 
using prn ?

For the moment what is the best strategy to fix this issue and keep our 
coders happy with their local repl configuration ?
  - ask them to limit the scope of such configuration, in for example the 
lein repl profile ?
  - wrap prn calls with rebinding of any dynamic vars modifing the outpout ?

Regards
Laurent

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

Nesting test.check's defspec tests like deftest/testing

[Khalid Jebbari]

Hello everyone,

Is there a way to nest defspec tests like we can with deftest and testing ? 
I'm porting some tests from deftest to defspec but losing the ability to 
nest them make them a bit less readable.

Thanks in advance

-- 
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: Best way to unit test

[Moe Aboulkheir]

bj,

Is 'current-date' a top-level var in that file?  If so, a good start might
be a test which used with with-redefs
 to supply a contrived
value for 'current-date', and then validated dates on either side of it.
It may be less brittle to support something like this:

(defn validate-date
 ([now date-for-validation] (<= (Integer/parseInt date-for-validation)
(Integer/parseInt now)))
 ([date-for-validation] (validate-date current-date
date-for-validation)))

You'd then only test the arity which accepts an explicit current-date, and
separately test whatever is responsible for deriving 'current-date'.  A few
notes:

- Having a static current-date is going to be a problem for long-running
programs - computing it at the point of validation may be a safer approach.
- If these values (current-date, date-for-validation) are used more than
once, converting them from strings elsewhere, and passing them around as
numbers may be more convenient.  validate-date just becomes <=, in that
case, and may not require a test.

Take care,
Moe


On Thu, Mar 29, 2018 at 2:20 AM, bj  wrote:

> What is the best way to write unit test case for following situation?
>
> [date-for-validation]
> (if (>= (Integer/parseInt current-date)
> (Integer/parseInt date-for-validation)) true false))
>
> --
> 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.