A Cells port of David's core.async webinar on avoiding Callback Hell

[hiskennyness]

As I watched David Nolen's compelling core.async web client webinar 
(http://go.cognitect.com/core_async_webinar_recording) I started to wonder 
if CSP was not another metaphor for Cells (the spreadsheet being another, 
and in FRP we have a time series or stream or something).

So I went ahead and redid the ten examples as closely as possible* using 
Cells.

https://github.com/kennytilton/async-webinar

The README may soon be expanded, but if I do it will just be a reformatting 
of the heavily annotated:

  
 https://github.com/kennytilton/async-webinar/blob/master/src/webinar/core.cljs

Along the way I concluded Cells is not CSP, unless by communicating we mean 
"broadcasting whether or not anyone is listening and to whoever is 
listening". But my annotations turned out to be decent documentation of 
Cells, including a new "gotcha" I encountered recently for the first time 
in twenty years of Cells (suggesting the artificial code examples are unuse 
cases, which we already knew). That brings me to the long-awaited asterisK.

* In examples 4&5 David motivates then fixes a case where a coder is misled 
by the simplicity of a "go" form and tries to put to a channel and then 
take that value in the next statement, ending up blocked forever. That 
cannot happen with Cells, so I coded up the Cells "gotcha":

   (if (or cell-a cell-b) )

Cell depedencies are decided after each invocation of a cell formula and 
include only those other cells actually read, so once cell-a is true there 
will be no dependency on cell-b, so only cell-a is "heard".

Final note: I have seen "callback hell" a couple of places now. I guess 
Cells is hiding that from me. I do recall using qooxdoo's "message" hack to 
great effect in the brief time I did clients without Cells.

-kt




-- 
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: Frustrations so far

[Paul deGrandis]

Similar to James'  ring-anti-forgery message,
as the maintainer of Pedestal, I'd also like to know if you had issues with 
Pedestal (specifically, on the Pedestal mailing list 
).  In general, I 
think most maintainers want to know about shortcomings, missteps, or 
security risks.

--Paul

-- 
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: Future of spec/explain-data, spec/and, etc.

[Mars0i]

On Monday, July 25, 2016 at 10:56:09 AM UTC-5, Mars0i wrote:
>
>  just noticed this morning that :path is explained in "clojure.spec - 
> Rationale and Overview".
>

There's also material about :path in your Spec Guide, but I had not fully 
understood it.  I get it now--at least up to the level of my understanding 
of the rest of 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.

Re: Future of spec/explain-data, spec/and, etc.

[Mars0i]

Alex, thanks very much.  That's all very helpful.  Just what I needed.  I 
hadn't seen an explanation of the meaning of :path, :via, and :in, and was 
guessing about them from experiments.:via and :in aren't mentioned in 
the docstring, so I wasn't sure whether to depend on them.   (The source 
code that feeds into explain-data isn't easy reading--no reason to think it 
would be--and I haven't made sense of it so far.)   I just noticed this 
morning that :path is explained in "clojure.spec - Rationale and Overview".

I assume that the explain-data docstring will eventually sketch the meaning 
of :path, :via, and :in.  Or is this the sort of thing that I ought to file 
a JIRA ticket on if I think it's important? (I'm new to using JIRA don't 
want to clutter up with irrelevant tickets during an alpha process.  I 
don't see a ticket about the explain-data docstring.

On Monday, July 25, 2016 at 12:34:23 AM UTC-5, Alex Miller wrote:
>
>
>
> On Sunday, July 24, 2016 at 10:40:41 PM UTC-5, Mars0i wrote:
>>
>> spec/explain-data seems very important.  It allows programmatic responses 
>> to spec failures.  Maybe explain-data's behavior hasn't yet stabilized, 
>> though?  The structure of the return value has changed between 1.9.0-alpha7 
>> to the current 1.9.0-alpha10, the docstring is a bit vague, and the Spec 
>> Guide only talks about it very briefly.
>>
>
> explain-data is not in flux but as we are in alpha, it could still change.
>
> :path are path tags
> :via are specs
> :in are data keys
>
> At present, it's easy to figure out which test(s) has/have failed by 
>> examining the :path value(s) in explain-data's return value in some 
>> situations, such as when specs are combined using spec/keys or spec/or. In 
>> other situations--at least when specs are combined with spec/and,  the:path 
>> values are empty.  Unlike spec/or, there's no way to specify keywords that 
>> would identify the failed test.
>>
>> Am I right that explain-data is in flux?  Is the goal that in the future, 
>> it will always be possible for developers to specify composite specs in 
>> such a way that explain-data can return info that identifies the failed 
>> test clearly?  For example, in the first spec/and illustration below, maybe 
>> explain-data could use the names of the component specs as path elements?  
>> (Or am I just confused about something?)
>>
>
> As specs, the component spec path is recorded in :via.
>  
>
>>
>> Thanks-
>>
>> Example, using Clojure 1.9.0-alpha10:
>>
>> (s/def ::even even?)
>> (s/def ::zero-to-ten (s/int-in 0 10)) ; require number from 0 to 10 
>> inclusive
>>
>> user=> (s/explain-data (s/or :pred1 ::even :pred2 ::zero-to-ten) 11)
>> {:clojure.spec/problems
>>  ({:path [:pred1], :pred even?, :val 11, :via [:user/even], :in []}
>>   {:path [:pred2],
>>:pred (int-in-range? 0 10 %),
>>:val 11,
>>:via [:user/zero-to-ten],
>>:in []})}
>>
>> ;; Note that the format of the path entries are different above and below.
>> ;; Is there a reason for this difference, or will later versions return
>> ;; the same path elements?
>>
>
> Both examples seem consistent with my prior description of the data (specs 
> in :via, paths in :path, and data keys in :in). They are specs with 
> different structure so I would not expect them to yield the same explain 
> results.
>  
>
>> user=> (s/explain-data (s/keys :req-un [::even ::zero-to-ten]) {:even 11 
>> :zero-to-ten 11})
>> {:clojure.spec/problems
>>  ({:path [:even], :pred even?, :val 11, :via [:user/even], :in [:even]}
>>   {:path [:zero-to-ten],
>>:pred (int-in-range? 0 10 %),
>>:val 11,
>>:via [:user/zero-to-ten],
>>:in [:zero-to-ten]})}
>>
>> ;; Here there's nothing in the :path or :in sequences, although :via 
>> provides some information:
>>
>
> Yes, as expected.
>  
>
>> user=> (s/explain-data (s/and ::even ::zero-to-ten) 11)
>> #:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via 
>> [:user/even], :in []}]}
>>
>> ;; Note that only the first failed test is identified, which makes sense.
>>
>  
>
>>
>> ;; Another s/and example, with no info other than the value of :pred to 
>> indicate what test failed:
>>
>  
> What other info could be provided? You have the predicate and the invalid 
> value. If you had named the predicate, you would have more info.
>
> user=> (s/explain-data (s/and even? (s/int-in 0 10)) 11)
>> #:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via [], :in 
>> []}]}
>>
>
> user=> (s/def ::even even?)
> :user/even
> user=> (s/def ::irange (s/int-in 0 10))
> :user/irange
> user=> (s/explain-data (s/and ::even ::irange) 11)
> #:clojure.spec{:problems [{:path [], :pred even?, :val 11, :via 
> [:user/even], :in []}]}
>

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

