Okay. Thanks BG :)

On Saturday, May 30, 2015 at 5:13:00 AM UTC+5:30, Baishampayan Ghose wrote:
>
> May be wrap it up in a `wait-until-with-meta` macro as Herwig suggested? 
> Then you can search and replace the invocations. ~BG
>
> On Fri, May 29, 2015 at 9:30 PM, Shalaka Patil <sha...@helpshift.com 
> <javascript:>> wrote:
>
>> Hey BG, 
>>    Yes, having metadata is really a straight forward way but this is kind 
>> of extra work in every wait-until call which I was trying to avoid. Going 
>> with metadata option will not just cause extra work for wait-until in 
>> future code but even I need to add it at all the places in wherever it is 
>> used. But yes, if having `eval` is really bad way or there is no other way 
>> to handle it then will go with `metadata` approach :)
>>
>> On Friday, May 29, 2015 at 8:53:11 PM UTC+5:30, Baishampayan Ghose wrote:
>>>
>>> Shalaka,
>>>
>>> This is a really interesting conversation :-) However, I'd insist that 
>>> you ditch eval or any sort of complicated affair and adopt the metadata 
>>> approach as I had suggested that day :-P
>>>
>>> ~BG
>>>
>>> On Fri, May 29, 2015 at 4:20 PM, Shalaka Patil <sha...@helpshift.com> 
>>> wrote:
>>>
>>>> Hey, Thanks Herwig & Mohit.
>>>>
>>>> So, I have one more solution.
>>>>
>>>> Here is the original wait-until function-
>>>>
>>>>
>>>> (defn wait-until
>>>>   ([pred] (wait/wait-until *driver* (fn [_] pred)))  ([pred timeout] (
>>>> wait/wait-until *driver* (fn [_] pred) timeout))  ([pred timeout 
>>>> interval] (wait/wait-until *driver* (fn [_] pred) timeout interval))  
>>>> ([driver pred timeout interval] (wait/wait-until driver (fn [d] (pred d
>>>> )) timeout interval)))
>>>>
>>>> I have converted function to macro like - 
>>>>
>>>> (defmacro with-wait-until-error-log
>>>>   [pred & body]
>>>>   `(try
>>>>      ~@body
>>>>      (catch Exception e#
>>>>        (println "\nWait-until failed for: " ~pred "\n")
>>>>        e#)))
>>>>
>>>>
>>>> (defmacro wait-until
>>>>   [& args]
>>>>   `(if (= (count '~args) 4)
>>>>      (let [pred# (nth '~args 1)]
>>>>        (with-wait-until-error-log
>>>>          pred#
>>>>          (wait/wait-until (eval (nth '~args 0))
>>>>                           (fn [_#] (eval pred#))
>>>>                           (nth '~args 2)
>>>>                           (nth '~args 3))))
>>>>      (let [pred# (first '~args)]
>>>>        (with-wait-until-error-log
>>>>          pred#
>>>>          (wait/wait-until *driver* (fn [_#] (eval pred#))
>>>>                           (nth '~args 1)
>>>>                           (nth '~args 2))))))
>>>>
>>>> So, by this way I am not breaking input format or fn behaviour, but 
>>>> need to use `eval`. So, is there any other way for doing same as eval? Or, 
>>>> is it OK to use eval?
>>>>
>>>>
>>>>
>>>> On Friday, May 29, 2015 at 12:55:20 PM UTC+5:30, Mohit Thatte wrote:
>>>>>
>>>>> I see what you mean, this is nice 
>>>>>
>>>>> On Thu, May 28, 2015 at 11:25 PM, Herwig Hochleitner <
>>>>> hhochl...@gmail.com> wrote:
>>>>>
>>>>>> 2015-05-28 19:42 GMT+02:00 Mohit Thatte <mohit....@gmail.com>:
>>>>>>>
>>>>>>> The interesting question here is what constitutes useful information!
>>>>>>>
>>>>>>
>>>>>> (let [pred #(exists? ".foo")]
>>>>>>   (wait-until pred)) ;; <- the fact that it's called 'pred is not 
>>>>>> interesting in most cases
>>>>>>  
>>>>>>
>>>>>>> The trade-off is breaking an existing public API.
>>>>>>>
>>>>>>
>>>>>> How so?
>>>>>>
>>>>>> (defmacro op [msg args expr]
>>>>>>   `(with-meta (fn ~args ~expr) {:msg ~msg :args '~args :expr '~expr}))
>>>>>>
>>>>>> (let [pred1 #(exists? ".foo")
>>>>>>       pred2 (op "checks existance" [] (exists? ".foo"))]
>>>>>>   ;; both these will work, the one with pred1 will give less useful 
>>>>>> errors. the API of wait-until is unchanged
>>>>>>   (wait-until pred1)
>>>>>>   (wait-until pred2))
>>>>>>
>>>>>> If Shalaka's primary goal is prettier errors in test failures, I'd 
>>>>>>> settle for the fn body itself as the error message and that could be 
>>>>>>> achieved without breaking the API.
>>>>>>>
>>>>>>
>>>>>> The op macro can include the code in its information.
>>>>>>
>>>>>> -- 
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> -Mohit Thatte
>>>>>  
>>>>  -- 
>>>> 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Baishampayan Ghose
>>> b.ghose at gmail.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 
>> <javascript:>
>> 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 <javascript:>
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Baishampayan Ghose
> b.ghose at gmail.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.

Reply via email to