Re: Arity count

[Alex Miller]

It might be helpful to back up a step and explain why you need to do this?

On Monday, July 25, 2016 at 10:14:16 AM UTC-5, Riccardo Di Meo wrote:
>
> Hi!
>
> It's a *very* old thread, but is there any news about this? I mean, is 
> there a way to find the list of accepted arities of an anonymous function, 
> without trying them all and catching the exception?
>

-- 
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: Arity count

[Riccardo Di Meo]

Hi!

Il giorno mercoledì 19 agosto 2009 21:16:35 UTC+2, John Harrop ha scritto:
>
> On Wed, Aug 19, 2009 at 10:03 AM, Achim Passen  > wrote:
>
>> Beware! This snippet relies on unexposed details of clojure's current
>> implementation. It might stop working tomorrow, so it's definitely not
>> intended for production use, but it might help with debbuging/exploring.
>
>
> Meanwhile, for declared functions this works:
>
> (map #(if (contains? (set %) '&) [:more (- (count %) 2)] (count %)) 
> (:arglists ^#'foo))
>
> giving results like:
>
> (0 2 5 [:more 7])
>
> (in this case for (defn foo ([] nil) ([glorb fuzzle] nil) ([x y z w u] x) 
> ([a b c d e f g & more] more)))
>
> Add this:
>
> (defn accepts-arity [arities arity]
>   (or
> (contains? (set arities) arity)
> (and (vector? (last arities)) (>= arity (second (last arities))
>
> and you can check if the function accepts a particular arity. (This 
> expects "arities" in the format output by my map expression. In particular, 
> a list of numerical arities and possibly a [:more n] entry, which must be a 
> vector and must be the last item in the list if present, and n must be the 
> number of required parameters for the "& more" overload.)
>
> Wrap it all up with two macros:
>
> (defmacro fn-arities [fn-name]
>   `(map (fn [x#] (if (contains? (set x#) '&) [:more (- (count x#) 2)] 
> (count x#))) (:arglists ^#'~fn-name)))
>
> (defmacro fn-accepts-arity [fn-name arity]
>   `(accepts-arity (fn-arities ~fn-name) ~arity))
>
> user=> (fn-accepts-arity foo 8)
> true
> user=> (fn-accepts-arity foo 6)
> false
> user=> (fn-accepts-arity reduce 2)
> true
> user=> (fn-accepts-arity reduce 3)
> true
> user=> (fn-accepts-arity reduce 4)
> false
> user=> (fn-arities map)
> (2 3 4 [:more 4])
>
> Works for macros, too:
>
> user=> (fn-arities fn-arities)
> (1)
> user=> (fn-arities fn-accepts-arity)
> (2)
>
> But, as noted, only works with a name of a declared fn or macro:
>
> user=> (fn-arities #(+ 3 %))
> # be cast to clojure.lang.Symbol (NO_SOURCE_FILE:110)>
>
> (One thing odd about that:
>
> user=> (class '#(+ 3 %))
> clojure.lang.PersistentList
>
> not Cons. Hmm.)
>
> It also doesn't work with local, named functions, either using let or 
> using letfn, even if (fn name [args] body) is used and not (fn [args] body):
>
> user=> (let [x (fn [a] (+ 3 a))] (fn-arities x))
> # context (NO_SOURCE_FILE:117)>
> user=> (let [x (fn x [a] (+ 3 a))] (fn-arities x))
> # context (NO_SOURCE_FILE:118)>
> user=> (letfn [(x [a] (+ 3 a))] (fn-arities x))
> # context (NO_SOURCE_FILE:119)>
>
>
It's a *very* old thread, but is there any news about this? I mean, is 
there a way to find the list of accepted arities of an anonymous function, 
without trying them all and catching the exception?

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.

[ANN] CIDER 0.13 (California) is out!

[Bozhidar Batsov]

Hey everyone,

In the middle of the summer (for my part of the world, at least) we've got
a hot new CIDER release for you. It's named after my beloved Republic of
California, where its development began. Here are the highlights for the
release:

### New Features

* Add an option `nrepl-prompt-to-kill-server-buffer-on-quit` to control
whether killing nREPL server buffer and process requires a confirmation
prompt.
* [#1672](https://github.com/clojure-emacs/cider/issues/1672): Allow
setting a preferred build tool when multiple are found via
`cider-preferred-build-tool`.
* Ensure Clojure version meets minimum supported by CIDER (1.7.0).
* Fringe indicators highlight which sexps have been loaded. Disable it with
`cider-use-fringe-indicators`.
* New command: `cider-inspect-last-result`.
* `cider-cljs-lein-repl` now also supports figwheel.
* Option `cider-jack-in-auto-inject-clojure` enables the user to specify a
  version of Clojure for CIDER. This allows the user to override the version
  used in a project, particular if it is lower than minimum required for
CIDER.
* Allow the ns displayed by eldoc to be tailored via
`cider-eldoc-ns-function`.
* After connecting a ClojureScript REPL, CIDER will try to figure out if
it's being served on a port and will offer to open it in a browser.
* [#1720](https://github.com/clojure-emacs/cider/issues/1720): Add a
command `cider-eval-sexp-at-point` to evaluate the form around point (bound
to `C-c C-v v`).
* [#1564](https://github.com/clojure-emacs/cider/issues/1564): CIDER's
internal namespaces and vars are filtered from the ns-browser and apropos
functions.
* [#1725](https://github.com/clojure-emacs/cider/issues/1725): Display
class names in eldoc for interop forms.
* [#1572](https://github.com/clojure-emacs/cider/issues/1572): Add support
for variables in eldoc.
* [#1736](https://github.com/clojure-emacs/cider/issues/1736): Show "See
Also" links for functions/variables in documentation buffers.
* [#1767](https://github.com/clojure-emacs/cider/issues/1767): Add a
command `cider-read-and-eval-defun-at-point` to insert the defun at point
into the minibuffer for evaluation (bound to `C-c C-v .`).
* [#1646](https://github.com/clojure-emacs/cider/issues/1646): Add an
option `cider-apropos-actions` to control the list of actions to be applied
on the symbol found by an apropos search.
* [#1783](https://github.com/clojure-emacs/cider/issues/1783): Put eval
commands onto single map bound to `C-c C-v`.
* [#1804](https://github.com/clojure-emacs/cider/issues/1804): Remember
cursor position between `cider-inspector-*` operations.

### Changes

* Simpler keybindings in macroexpand buffer. Expand one step with `m` and
all expansions with `a`. Previously was `C-c C-m` and `C-c M-m`.
* Signal an error sooner if the user misconfigured `cider-known-endpoints`.
* `cider-inspect-read-and-inspect` is obsolete. Use
`cider-inspect-expression` instead.
* Extremely long overlays are truncated and `cider-inspect-last-result` is
recommended.
* Signal `user-error` instead of `error` on jack-in if a project type is
not supported.
* Users with `boot.sh` instead of `boot` should customize
`cider-boot-command` instead of relying on automatic detection.
* [#1737](https://github.com/clojure-emacs/cider/issues/1737): Show value
of locals in debugger tooltip.
* Rebind `cider-eval-last-sexp-and-replace` to `C-c C-v w`.
* Rebind `cider-eval-region` to `C-c C-v r`.
* Rebind `cider-eval-ns-form` to `C-c C-v n`.
* [#1577](https://github.com/clojure-emacs/cider/issues/1577): Show first
line of docstring in ns browser.
* `cider-repl-closing-return` (`C-`) now also completes brackets
(`[]`) and curly braces (`{}`) in an expression.

### Bugs fixed

* [#1755](https://github.com/clojure-emacs/cider/issues/1755): Impossible
completion for multiple zombie REPL buffers.
* [#1712](https://github.com/clojure-emacs/cider/issues/1712): Bad
compilation issue caused when installed along with `nim-mode`.
* Fix arglist display for `def` in the doc buffer.
* Use `cider-apropos-select` instead of `cider-apropos` in
`cider-apropos-documentation-select`.
* [#1561](https://github.com/clojure-emacs/cider/issues/1561): Use an
appropriate font-lock-face for variables, macros and functions in
the ns-browser.
* [#1708](https://github.com/clojure-emacs/cider/issues/1708): Fix
`cider-popup-buffer-display` when another frame is used for the error
buffer.
* [#1733](https://github.com/clojure-emacs/cider/pull/1733): Better error
handling when no boot command is found in `exec-path`.
* Fix orphaned nrepl-messages buffer after `cider-quit`.
* [#1782](https://github.com/clojure-emacs/cider/issues/1782): Disable
mouse-over tooltips when `help-at-pt-display-when-idle` is non-nil.
* [#1811](https://github.com/clojure-emacs/cider/issues/1811): Handle
properly jack-in commands with spaces in them.

Thanks to everyone who made this release possible! I really appreciate all
of your help and hard work!

Enjoy!

*P.S.* I've heard a rumour that asking 

Re: Exception : cannot create ISeq from Long when empty list is present.. ?

[Ashish Negi]

Thanks James..

I will now add a vector after first..

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