Re: Sierra's Component

[Paul Stadig]

You can do either. If you pass the config as a dependency, then you have to
access it in the `start` method after dependency injection has occurred.

Sometimes it is useful to write a constructor function to initialize the
component. If that constructor needs access to the config it must be passed
to the function, not provided as a dependency.

On Sat, Apr 6, 2024, 1:00 AM dieter.v...@gmail.com <
dieter.van.ees...@gmail.com> wrote:

> Hello,  I'm playing a bit with the 'Component' library. The system has
> some initial configuration (port numbers, uri's, usernames,...) in code.
>
> I'm doubting to eighter pass configuration when constructing the system:
> (C/system-map
>  :mycomponent  (map->MyComponent {:conf ...})
>
> OR to pass configuration itself as a component
> (defrecord Config ...)
> (C/system-map
> :config ...
> :mycomponent
>(C/using (map->MyComponent ...) [:config])
>
> Is there any reason why to prefer one way over the  other or is it just
> personal preference?
>
> kind regards,
> Dieter
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/2abcf943-e885-4e17-9856-0247959115dcn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CADQBrAT3fcv10bbwESWf8AHJouzx_nKrTZbO9BZ04%3DoKMrH19g%40mail.gmail.com.

Re: variable name duplicate

[Paul Stadig]

I'm pretty sure what is happening is the Clojure compiler is munging "x-"
into "x_" but since you already have an "x_" you get an exception.

On Sat, Jul 30, 2022, 5:23 AM vinurs  wrote:

> hello,
> i have the following code:
> ```
> (let [x- 1 x_ 2] (fn [] [x- x_])) ; => Throws: Duplicate field name "x_"
> with signature "J" in class file [...]
> ```
> i tested from clojure 1.0.0 to the latest, all throw 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/72a4df10-b0a7-4886-b1aa-79e15f1f9c79n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CADQBrAQJK09mdp%3DLSTkUyEXFzNmQ78P-vU%3DbfjfgfVNjtKDZKA%40mail.gmail.com.

Book project : compilation of Rich Hickey conferences transcripts translated in french

[Paul schuhmacher]

Hi,

I am a French web developer, soon a teacher, IT books and standards 
enthusiast.

I've listened many times to many of Rich Hickey conferences. It took me 
time and mental efforts to understand those ideas and concepts, but now I 
can say that I consider Rich Hickey to be on of the most precious (public 
at least) thinker and artisan in the IT. So for that, I want first to thank 
him to have shape my mind to fascinating new horizons.

I want to make the ideas and concepts discussed in those conferences 
accessible for a French-speaking audience. I think many people (besides 
programmers) interested from near or far to information systems would 
benefit from this content. I'm rather surprised to realize that even if 
understanding/reading English language is a "must have" for any developer 
around the world, still many French-speaking developers and IT people are 
not able to "read" (in the general sense) with ease many English textbooks 
or conferences. I would like to contribute to feel that gap by translating 
and publishing some content found in those conferences for this audience, 
because this work is highly valuable, and I think need to be better known 
by many IT people.

I've already made a French subtitle version of the conference "The Value of 
Values" (Jax Conference, 2012) available on YouTube (link: 
https://www.youtube.com/watch?v=VJi1vOwu2SM). I've been doing caption for 
many years now. Mainly I have caption 5 of 7 of the Feynman Lectures on 
Physics conference (1964) (I'm an ex physicist and big fan of Richard 
Feynman...) (link: 
https://www.youtube.com/watch?v=GSeSqqUV7_4=PLS3XEhTy6-AkS1j8JrHoJnkSrY31Bfddl).
 
And I saw that many people were hungry for this wonderful and rich content 
(as your work) they cannot access otherwise.

I would like, in the near future, to work on a compilation of transcripts 
of some of Rich Hickey conferences (based on some themes), translated in 
French. The idea I have in mind is to try to publish a small book in French 
in the same idea as the book "La nature de la physique", a French 
transcript compilation of the Feynman Lectures on Physics.

I wanted to know if Rich Hickey (or any other people involved) would be 
interested to see this project happening or not, and if there are any legal 
questions, constrains etc...

Thank you for reading this way too long message,

I wish you a very pleasant day,

Best regards,

Paul Schuhmacher

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/b08a6176-0a47-4e7c-a4e7-26b15024b26an%40googlegroups.com.

Re: [?] alter-var-root and *out*

[Paul Stadig]

`*out*` may have a thread binding established. REPLs will often do this.

If `*out*` is thread bound you should be able to use `thread-bound?` to
check that and then `set!` to set it, but you have to be careful because
https://clojure.atlassian.net/browse/CLJ-1077

On Wed, Sep 1, 2021 at 4:58 AM Philos Kim  wrote:

> I can change my dynamic var with alter-var-root like this.
>
> (def ^:dynamic *x* "abc")
> (alter-var-root #'*x* (constantly "xyz"))
> *x*
> ; => "xyz"
>
>
> However, I cannot change *out* with alter-var-root.
>
> (alter-var-root #'*out* (constantly "xyz"))
> *out*
> ; => #object[java.io.PrintWriter 0x6957ec80 "java.io.PrintWriter@6957ec80
> "]
>
>
> I expected the result to be "xyz" but the result of *out* doe not change
> at all
>
> Can anyone explain to me why?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/23d13e9b-6eb8-4a39-b00d-8fead541e18en%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CADQBrARn_ysTOsvk-CVrekb69k-ZMyxmNa%2BEcMZB_kabCykLKw%40mail.gmail.com.

Re: Strange result for clojure.core/time

[Paul Stadig]

The output of `time` is in milliseconds and the output of
`with-timer-print` is in seconds. So to make them comparable:
`time` 0.01344 msec
`time` with eval 0.922536 msec

`with-timer-print` 0.048 msec
`with-timer-print` with eval 1.041 msec

The `with-timer-print` version is slower, and I suspect it is the use of
`format` instead of `str`.

Paul

On Fri, Apr 10, 2020 at 8:46 PM Alan Thompson  wrote:

> I was doing some macro work and was curious about the cost of an inline
> `eval` vs compiled code.  I tried to time it with `clojure.core/time` and
> got results I can't explain:
>
>
> (println :eval-time)
> (time
>   (do
> (println (eval (quote (+ 40 0
> (println (eval (quote (+ 40 1
> (println (eval (quote (+ 40 2
> (println (eval (quote (+ 40 3
> (println (eval (quote (+ 40 4))
>
>
> :eval-time
> 40
> 41
> 42
> 43
> 44
> "Elapsed time: 0.922536 msecs"
>
> On a modern computer, this is an insanely long amount of time. And yes, it
> is approx 5x longer than doing just one line of the above.  I also tried it
> without the eval:
>
> (println :add-time)
> (time
>   (do
> (println (+ 30 0))
> (println (+ 30 1))
> (println (+ 30 2))
> (println (+ 30 3))
> (println (+ 30 4
>
>
> :add-time
> 30
> 31
> 32
> 33
> 34
> "Elapsed time: 0.01344 msecs"
>
> Still seems pretty slow to just print 5 lines with a single addition each.
>
> The `time` macro is very simple, and is often used as introductory example
> of how macros work and when they are needed:
>
> (defmacro time
>   "Evaluates expr and prints the time it took.  Returns the value of
>  expr."
>   {:added "1.0"}
>   [expr]
>   `(let [start# (. System (nanoTime))
>  ret# ~expr]
>  (prn (str "Elapsed time: " (/ (double (- (. System (nanoTime)) start#)) 
> 100.0) " msecs"))
>  ret#))
>
>
> I coincidentally had a homegrown timer available with nearly identical
> code.  It has results:
>
> (prof/with-timer-print :add-prof
>   (do
> (println (+ 10 0))
> (println (+ 10 1))
> (println (+ 10 2))
> (println (+ 10 3))
> (println (+ 10 4
>
>
> 10
> 11
> 12
> 13
> 14
> :with-timer-print :add-prof 0.48
>
>
>
> and
>
> (prof/with-timer-print :eval-prof
>   (do
> (println (eval (quote (+ 20 0
> (println (eval (quote (+ 20 1
> (println (eval (quote (+ 20 2
> (println (eval (quote (+ 20 3
> (println (eval (quote (+ 20 4))
>
>
> 20
> 21
> 22
> 23
> 24
> :with-timer-print :eval-prof 0.001041
>
> So we see the times are much, much shorter.  The timing code is nearly
> identical to clojure.core/time:
>
> (defmacro with-timer-result
>   "Times execution of Clojure forms, returning a result map like:
>   {:result result  :seconds seconds} "
>   [& forms]
>   `(let [start#   (System/nanoTime)
>  result#  (do ~@forms)
>  stop#(System/nanoTime)
>  elapsed# (double (- stop# start#))
>  seconds# (/ elapsed# 1e9)]
>  {:result  result#
>   :seconds seconds#}))
>
> (defmacro with-timer-print
>   "Times execution of Clojure forms, printing the result to the screen. "
>   [id & forms]
>   (when-not (keyword? id)
> (throw (ex-info "id must be a keyword" (vals->map id
>   `(let [result-map# (with-timer-result ~@forms)]
>  (println (format ":with-timer-print %s %12.6f" ~id (grab :seconds 
> result-map#)))
>  (grab :result result-map#)))
>
>
> Does anyone have an idea of why `clojure.core/time` gives such insanely
> inflated results?
>
> Alan
>
> PS.  I ran the above 4 sequences multiple times using lein-test-refresh,
> and these were the shortest I could get.  I'm pretty confident the answer
> is not loading, compiling, or JIT related.
>
>
>
> --
> 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.
> To view

[ANN] electron-app 1.0.0

[Paul Butcher]

I’ve just published a clj template for for an Electron application 
built with deps.edn, Figwheel Main, Reagent, and test integration via 
cljs-test-display:


https://github.com/paulbutcher/electron-app

--
paul.butcher->msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher

Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel
http://pragprog.com/book/pb7con

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/EF92C90B-4E7F-4C5C-944A-728B024451CB%40paulbutcher.com.

[ANN] com.vodori/schema-forms "0.1.0" - Convert prismatic schemas to JSON schema for react-jsonschema-form

[Paul Rutledge]

Schema-forms is a library for converting prismatic schemas into JSON schema 
that's compatible with Mozilla’s react-jsonschema-form component. It’s 
probably best suited for generating admin interfaces and the like. Feedback 
welcome!

You can find more information in the readme: 
https://github.com/vodori/schema-forms


Cheers!

-- 
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] Calfpath (v0.7.1), a fast and flexible Ring request router

[Paul deGrandis]

Hi Shantanu,

Interesting project and congrats on the release!

I think Alan was asking more about the runtime and space complexities.  
What is the core approach used in Calfpath?  What is the runtime and space 
complexity?  What are the ideal operational conditions and under what 
conditions does it suffer?  What were the trade-offs made in the approach?

I'm curious to know the answers myself.  Thanks!

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

[ANN] com.vodori/reactors 0.1.0

[Paul Rutledge]

Vodori released [com.vodori/reactors "0.1.0"]. It’s our take on a reactive 
store (events/reducers/subscribers) atop clojure agents with event 
producers and subscribers expressed as core.async channels. As an example, 
we use it with database change streams as our event producers and 
websockets as our subscribers to provide live collaboration between users 
annotating files. 

https://github.com/vodori/reactors

Cheers!

-- 
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: IF, WHEN or SOME

[Paul Rutledge]

I haven't used them much myself but the idea of "reified control flow" is 
called a continuation . Some 
other lisps implement continuations, Clojure does not. I'm sure there's 
plenty of material out there about why Clojure/Rich did not provide 
continuations.


On Monday, December 11, 2017 at 5:56:29 PM UTC-6, Stephen Feyrer wrote:
>
> Hi there,
>
> I have been trying to shake this thought for a while now.  Essentially, my 
> thought was if you can return a function why not decision component of an 
> IF, WHEN or SOME statement?  That would give you a re-usable named choice.
>
> Then you could write:
>
> (celebration: do-something do-something-else)
>
>
> This would be equivalent to writing:
>
> (def success [apples bananas pears])
>
> (defn celebration: [x y] (if (empty? success) x y))
>
> (celebration: (do-something do-something-else))
>
>
> I'm reasonably certain of the foolishness of this thought but 
> occasionally, I have doubts.
>
> Maybe I'm barking up the wrong tree or possibly I've seen something like 
> this before and forgotten about it.  Perhaps, this is just taking things 
> too far...  Either way, it's deferring the choice until it's needed.  In 
> the right hands it could make for more readable code.
>
> For completeness sake, to define the first form above you'd use:
>
> (defc celebration: (if (empty? success)))
>
>
> A more usable example might look like:
>
> (def nums [1 2 3 4 5 6 7 8])
>
> (defc even-nums: (some (even? nums)))
>
> I guess this makes the real question, is it a good thing to be able to 
> defer choice like this?
>
>
> Btw, defc would be like def-choice but other options might be deft - 
> def-test or defp - def-predicate.
>
>
> --
> Kind regards
>
> Stephen
>

-- 
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] com.vodori/chronology "0.1.0"

[Paul Rutledge]

Chronology is a small library for working with cron expressions and 
scheduling tasks. It provides infinite sequences of cron expressions (both 
forwards and backwards!) and provides a small layer to schedule functions 
as periodic tasks using core.async machinery.

https://github.com/vodori/chronology

Cheers!

-- 
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] Missing 0.1.0 - utility functions, transducers, locking by value, and topological sorting

[Paul Rutledge]

Missing is a lightweight complement to clojure.core containing general 
purpose functions and macros along similar veins of medley, plumbing, 
flatland, etc.

   - https://github.com/vodori/missing


Vodori has been building products in Clojure for the last ~2 years and will 
be open sourcing several of our libraries in the coming weeks.

Cheers!

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

core.async pipeline bug?

[Paul Rutledge]

Hi all,

I've been using the 'pipeline' function in core.async and the docstring 
says that the 'from' channel won't be consumed anymore after the 'to' 
channel is closed (since you probably don't care anymore). In reality, I'm 
finding that my 'from' channel is still being taken from and the pipeline 
transducer continues to execute long after I've closed the 'to' channel. Am 
I misunderstanding the stated behavior or is this a bug? I'm using the 
latest version (0.4.474). If someone can confirm this is an issue I'm happy 
to create a jira ticket and attempt a patch.

Minimal example here: 
https://gist.github.com/RutledgePaulV/6ddb7b29578de4442cd8d946885c38a8

Thanks,
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: [ANN] clj-embed | segmented clojure runtimes inside a single JVM process

[Paul Rutledge]

It certainly does seem like they overlap a lot! 

I'll have to take a closer look at pods to see what things I'm not solving 
well yet :)

Thanks!


On Sunday, December 3, 2017 at 6:09:27 PM UTC-6, Andrea Richiardi wrote:
>
> Haven't check the code, but this is similar to what boot pod is: 
> https://github.com/boot-clj/boot/wiki/Pods
>
> The nice thing is that it uses tools.deps, good job!
>

-- 
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] clj-embed | segmented clojure runtimes inside a single JVM process

[Paul Rutledge]

I've been looking for something that would let me create REPL sessions that 
couldn't easily mess with the namespaces already being used by the process 
that's hosting the REPL server. That eventually led me to look at 
https://github.com/projectodd/shimdandy but the readme told me I couldn't 
have Clojure on the classpath when it starts or else it'd be sharing RT 
even for the new class loaders. clj-embed is a thin layer around shimdandy 
that builds a more isolated class loader and loads dependencies at runtime 
using the new https://github.com/clojure/tools.deps.alpha. The result is 
easy "isolated" runtimes (but *not* a secure sandbox). This shouldn't be 
considered production quality and I'm interested in feedback from those who 
know more about Clojure's internals and the nuances of class loaders!

I published a snapshot version to clojars if you'd like to give it a try 
and you can find the code / readme here:

https://github.com/RutledgePaulV/clj-embed


Cheers!


-- 
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: Java learning resources for Clojurists?

[Paul Gowder]

Oh, thank you, that looks like a great resource!

On Tuesday, August 15, 2017 at 9:24:45 PM UTC-5, Daniel Compton wrote:
>
> Eric Normand has a course "JVM Fundamentals for Clojure" which might be 
> useful? https://purelyfunctional.tv/courses/jvm-clojure/
>
> On Wed, Aug 16, 2017 at 2:20 PM Paul Gowder <paul@gmail.com 
> > wrote:
>
>> Hi there, 
>>
>> Can anyone recommend decent resources for learning Java for experienced 
>> Clojurists who don't do enough interop?  
>>
>> After writing Clojure for about a year and a half, I find that the most 
>> continuous barrier I encounter is in understanding how to drop down to the 
>> JVM.  And it's even a barrier in using some core CLJ libraries.  
>>
>> Here's an illustration of the problem I often have.  I was writing a web 
>> application using Reagent/Immutant, and I wanted to pass data from frontend 
>> to backend over a websocket in transit format. But the only example in the 
>> github readme for Transit-CLJ involves dealing with data as a Java 
>> bytestream.  And it was just too daunting to try to figure out what flavor 
>> of JVM string the stuff being received over the websocket was under the 
>> hood, how to cast it into a bytearrayinputstream or whatever else can fit 
>> into a transit "writer," etc. Or even just like where to start translating 
>> from "here, I have a Clojure string" to "oh god, now it has to turn into 
>> some kind of low-level object that isn't a string and isn't a file but is 
>> something in between and maybe it has to be a stream and maybe it doesn't 
>>
>> Yet almost all "how to learn java" materials I can turn up seem to be 
>> directed at total beginner programmers, and start with stuff like "here's 
>> what a for loop is" rather than practical stuff like "here's how to sort 
>> out the different kinds of array-whatsits and byte-whatsats" or "here's how 
>> the entry point of a java library works" or whatnot. 
>>
>> I'm hoping there's something out there (that goes a bit deeper than the 
>> wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that 
>> someone can recommend.
>>
>> thanks!
>>
>> -Paul
>>
>> -- 
>> 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.

Java learning resources for Clojurists?

[Paul Gowder]

Hi there, 

Can anyone recommend decent resources for learning Java for experienced 
Clojurists who don't do enough interop?  

After writing Clojure for about a year and a half, I find that the most 
continuous barrier I encounter is in understanding how to drop down to the 
JVM.  And it's even a barrier in using some core CLJ libraries.  

Here's an illustration of the problem I often have.  I was writing a web 
application using Reagent/Immutant, and I wanted to pass data from frontend 
to backend over a websocket in transit format. But the only example in the 
github readme for Transit-CLJ involves dealing with data as a Java 
bytestream.  And it was just too daunting to try to figure out what flavor 
of JVM string the stuff being received over the websocket was under the 
hood, how to cast it into a bytearrayinputstream or whatever else can fit 
into a transit "writer," etc. Or even just like where to start translating 
from "here, I have a Clojure string" to "oh god, now it has to turn into 
some kind of low-level object that isn't a string and isn't a file but is 
something in between and maybe it has to be a stream and maybe it doesn't 

Yet almost all "how to learn java" materials I can turn up seem to be 
directed at total beginner programmers, and start with stuff like "here's 
what a for loop is" rather than practical stuff like "here's how to sort 
out the different kinds of array-whatsits and byte-whatsats" or "here's how 
the entry point of a java library works" or whatnot. 

I'm hoping there's something out there (that goes a bit deeper than the 
wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that 
someone can recommend.

thanks!

-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: slackpocalypse? (Alternatives to Slack like Matrix.org)

[Paul Fernhout]

Here is an essay I wrote in January 2016 against using Slack for FOSS
(which cites that Ryver page): 
http://pdfernhout.net/reasons-not-to-use-slack-for-free-software-development.html

The biggest practical issue (ignoring philosophical ones or theoretical
ones) is probably "Slack is focused on teams, not communities".

The essay mentions some FOSS alternatives including Mattermost (which
can import Slack history) and Matrix.org (which is decentralized). 

Perhaps someone knows if there is already a Clojure/ClojureScript
frontend to Matrix.org? :-)

--Paul Fernhout (pdfernhout.net)
"The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity."

On 18.05.2017 17:31, Gregg Reynolds wrote:

> looks like access is restored, for me at least.  still, slack is making me a 
> little nervous. and that's in addition to the 10K msg limit, which is a pain. 
>  anybody know antything about ryver? https://ryver.com/ryver-vs-slack/ 
> 
> On May 18, 2017 3:15 PM, "Gregg Reynolds" <d...@mobileink.com> wrote:
> 
>> is it just me? i've been unable to connect to clojurians (by cellphone) for 
>> about 30 minutes, but i can connect to other slack groups. 
>> 
>> have we hit 
>> https://github.com/clojurians/clojurians-chat/wiki/Slackpocalypse [1]?  
>> we're almost to 10K subscribers. 
>> 
>> g
 

Links:
--
[1] https://github.com/clojurians/clojurians-chat/wiki/Slackpocalypse

-- 
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: with-open pattern

[Paul Stadig]

Hey Brian,
The fact that a reducible (as I have implemented it in the reducible-stream 
library) will fully realize itself if it is used as a sequence is a 
drawback that I'm not happy with. In the back of my mind I believe there 
may be a way around it, but I'm not sure, and it is still a topic of 
further thought/research for me. However, I think it can easily be avoided.

The point of using a reducible instead of a sequence is to invert the 
control so that the collection is in charge of processing itself. When you 
use a reducible as a sequence you are processing the collection externally, 
making the collection responsible only for doling itself out one item at a 
time, which it cannot do if it must also manage the scope for some resource 
(like a connection) that must be closed.

I would suggest that you have more processing that needs to be pushed into 
the reduction process. So, instead of getting a database result set, 
processing it in some way, and then trying to pass it as a sequence into 
Ring (I'm not sure if this is exactly your problem, but I think it is 
representative?), where Ring will want to consume that sequence, which will 
trigger it to fully realize in memory---instead push the work that Ring 
would be doing into the reduction process. So, reduce over the result set 
with an output stream (or one end of a piped output stream), and in the 
reduction process write to the stream. Ring takes the other end of the pipe 
and consumes the stream to produce its result.

A reducible is a delayed computation, and with transducers or by other 
means you can layer more delayed computation onto the reducible. As soon as 
you fire the reducible it will produce its entire result, whether the 
firing is because of a call to `reduce` or `seq`. A reducible is like a 
spring with potential energy built in, and when it is sprung it springs. A 
lazy sequence is like a wheel, if you apply external force to it, it will 
turn, but otherwise it is inert. Probably a terrible analogy, but that's 
the best I can come up with. :)

I hope that's helpful.


Paul

http://www.realworldclojure.com/
http://paul.stadig.name/
@pjstadig

On Thursday, May 4, 2017 at 3:04:40 PM UTC-4, Brian Craft wrote:
>
> It's definitely the same problem, but I don't think it helps me. This 
> part, in particular:
>
> "If you treat this object like a sequence, it will fully consume the input 
> stream and fully realize the decoded data in memory."
>
> I'm specifically trying to avoid realizing the full collection in memory, 
> because it won't fit.
>
> On Thursday, May 4, 2017 at 11:22:36 AM UTC-7, Josh Tilles wrote:
>>
>> I think the “reducible streams” approach described by Paul Stadig here 
>> <http://paul.stadig.name/2016/08/reducible-streams.html> has potential. 
>> It might not cover all of the scenarios you’re thinking of, though.
>>
>> On Thursday, May 4, 2017 at 1:35:48 PM UTC-4, Brian Craft wrote:
>>>
>>> The with-open style is used a lot in the jdbc lib, and elsewhere. It's 
>>> pretty simple when data is very small, as you can just evaluate the entire 
>>> result with doall, etc.
>>>
>>> How do you deal with larger data, where you need to evaluate 
>>> iteratively? If there's only one with-open it can be reasonably simple to 
>>> pass the consumer into that context (though from ring it's pretty 
>>> convoluted, due to needing to pass control to ring first). But if there are 
>>> multiple with-open you have to nest them, with a continuation passing 
>>> style, or middleware pattern, or something, which quickly becomes onerous 
>>> as it affects all the code surrounding the with-open.
>>>
>>> Is there some simpler pattern?
>>>
>>

-- 
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: Cognitect acquired by Microsoft

[Paul Gowder]

AMAZING.

-- 
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: Combinatorics partitions that preserves adjacency?

[Paul Gowder]

For sake of completeness/if this is useful for anyone else, a full 
implementation of the number-the-possible-split-locations method, including the 
original API with :min and :max options. Could probably be tidied up with 
transducers and such for all those filters but does the job. 

(require '[clojure.math.combinatorics :as c])
(defn breaks->partition 
  ([v brks]
   (breaks->partition 0 [] v brks))
  ([start pars v brks]
   (if (empty? brks)
 (conj pars (subvec v start (count v)))
 (let [this-part (subvec v start (first brks))]
   (recur (first brks) (conj pars this-part) v (rest brks))

(defn min-parts [min splits]
  (>= (count splits) (- min 1)))

(defn max-parts [max splits]
  (<= (count splits) (- max 1)))

(defn ordered-partitions [v & {:keys [max min]}]
  (let 
[s (c/subsets (range 1 (count v)))
 fs (cond
  (and max min) 
  (filter 
(partial max-parts max) 
(filter (partial min-parts min) s))
  max (filter (partial max-parts max) s)
  min (filter (partial min-parts min) s)
  :else s)]
(map (partial breaks->partition v) fs)))

It does, alas, take more than 10 times as long as Mike's version.  Which proves 
that one should never try to do anything faster than the core.matrix guy.  :-) 

-- 
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: Combinatorics partitions that preserves adjacency?

[Paul Gowder]

Ooh, thank you---those are both lovely solutions! 

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

Combinatorics partitions that preserves adjacency?

[Paul Gowder]

Hi everyone, 

Does anyone know of a straightforward way to get something like 
clojure.math/combinatorics/partitions that works more like partition in the 
core library, that is, that only selects partitions with adjacent elements?

In other words, right now this is the problem:

(require '[clojure.math.combinatorics :as c])
(c/partitions [:a :b :c] :min 2)

=> (([:a :b] [:c]) ([:a :c] [:b]) ([:a] [:b :c]) ([:a] [:b] [:c]))

But that ([:a :c] [:b]) there in the second position isn't a proper partition 
because :a and :c aren't adjacent in the original vector.  

I feel like there's got to be a standard, canonical solution for this, or some 
existing sequence or combinatorics function with a funny name that just returns 
(([a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c])) in this situation.  I just 
don't know it... 

The best I can come up with is kind of a hackish workaround that only works 
when the original vector is sorted, namely, flattening all the partitions and 
testing to see whether they are sorted too, i.e.: 

(require '[clojure.math.combinatorics :as c])

(defn test-fn [part]
  (let [f (flatten part)]
(= f (sort f

(filter test-fn (c/partitions [:a :b :c] :min 2))

=> (([:a :b] [:c]) ([:a] [:b :c]) ([:a] [:b] [:c]))  ; Yay! :-)

And that works, but, as noted, only when the original vector is sorted.  What 
if someone wanted to preserve adjacencies in an unsorted vector?

All thoughts appreciated, thanks!

Cheers,

-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: ANN: ClojureScript 1.9.456, Externs Inference & Comprehensive JS Modules Support

[Paul Gowder]

Yeah, this is a recurrent problem---as far as I can determine, several database 
libraries (at least) have a dependency a layer or two down on an old version of 
guava; the latest closure compiler seems to be depending on the most recent 
guava. See eg this issue (which ai've been meaning to pr...) 
https://github.com/clojurewerkz/support/issues/4

-- 
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] Vase: data-driven microservices

[Paul deGrandis]

I'm very pleased to announce the availability of Vase 
<https://github.com/cognitect-labs/vase> - a library for writing 
declarative, data-driven microservices.
With Vase, HTTP services can be created within minutes, complete with 
database integration and data validation.

I first described Vase over two years ago at Clojure/Conj 2014 
<https://www.youtube.com/watch?v=BNkYYYyfF48>.  Since then, Vase has proven 
to be a valuable tool as we continually developed it.
Vase should be considered beta technology - It has been used on real-world 
projects.  Each new project teaches us something more about what Vase can 
do. We're continuing to improve its utility and usability. You may find 
some rough edges here and there -- when you do, raise an issue so we can 
make it better.

Full details can be found in the blog post <http://bit.ly/2jqHeV6>.

Stable versions are currently deployed to the Clojars repository.


Leiningen <https://github.com/technomancy/leiningen> dependency information:

 [com.cognitect/vase  "0.9.0"]


<http://maven.apache.org/>

Maven <http://maven.apache.org/> dependency information:


  com.cognitect
  vase
  0.9.0


*Getting Started:*
Details for getting started with Vase 
<https://github.com/cognitect-labs/vase#getting-started> can be found on the 
project’s GitHub page.
The project has a Leiningen/Boot template: lein new vase my-service


To help you get going, see the "Todo" sample application 
<https://github.com/cognitect-labs/vase/tree/master/samples/omnext-todo>.
- - - - - - 

Thanks to everyone who helped make Vase what it is today and watch for upcoming 
enhancements!

Cheers,
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: [ANN] Nightcoders.net, a cloud IDE for ClojureScript

[Paul Gowder]

That's really cool!  The autosave is sweet.  So is the fact that I can get 
it to work on ios---I was just thinking about buying an ipad pro and 
figuring out good ways to code on it... this could be a really cool 
solution for starting something on a real computer, leaving it in the 
cloud, working on it on the ipad, etc.  

The oauth doesn't seem to work for me in chrome (on sierra with a ton of 
ad-blockers and such, so that might be giving grief)---I hit the sign in 
button, it pops up the standard google account chooser, I choose an 
account, then the window closes and nothing happens.  But it works in 
safari just fine (with the same double-click issue reported elsewhere in 
this thread). 

Oh, one other little thing I noticed... it's not obvious how to close a 
project and get back to the first screen, like to start on a different 
project.  I ended up just hitting the back button then reload...

This is amazing!

On Wednesday, January 4, 2017 at 10:20:20 AM UTC-6, Zach Oakes wrote:
>
> Cloud IDEs are becoming more common. To quote the rifleman's creed, there 
> are many others like it, but this one is mine:
>
> http://nightcoders.net/
>
> It's basically a hosted version of Nightlight, running the compiler on my 
> server so you can build CLJS projects using nothing but a web browser. I'm 
> aiming at beginners, much like I did with the original Nightcode, but this 
> time I'm going further by eliminating all setup requirements.
>
> Please be gentle with it. I've only been working on this for the past few 
> weeks while vacationing in mexico...mostly as a distraction while my body 
> convulsed over the somewhat unhygienic street food I gave it. I spent a lot 
> of time in the bathroom. That may be oversharing. Oh well.
>
> Enjoy!
>

-- 
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: Closure for object pattern? A good idea?

[paul]

Let me add a couple of comments, both from a clojure perspective and from 
other languages.

First, I have used this pattern in clojure and similar languages. I find it 
is often useful when I need to deal with multiple functions mutating the 
same state. In clojure, I used this to make little sloppy UI objects that 
all reference the same paintable thing, for instance. That ((:reset-state 
drawable-thingy) 13) was a quick and casual thing.

But it encourages you to use one of the functional programming 
anti-patterns (which is very common in OO languages): A function of no 
arguments with no return value. If you want your functions to be pure and 
side-effect free, then you know that a function with no return value does 
nothing. (Or more concisely, if it does something it does it through a side 
effect, so it isn't pure and side effect free). And pure and side effect 
free functions are useful for a variety of reasons. And one of the things 
clojure has worked hard to do (and one of my favorite features of the 
language) is to embrace this by having immutable structures everywhere. 
This then allows the STM implementation and a bunch of good stuff. 

So I'd say your pattern isn't very idiomatic, or perhaps is only idiomatic 
if you want to encapsulate mutable state with a set of cooperating 
functions without declaring a protocol.

Instead what you could do, as Logan points out, is separate your state 
(which is returned by a no-arg constructing function) from your 'modifiers' 
(which really clone and return a modified version.

But there's one problem you run into in the client code you posted.

Rather than the full stopwatch version, here's a very similar counter 
pattern.

(defn counter []
  {:count 0}
  )
(defn icount [counter]
  (update counter :count inc))
(defn dcount [counter]
  (update counter :count dec))
(def getcount :count)

(-> (counter) (icount) (icount) (dcount) (icount) (getcount))

OK so that returns 2 as we would expect. But if you want to use this inside 
your code, you need to 'stow away' the counters somewhere. Lets say you 
have something like (* (inc 2) 4) and you want to intersperse those counts. 
I end up with something that looks like this

(let [ct (counter)
  a 2
  ct (icount ct)
  b (inc a)
  ct (icount ct)
  d (* 4 b)
  ]
  [ d (getcount ct) ]
  )

And in your original example, where you are calling start and stop in what 
is basically procedural code that gets a bit nasty.

Where to put that counter is actually a problem which is section 2.3 of a very 
famous pape r, 
and it seems those ideas are kicking around the clojure community too, 
unsurprisingly.

But if you don't want to dive into that, you can still end up making your 
program easier by keeping your state and count in a map and then having an 
operator to count the functions.


(defn value-counter [ivalue]
  {:count 0 :value ivalue}
  )
(defn icount [counter]
  (update counter :count inc))
(defn dcount [counter]
  (update counter :count dec))
(def getcount :count)


(defn count-ops [c f & arguments ]
  (let [cn (icount c)
nv (apply f (:value cn) arguments)
]
(assoc cn :value nv)
)
  )

(-> (value-counter 2)
(count-ops inc)
(count-ops * 4)
)

Which returns { :count 2 :value 12 } as you'd hope.

Hope that helps!

On Sunday, December 11, 2016 at 2:41:14 AM UTC-5, Didier wrote:
>
> Logan's point about being able to add new functions on a stopwatch is 
> valid. That's often the argument to why protocols are better then classic 
> OO. Though I still feel like in some scenarios, I think this is a good 
> pattern, and can serve us better, the stopwatch being one good example.
>
> Nothing in the pattern necessitate this to be mutable either, though I 
> guess this pattern does seem to have some of its advantages from when you 
> need mutability for some reason. Then I like how it isolates the mutable 
> data behind the functionality.
>
> It feels like a lighter weight version of both OO and protocols/records. 
> I'm curious to benchmark it against records, which is what I would have 
> used before for something like a stopwatch.
>
> I think this could come in handy when doing libraries with options. My 
> current pattern was to have a function create an options, and then the user 
> would need to manage the options map, and pass it to all my library 
> functions. Or I would use a var instead the library to store the options 
> map, and offer it as a binding so users could rebind their own options. The 
> problem with the latter is that you can't run the library with two 
> different option set at the same time, while the former forces you to have 
> to manage an options map and pass it around everywhere. So I feel there's 
> something I could do here, with wrapping everything in this pattern, and 
> having the options be captured in the closure.
>
> On Friday, 9 December 2016 23:47:34 UTC-8, Didier 

Re: Errors

[Paul Walker]

Very useful. So it is a *bit* philosophical :) I guess the unabashedly hosted 
philosophy is one I wasn't so sure was intentional but it's good to understand; 
and embracing that changes the way you'd teach or introduce the language. 
Gotcha. Where I thought I "had to form" a dual mental model and I should have 
thought I "got to learn" one quickly. Cool!

And yeah lazyness and locality of error is always always hard. 

I loved elenas talk. At about the 16 minute mark she takes to task exactly the 
message I picked. Her solution looks tricky for non-instructional uses though, 
like when she rebinds map. And a big pile of stack regexps is tricky to 
maintain beyond teaching use cases I could imagine.

Anyway, thanks for the links and thanks for the thoughtful answers. I really 
appreciate it. It has me thinking.

Be well,

  - Paul

> On Dec 6, 2016, at 10:54, Alex Miller <a...@puredanger.com> wrote:
> 
> 
>> On Tuesday, December 6, 2016 at 5:55:52 AM UTC-6, Paul Walker wrote:
>> Wow thank you for the fulsome responses
>> 
>> A couple of thoughts. I brashly said
>> 
>> > I cherrypicked a case where the runtime difference would be tiny
>> 
>> and I appreciate the clarifications - especially that my naive 
>> add-one-bytecode calculation in my head (the code I pasted has a pretty 
>> meaty “analyze” call called before it every time which is why I thought I 
>> cherry-picked) didn’t think about things like byte code inlining or, really, 
>> the pile-of-sand one-more-bytecode syndrome. So thanks for that!
> 
> I think in the case you picked that you're right that the performance impact 
> is minimal. This happens at compile-time and generally we are less sensitive 
> there than in calls during the runtime. Colin's talk from last year's conj 
> gives a good idea of some of the challenges in working on this stuff. 
> https://www.youtube.com/watch?v=kt4haSH2xcs
>  
>> And my favorite response from Alex:
>> 
>> > If I can make a request, it would be that instead of saying "errors are 
>> > bad" (which is honestly, not helpful by itself), but to step back and 
>> > either take a broader approach towards systemic issues
>> 
>> This is so reasonable I’m embarrassed I was a bit glib in my first note. I 
>> mean it’s not like they are C++ template errors from 1998  (my gold standard 
>> for bad errors). So let me expand on “bad” a little. 
>> 
>> I think the error messages are “bad” in 3 particular but related ways. I’d 
>> be happy to expand on these, but the themes are:
>> 
>> 1: They are “large” and “far from my code”. This is partly an issue with 
>> java stack traces, but the intermixing of java and clojure and the 
>> presentation of clojure names in java name-like things in the stacks is 
>> obscuring. The line numbers are obscured instead of displayed prominently. 
>> And so on.
> 
> Personally, I don't have a problem with stack traces - there's a ton of 
> useful information in a stack trace. The issues of "distance from code" are 
> interesting in Clojure though. One area I mentioned is due to errors in 
> macros where it reports either the error in the macro rather than in the 
> source OR where you get a runtime code that is based on code that was written 
> by the macro (not by you). The first problem is significantly improved by 
> spec. Another source of "distance" is laziness - sometimes a nested operation 
> will not error until a lazy seq is forced, possibly far from the core of the 
> problem. Eager transformations (we have more options for this now with 
> transducers) can help with that, as can spec in reporting more accurately the 
> error when it occurs.
>  
>> 2: Similarly, they expose internals of the runtime implementation to the 
>> user. Stacks intertwine java and clojure (CIDER error screen has a toggle to 
>> supress the stack partially for this). They show java exceptions as clojure 
>> errors when they aren’t part of a clojure program. etc…
> 
> Again, Clojure is an unapologetically hosted language. There is no desire to 
> hide that fact or to shield you from it. That means that learning Clojure 
> inevitably means learning something about the JVM or Java as well. 
>  
>> 3: These, plus a few other things, mean the error messages are semantically 
>> far away from the program you write. You stay happily in LISP-y land until 
>> you get a stack, then you realize you are in java. There are lots of 
>> examples of this, but take the dumb one I picked - (1 + 1) in a REPL. That 
>> shows two concepts (java.lang.Long and clojure.lang.IFn) which you don’t 
>> deal with in lisp. I’ve written quite a lot o

Re: Errors

[Paul Walker]

Wow thank you for the fulsome responses

A couple of thoughts. I brashly said

> I cherrypicked a case where the runtime difference would be tiny

and I appreciate the clarifications - especially that my naive add-one-bytecode 
calculation in my head (the code I pasted has a pretty meaty “analyze” call 
called before it every time which is why I thought I cherry-picked) didn’t 
think about things like byte code inlining or, really, the pile-of-sand 
one-more-bytecode syndrome. So thanks for that!

And my favorite response from Alex:

> If I can make a request, it would be that instead of saying "errors are bad" 
> (which is honestly, not helpful by itself), but to step back and either take 
> a broader approach towards systemic issues

This is so reasonable I’m embarrassed I was a bit glib in my first note. I mean 
it’s not like they are C++ template errors from 1998  (my gold standard for bad 
errors). So let me expand on “bad” a little. 

I think the error messages are “bad” in 3 particular but related ways. I’d be 
happy to expand on these, but the themes are:

1: They are “large” and “far from my code”. This is partly an issue with java 
stack traces, but the intermixing of java and clojure and the presentation of 
clojure names in java name-like things in the stacks is obscuring. The line 
numbers are obscured instead of displayed prominently. And so on.

2: Similarly, they expose internals of the runtime implementation to the user. 
Stacks intertwine java and clojure (CIDER error screen has a toggle to supress 
the stack partially for this). They show java exceptions as clojure errors when 
they aren’t part of a clojure program. etc…

3: These, plus a few other things, mean the error messages are semantically far 
away from the program you write. You stay happily in LISP-y land until you get 
a stack, then you realize you are in java. There are lots of examples of this, 
but take the dumb one I picked - (1 + 1) in a REPL. That shows two concepts 
(java.lang.Long and clojure.lang.IFn) which you don’t deal with in lisp. I’ve 
written quite a lot of clojure in the last 5 months and never typed 
clojure.lang.IFn once. It’s a java error message but I’m a clojure programmer. 
Instant semantic break. And since many error messages are generated at the 
runtime level, which is java / JVM, I experience this semantic break often. Add 
the excellent comments in this thread on macro expand non-locality of error and 
the problem expands.

So if you imagine a guide like “the error should be as close to the error 
causing code as possible and presented in the semantics of the problem” then I 
think I conclude clojure messages are “bad”. (But I love clojure) 

It seems spec, inasmuch as it acts as a sort of optional type system which is 
in the space of the clojure language and produces information in that space, 
would address many of these. 

And as to why I mentioned this: I mean I haven’t had a problem. I just built a 
dual mental model of clojure and the clojure runtime while I learned the 
language and swapped between when an error popped. And I’ve written a lot of 
java (and interpreters and compilers too) so that was easy enough for me to do. 
And I have been hugely productive in your kit. I love clojure! 

But indeed for teaching it’s an obstacle, but also for teaching’s adjacent 
problem, using a language or toolset in a group of programmers of mixed 
abilities, I was thinking errors would be something I’d improve.

But really, it seemed like a place I could lend a shoulder if work was afoot, 
so the comments on the ticketing approach are appreciated and I will dig into 
them.

Thank you for your rapid and thoughtful responses

- Paul


> On Dec 6, 2016, at 2:56 AM, Mars0i <marsh...@logical.net> wrote:
> 
> On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote:
> Several of the Clojure/core folks have said at various times over the years 
> that Clojure is deliberately not optimized for novices, on the grounds that 
> whilst everyone starts out as a novice, most of your time spent with Clojure 
> is beyond that stage (and an optimization for novices can be a 
> de-optimization for everyone else).
> 
> This makes sense for anyone with significant programming experience.  It's a 
> shame, though, that Clojure would be a great language for novice programmers 
> except for the error messages, which are probably a show-stopper for some p 
> teachers thinking of using it for teaching.  I know that there are people 
> involved in Clojure Bridge and other teaching programs, but as a teacher (in 
> another discipline), I personally would have a hard time choosing Clojure 
> over Scheme at this point, if I was teaching an intro programming course.  
> Clojure's probably a better language for later growth though, given its easy 
> integration with Java and Javascriptl.
> 
> I'm not arguing for a 

Re: Errors

[Paul Walker]

Yeah I understand that tradeoff. I cherrypicked a case where the runtime 
difference would be tiny but others are harder I’m sure.

I guess I will go figure out how spec applies to my project.

Thanks as always. This group is so responsive. Appreciated.

- Paul

> On Dec 5, 2016, at 9:46 PM, James Reeves <ja...@booleanknot.com> wrote:
> 
> On 6 December 2016 at 01:28, <p...@pwjw.com <mailto:p...@pwjw.com>> wrote:
> And the error messages are not good.
> 
> So I was wondering: Is this a philosophical thing? Or is it an effort thing? 
> And if it is an effort thing, is there some sort of plan for what effort to 
> put in? And if so, can I help by closing tickets?
> 
> This is an issue that's been discussed often.
> 
> The fundamental problem is that in a dynamically typed language, good error 
> messages are often at odds with runtime performance. The more checks we add 
> to catch specific scenarios, or to provide more descriptive scenarios, the 
> more performance tends to be impacted.
> 
> However, Clojure 1.9.0 may have a solution to that in the form of specs. We 
> can turn on specs selectively at development time, so we get the benefit of 
> detailed error messages, while in production we can turn them off for 
> performance.
> 
> - 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 
> <http://groups.google.com/group/clojure?hl=en>
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/ANKq6XD1nW8/unsubscribe 
> <https://groups.google.com/d/topic/clojure/ANKq6XD1nW8/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

Errors

[paul]

Hi!

Boy I really think you've all done a nice job with Clojure. I've used quite 
a few environments over the years and clojure + CIDER + etc is a great 
experience. The immutability and threading are smart. I've been able to 
finish a hobby project in clojure which I've been mulling for a long time 
and never found the right environment. Super stuff.

And the error messages are not good.

So I was wondering: Is this a philosophical thing? Or is it an effort 
thing? And if it is an effort thing, is there some sort of plan for what 
effort to put in? And if so, can I help by closing tickets?

Here's one, for instance, which bugs me (using a build of branch master in 
clojure from github just now)

user=> (+ 1 1)

2

user=> (1 + 1)

ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
user/eval17 (NO_SOURCE_FILE:10)




OK but what sort of noob would actually type in 1 + 1? (That's a joke. Lots 
of people would. And I do sometimes when switching between java and 
clojure) But that same error pops up if you misalign in parenthesis or 
confuse an argument order or do a variety of other things.

And that error message is terrible. I mean I know why it is there. Clojure 
needs the first element of a list be the function position and 1 is not a 
function, it is a long. But you have to squint rather generously at that 
message to get to the problem. Or just learn what that message "really" 
means, which seems a bit unfriendly.

And so when I go look inside the source 

user=> (print-stack-trace *e 20)

java.lang.ClassCastException: java.lang.Long cannot be cast to 
clojure.lang.IFn

 at user$eval9.invokeStatic (NO_SOURCE_FILE:6)

user$eval9.invoke (NO_SOURCE_FILE:6)

clojure.lang.Compiler.eval (Compiler.java:6978)

clojure.lang.Compiler.eval (Compiler.java:6941)



Compiler.java has

IFn fn = (IFn) fexpr.eval();

return fn.invoke();


Which of course throws a class cast exception.


But there's so much information right there. Imagine this (in pseudo-code) 
as


Object f = fexpr.eval();

if (f instanceof IFn) return (IFn)f.invoke()

else throw ClojureNotAFunctionEvaluationError "First position in form at 
line " ... " of environment " ... " is not a function object. You handed me 
" + fexpr.first() " in form " ... " which has type " fexpr.first().class() 
" and value " fexpr.first().toString()


or whatever (like maybe don't toString values - that's why you'd want a 
plan. And maybe use a string table so you can internationalize. Again, plan 
:) )


so I almost want to whack this sort of stuff into a local copy as I hit 
error messages which bug me, but that seems foolish. And anyway I'm new 
here.


Sorry if I have accidentally stepped into some sort of landmine or if this 
has been rehashed a million times.


But I figured, in the spirit of being willing to help if there's help to be 
applied, I would ask if there's some sort of thinking on this topic for 
1.9.1 or 1.10 or something?


Thanks


  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: recursive bindings not available in let form?

[Paul Gowder]

That's a really neat post. Thank you for writing it!  

How do bindings created by let fit into that picture? 

> The question of how vars work comes up enough that I recently wrote a blog 
> post on the subject. Maybe it will be useful to you. 
> http://blog.cognitect.com/blog/2016/9/15/works-on-my-machine-understanding-var-bindings-and-roots
> 

-- 
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: recursive bindings not available in let form?

[Paul Gowder]

Thanks Bobby, Francis, Walter!  Now trying to wrap my head around the idea 
of def as a ref... 

On Friday, December 2, 2016 at 2:57:13 PM UTC-6, Francis Avila wrote:
>
> Let bindings are immutable bindings, not refs. They must act as if their 
> value could be substituted at the moment they are referenced. Def (i.e. a 
> ref) is a mutable container whose contents is examined when it is used (not 
> when referenced), which is why your second example works.
>
>
> Why doesn't let work how you expect? Well, how would the following code 
> work if let worked as you intend?
>
> (let [a 1
>   a (+ a 2)]
>   (= a 3))
>
> However, fn  accepts an optional name binding, so you can do this:
>
> (let [fib (fn fib [...] (fib ...))] fib)
>
> The inner fib reference is bound by the fn form, but the outer fib 
> reference is still bound by let.
>
> Or you can use letfn instead of let, which is the same as above with less 
> typing AND the bindings can all see one another simultaneously. It's best 
> for groups of closed-over  but mutually recursive functions.
>
> (letfn [(fib [...] (fib ...))] (fib ...))
>
>

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

recursive bindings not available in let form?

[Paul Gowder]

Hi clojure-world, 

I think maybe this is actually related to the complexities of binding 
referenced in the previous thread 
(https://groups.google.com/forum/?utm_source=digest_medium=email#!topic/clojure/zBXsrqTN2xs)...
 
maybe?  But it would be amazing if some wise person would help explain... 

So for obscure reasons, I found myself trying to use a naive recursive 
fibonacci function interactively.  So naturally, the first thing my fingers 
went to was: 

(let [fib (fn [x] 
  (cond
(< x 2) x
:else (+ (fib (- x 2)) (fib (- x 1)]
(fib 5))

which threw an unable to resolve symbol error because it couldn't resolve 
the recursive calls to fib inside the let binding. 

But swap out the let for a def and it works just fine:

(def fib (fn [x] 
  (cond
(< x 2) x
:else (+ (fib (- x 2)) (fib (- x 1))
(fib 5)

Can someone clarify for me what's going on here?  Why can a def binding get 
access to its own name in the body of a function, but not a let binding?

thanks!

-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: Getting information from a hashmap that is inside anothe hashmap

[paul]

Not quite. The -> operator basically puts the prior result in as argument 
number one of the next statement, so you need to create an expression who, 
when it has the result of :char put in position 1, returns a vector of eye 
color and hair color

Luckily the core library has a function (juxt) which does exactly that - 
given two functions makes the result of calling each on the same arguments.

So you need to create a function (juxt :ec :hc) and then you need to call 
it by wrapping it in (). So

(-> human2 :char ((juxt  :eye-colour :hair-color)))

There are, of course, a million other ways. Here's another which is may be 
easier if you aren't so used to higher order functions.

(-> human2 :char (as-> sub [ (:eye-colour sub) (:hair-colour sub)]))

using the "as->" idiom which basically binds a variable in the subsequent 
expression to the result of the prior expression in the -> (that's not 
really what it does but in this context you can think of it that way).

Hope that helps!

On Thursday, November 24, 2016 at 7:17:17 AM UTC-5, Rickesh Bedia wrote:
>
> That makes sense. Thanks for the help.
>
> Also say I wanted to get both eye-colour and hair-colour.
> Could that be done by (-> human2 :char [:eye-colour :hair-colour])?
>
>
> On Tuesday, 22 November 2016 11:08:45 UTC, Bost wrote:
>>
>> (->> human2 :char :eye-colour) or 
>> (-> human2 :char :eye-colour) or 
>> ((human2 :char) :eye-colour) or 
>> (:eye-colour (:char human2)) all variants work. 
>>
>> Either way it looks like you're asking a very basic question. 
>> I recomend you to go over http://clojurekoans.com/ or read some 
>> tutorial, quick start guide etc. 
>>
>>
>> 2016-11-22 11:42 GMT+01:00 'Rickesh Bedia' via Clojure 
>> : 
>> > Lets say I have: 
>> > (def human {:firstname "John" :surname "Smith"}) 
>> > To get the firstname I would run (human :firstname) and this would give 
>> > "John" 
>> > 
>> > However if I now have 
>> > (def human2 {:name "Bob" :char {:eye-colour "brown" :hair-colour 
>> > "red"}}) 
>> > how would I get the eye-colour? Would it be (human2 :char :eye-colour). 
>> I 
>> > just want the eye-colour 
>> > 
>> > 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 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.

[ANN] functional-vaadin 0.2.1 released

[Paul Bennett]

I've just deployed a new release of functional-vaadin, a Clojure library 
that greatly improves the building of Vaadin-based web UI's. Latest version 
is 0.2.1, and adds

   - New builders for tree tables, upload and login form
   - Internal refactoring, including the use of clojure.spec for builder 
   argument parsing
   - Updated Sampler app
   - Moved ToDo app to a separate repository
   - Updated to Vaadin 7.7.3
   - Bug fixes!

The use of clojure.spec does require the use of Clojure 1.9.0-*

It has been deployed to clojars, and standalone jars are attached to the 
release in the repo - https://github.com/wizardpb/functional-vaadin.

Please Note: v0.2.0 is nonfunctional due to a bug in the deployment process

Thanks to all who have tried it, and the positive feedback!

-pb

-- 
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: protocols and namespaces confusion (with an example from core.matrix)

[Paul Gowder]

Thanks Gregg and Alex!  I didn't realize that protocols (or the black magic 
interfacing of core.matrix) were that fancy.  Definitely going into my "code to 
really dig into" list.

Cheers,

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

protocols and namespaces confusion (with an example from core.matrix)

[Paul Gowder]

Hi folks, 

I have a kinda basic question (I think?) that I should really know the 
answer to after writing Clojure for like 8 months, but don't.  It's about 
requiring namespaces with protocol definitions in them but not the actual 
implementations of those protocols, and how it works.  

tl/dr: if a protocol is defined in namespace a and implemented (extended to 
the type at issue) in namespace b, can you call functions from it in 
namespace c where namespace c only requires namespace a, not namespace b?

Backstory: I was poking around core.matrix recently in pursuit of 
restarting work on a months ago issue I promised to work on, and it looks 
like at least one namespace calls a function it shouldn't be able to call.

So: clojure.core.matrix.impl.pprint requires only one namespace within 
core.matrix, clojure.core.matrix.protocols. (I'm going to use ... hereafter 
to stand for clojure.core.matrix.) ...protocols defines a protocol 
PSliceSeq2, which gives the name, docstring, etc. for a function called 
get-slice-seq. PSliceSeq2 is actually implemented for the generic object 
case in ...impl.defaults and for ISeq in ...impl.sequence. 

But ...impl.pprint calls ...protocols/get-slice-seq. And it seems to work. 
 Even though I can't find either ...impl.defaults or ...impl.sequence 
anywhere in the dependency tree for ...impl.pprint.

This is a puzzle to me.  I mean, the ...impl.pprint namespace will 
typically be required from some other namespace, and presumably that 
higher-level namespace will require everything that one needs. But still, I 
hadn't thought that one would be able to call get-slice-seq in a function 
in ...impl.pprint without requiring a namespace that actually defines the 
function, as opposed to just defining the protocol.

So can someone explain how this magic works?  Is the compiler just way 
smarter than I thought it was, and capable of figuring this stuff out on 
its own?

Thanks!

-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: Should I switch to Clojure after 3 years of learning another full stack ?

[Paul Gowder]

Another thing worth thinking about is that Cojure(script) is great for pure 
front-end applications ("single page applications").  The reagent library is a 
scarily magical way of just abstracting away the dom, and figwheel is a scarily 
effective build tool. This template is a convenient way to get started: 
https://github.com/reagent-project/reagent-frontend-template.  I actually built 
a static site using reagent once, hard-coding the content into the 
clojurescript for shits and giggles gowder.io), but that's pretty stupid. :-)

If you don't need to do anything heavy server-side, reagent might be a good 
starting point, and then no need to think about things like webservers and 
databases and routing. 

-- 
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: Idiom question

[paul]

All very interesting, and Sean that first/or threading pattern is very 
helpful.

@puzzler - totally get that the language is extensible yup and appreciate 
the mainstream warning. When I read your cond-better version I got it; and 
I also thought "a return statement like thing could be useful in a 
construct something like this" and then remembered just how far the macro 
system in lisps lets you go, which was really instructive.

The patterns here are very useful. Thanks again to all of you who offered 
up tips so far.

On Wednesday, September 28, 2016 at 5:53:10 PM UTC-4, Sean Corfield wrote:
>
> Ooops, should be: 
>
> (defn has-transmitters 
>   [^MidiDevice device] 
>   (<= 0 (.getMaxTransmitters device))) 
>
> And if we made a helper for open-device, we could make it return the 
> now-open device and then you wouldn’t need the doto – just call 
> (open-device). 
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
>
> On 9/28/16, 2:48 PM, "Sean Corfield"  
> wrote: 
>
> And for comparison, here’s a threaded version that uses -> (with ->> 
> embedded, and doto): 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter #(= (.getName ^MidiDevice$Info %) name)) 
>(map #(MidiSystem/getMidiDevice ^MidDevice$Info %)) 
>(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (.open)) 
>   (.getReceiver)) 
> 
> Note that I replaced the empty? check by just calling first followed 
> by or/throw. Calling first on an empty sequence produces nil and (or x 
> (throw …)) will yield x if it is not nil (else throw the exception). 
> 
> Also note that you lose the type hints here which may affect 
> performance and/or method resolution (if the calls are ambiguous without 
> the type hints). 
> 
> If the code isn’t performance critical and the calls are still 
> resolvable without type hint, I’d probably omit them just to make the code 
> cleaner. If the hints are needed, then I’d probably defn helpers for the 
> interop calls (with type hinted arguments) to make the code cleaner: 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter #(= (get-device-name %) name)) 
>(map get-midi-device) 
>(filter #(>= (get-max-transmitters %) 0))) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (open-device)) 
>   (get-receiver)) 
> 
> I’d probably make predicates for the two filter calls: 
> 
> (defn matches-device-name 
>   [name] 
>   (fn [^MidiDevice$Info info] 
> (= name (.getName info 
> 
> (defn has-transmitters 
>   [^MidiDevice$Info info] 
>   (<= 0 (.getMaxTransmitters info))) 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter (matches-device-name name)) 
>(map get-midi-device) 
>(filter has-transmitters)) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (open-device)) 
>   (get-receiver)) 
> 
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> 
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
> 
> On 9/28/16, 2:12 PM, "clo...@googlegroups.com  on behalf 
> of pa...@pwjw.com "  on behalf of pa...@pwjw.com > wrote: 
> 
> This is a super interesting thread. Thank you all for your input 
> 
> I think you are right, @puzzler, that for my case a let may be better. 
> The original code is above. Using as-> it looks like this (using 'it' as 
> the name) 
> 
>   (as-> (MidiSystem/getMidiDeviceInfo) it 
>  (filter #(= (.getName ^MidiDevice$Info %) name) it) 
>  (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it) 
>  (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it) 
>  (if (empty? it) (throw (ex-info "No midi devices with recievers" 
> {:name name})) it) 
>  (first it) 
>  (do (.open ^MidiDevice it) it) 
>  (.getReceiver ^MidiDevice it) 
>  ) 
>) 
> 
> using let it looks like this 
> 
> (let [device-info   (MidiSystem/getMidiDeviceInfo) 
>  named-device-info (filter #(= (.getName ^MidiDevice$Info %) 
> name) device-info) 
>  devices   (map #(MidiSystem/getMidiDevice 
> ^MidDevice$Info %) named-device-info) 
>  receivables   (filter #(>= (.getMaxTransmitters 
> ^MidiDevice %) 0) devices) 
>  _ 

Re: Idiom question

[paul]

This is a super interesting thread. Thank you all for your input

I think you are right, @puzzler, that for my case a let may be better. The 
original code is above. Using as-> it looks like this (using 'it' as the 
name)

  (as-> (MidiSystem/getMidiDeviceInfo) it
 (filter #(= (.getName ^MidiDevice$Info %) name) it)
 (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
 (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
 (if (empty? it) (throw (ex-info "No midi devices with recievers" 
{:name name})) it)
 (first it)
 (do (.open ^MidiDevice it) it)
 (.getReceiver ^MidiDevice it)
 )
   )

using let it looks like this

(let [device-info   (MidiSystem/getMidiDeviceInfo) 
 named-device-info (filter #(= (.getName ^MidiDevice$Info %) name) 
device-info)
 devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info 
%) named-device-info)
 receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice %) 
0) devices)
 _ (when (empty? receivables) (throw (ex-info "No 
midi devices with recievers" {:name name})))
 receivable(first receivables)
 result(do 
 (.open ^MidiDevice receivable)
 (.getReceiver ^MidiDevice receivable))]
 result)

and if I were doing a code review, I think I would like the last one better.

How very interesting. Thanks all for your constructive answers. What a 
great community.

On Wednesday, September 28, 2016 at 4:47:22 PM UTC-4, puzzler wrote:
>
> A common convention with as-> is to use the symbol $ because it is 
> recognized as a Clojure identifier but looks distinctive, so it stands out 
> as the placeholder of where to thread.
>
> Personally, when reading code, I don't really like to see long uses of the 
> threading operator, and I'd argue that if you find yourself using such long 
> chains of computations that the "important" argument is switching to 
> different positions, that's a sign that maybe you shouldn't be using 
> threading operators in the first place, because it can be hard to mentally 
> follow what intermediate data structure you have at each stage of the 
> computation.  Instead, I'd argue that you should be using `let`, because 
> `let` allows you to give each stage of computation a meaningful name, 
> making it easy for others (or yourself in two months) to read and reason 
> about your code.  `let` allows you to communicate intent.
>
> I think one reason people sometimes shy away from using `let` is that it 
> can't easily be used at all positions within one's code.  For example, if 
> you are inside a `cond`  doing some conditional logic, adding a `let` means 
> you have to also start a new `cond`, and your code ends up awkwardly nested 
> and indented, drifting to the right.   The better-cond library removes this 
> limitation, making it easy to write clear functions which intermingle long 
> chains of computations with conditional logic: 
> https://github.com/Engelberg/better-cond
>

-- 
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: Idiom question

[paul]

Wow yes that's exactly the -%> macro I imagined just with "%" replaced with 
"it". And it exists!  Plus I just converted my fragment to use as-> and 
thought "aren't the first two arguments backwards (vs, say, "let"); and 
what name should I use (I chose 's')". Thank you. Reading the tupelo docs 
now.

On Wednesday, September 28, 2016 at 4:02:38 PM UTC-4, Alan Thompson wrote:
>
> Hi Paul,
>
> Since you are interested in the threading macros, you might like to take a 
> look at one of my favorite variants from the Tupelo library 
> <https://github.com/cloojure/tupelo#literate-threading-macro>:
>
> Literate Threading Macro
>
> We all love to use the threading macros -> and ->> for certain tasks, but 
> they only work if all of the forms should be threaded into the first or 
> last argument.
>
> The built-in threading macro as-> can avoid this requirement, but the 
> order of the first expression and the placeholder symbol is arguably 
> backwards from what users would expect. Also, there is often no obvious 
> name to use for the placeholder symbol. Re-using a good idea from Groovy, 
> we simply use the symbol it as the placeholder symbol in each expression 
> to represent the value of the previous result.
>
> (it-> 1
>   (inc it)  ; thread-first or thread-last
>   (+ it 3)  ; thread-first
>   (/ 10 it) ; thread-last
>   (str "We need to order " it " items." )   ; middle of 3 arguments;=> 
> "We need to order 2 items." )
>
> Here is a more complicated example. Note that we can assign into a local 
> let block from the it placeholder value:
>
> (it-> 3
>   (spy :msg :initial it)
>   (let [x it]
> (inc x))
>   (spy it :msg 222)
>   (* it 2)
>   (spyx it)); :initial => 3; 222 => 4; it => 88   ; return value
>
> Note that the :msg argument does not need to be a string. As shown above, 
> keywords, integers, etc may be used.
> Alan
>
>
> On Wed, Sep 28, 2016 at 11:36 AM, Colin Yates <colin...@gmail.com 
> > wrote:
>
>> Welcome to one of the best things about Clojure - the community. However, 
>> if anyone starts using the phrase 'Clojurian' then it is time to leave :-).
>>
>>
>>
>> On Wed, 28 Sep 2016, at 07:17 PM, pa...@pwjw.com  wrote:
>>
>> Wow thank you all for the really useful responses. How great. I 
>> appreciate the time.
>>
>> as-> cleans up a couple of ugly bits of my code already, yes. And I'm 
>> sort of irritated with myself for not thinking of _ (if (throw)) in my let 
>> but yes that's a perfect idiom.
>>
>>
>> I totally get the minimalist approach in clojure.test and like it. In 
>> fact, the ease of testing (and how easy it is to get coverage running with 
>> cloverage) is one of the things I find the most impressive. expectations 
>> looks interesting though too for a lot of my tests and I'll spend some time 
>> with it too.
>>
>> The idiom of "most important is first unless its a sequence then it is 
>> last" is really natural too; but I think it's what makes me end up 
>> switching from ->> to ->. Putting a "first" in the middle of a ->> 
>> expression is, I suppose, a hint that I'm switching.  Looking at my code, 
>> it really seems to be a mix of ->> and "doto" that I'm looking for. Here's 
>> a fragment, for instance, that returns me an opened instance of the first 
>> core midi device with a name that can receive messages. (and I know I 
>> should error check that there is one after that filter... that's on my todo 
>> list). An "as-> doto" pair would help and I'll get right on that later on 
>> this week.
>>
>> (->> (MidiSystem/getMidiDeviceInfo)
>>
>> (filter #(= (.getName ^MidiDevice$Info %) name))
>>
>> (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
>>
>> (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))
>>
>> first
>>
>> (#(do (.open ^MidiDevice %) %))
>>
>> (#(.getReceiver ^MidiDevice %))
>>
>> )
>>
>> Anyway, wow thanks again for all the responses!
>>
>>
>>
>>
>>
>> On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com 
>> wrote:
>>
>> Hi.
>>
>> I'm new to clojure, and it is quite lovely. The threading model is great, 
>> the emacs integration is super, and the tasteful

Re: Idiom question

[paul]

Wow thank you all for the really useful responses. How great. I appreciate 
the time.

as-> cleans up a couple of ugly bits of my code already, yes. And I'm sort 
of irritated with myself for not thinking of _ (if (throw)) in my let but 
yes that's a perfect idiom.


I totally get the minimalist approach in clojure.test and like it. In fact, 
the ease of testing (and how easy it is to get coverage running with 
cloverage) is one of the things I find the most impressive. expectations 
looks interesting though too for a lot of my tests and I'll spend some time 
with it too.

The idiom of "most important is first unless its a sequence then it is 
last" is really natural too; but I think it's what makes me end up 
switching from ->> to ->. Putting a "first" in the middle of a ->> 
expression is, I suppose, a hint that I'm switching.  Looking at my code, 
it really seems to be a mix of ->> and "doto" that I'm looking for. Here's 
a fragment, for instance, that returns me an opened instance of the first 
core midi device with a name that can receive messages. (and I know I 
should error check that there is one after that filter... that's on my todo 
list). An "as-> doto" pair would help and I'll get right on that later on 
this week.

(->> (MidiSystem/getMidiDeviceInfo)

(filter #(= (.getName ^MidiDevice$Info %) name))

(map #(MidiSystem/getMidiDevice ^MidDevice$Info %))

(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))

first

(#(do (.open ^MidiDevice %) %))

(#(.getReceiver ^MidiDevice %))

)

Anyway, wow thanks again for all the responses!





On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com wrote:
>
> Hi.
>
> I'm new to clojure, and it is quite lovely. The threading model is great, 
> the emacs integration is super, and the tasteful lisp extensions are good. 
> A very nice programming environment all around. 
>
> But as I write more code I find a couple of structures I'm using a lot 
> which seem related to me not knowing idioms for a couple of uses cases. So 
> thought I'd ask and see if you have any suggestions. 
>
> Apologies if this is covered elsewhere. And if I should read some existing 
> documentation I didn't find, I apologize for missing it. And thanks in 
> advance for your time reading!
>
> First the thrush operators (-> and ->>) are super handy. But I find myself 
> needing to 'move' arguments every now and then. So I get code which looks 
> like
>
> (->> blah
>  (do-this)
>  (do-that arg)
>  ((fn [s] (rearrange arg s arg
>
> quite a lot.The alternate is a big nested let like
>
>  (let  [ first   (blah)
>   second  (do-this first)
>   ...
>   result  (wrap-it-up fourteenth) ]
> result)
>
> for sort of sequential application where arguments fall in different 
> 'spots'. So I sort of find myself wanting to write a 'positional-thrush' 
> macro like
>
> (-%> blah
>  (do-this %)
>  (do-that arg %)
>  (do-the-other a1 % a2))
>
> where % is replaced with the output of the prior. But no such operator 
> exists as far as I can see. So either I've had a good idea (which is 
> unlikely since I'm super new to the language) or there's some other idiom 
> you all use for this pattern which I've missed.
>
> The second is smaller, but is more a question. clojure.test seems to only 
> have 'is' so for things like equality I end up writing (is (= (...) (...))) 
> a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
> but I'm wondering what led to that decision rather than having is-eq and 
> is-thrown and so on (considering the core language has shortcuts like when 
> and unless and if-not so the compound macros seem idiomatic).
>
> The last is sort of related to the first. Sometimes I'm assembling a data 
> structure in a set of operators and I write them with a let or a -> and 
> half way through I have an error condition I want to check. In a mutable 
> procedural language you would do something like
>
>   x = blah
>   y = bim
>   if (! (condition (y))) throw "y doesn't meet condition"
>   z = blob
>
> I don't see a good idiom for this. I have to split and nest lets for 
> instance
>
> (let [x (blah) y (bim) ]
>   (if (condition (y)) (throw ...)
>  (let [ z (blob) ] 
>   ))
>
> which seems a bit ugly.  I sort of want a let-with-test or a 
> thrush-with-test so something which looks like
>
> (-%?>  (init)
>  (operator-1 %)  (post-condition)
>  (operator-2 %)  (post-condition) )
>
> where if I don't have a post condition I could just use 'true'. Then this 
> expands to doing a quick '(if

Idiom question

[paul]

Hi.

I'm new to clojure, and it is quite lovely. The threading model is great, 
the emacs integration is super, and the tasteful lisp extensions are good. 
A very nice programming environment all around. 

But as I write more code I find a couple of structures I'm using a lot 
which seem related to me not knowing idioms for a couple of uses cases. So 
thought I'd ask and see if you have any suggestions. 

Apologies if this is covered elsewhere. And if I should read some existing 
documentation I didn't find, I apologize for missing it. And thanks in 
advance for your time reading!

First the thrush operators (-> and ->>) are super handy. But I find myself 
needing to 'move' arguments every now and then. So I get code which looks 
like

(->> blah
 (do-this)
 (do-that arg)
 ((fn [s] (rearrange arg s arg

quite a lot.The alternate is a big nested let like

 (let  [ first   (blah)
  second  (do-this first)
  ...
  result  (wrap-it-up fourteenth) ]
result)

for sort of sequential application where arguments fall in different 
'spots'. So I sort of find myself wanting to write a 'positional-thrush' 
macro like

(-%> blah
 (do-this %)
 (do-that arg %)
 (do-the-other a1 % a2))

where % is replaced with the output of the prior. But no such operator 
exists as far as I can see. So either I've had a good idea (which is 
unlikely since I'm super new to the language) or there's some other idiom 
you all use for this pattern which I've missed.

The second is smaller, but is more a question. clojure.test seems to only 
have 'is' so for things like equality I end up writing (is (= (...) (...))) 
a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
but I'm wondering what led to that decision rather than having is-eq and 
is-thrown and so on (considering the core language has shortcuts like when 
and unless and if-not so the compound macros seem idiomatic).

The last is sort of related to the first. Sometimes I'm assembling a data 
structure in a set of operators and I write them with a let or a -> and 
half way through I have an error condition I want to check. In a mutable 
procedural language you would do something like

  x = blah
  y = bim
  if (! (condition (y))) throw "y doesn't meet condition"
  z = blob

I don't see a good idiom for this. I have to split and nest lets for 
instance

(let [x (blah) y (bim) ]
  (if (condition (y)) (throw ...)
 (let [ z (blob) ] 
  ))

which seems a bit ugly.  I sort of want a let-with-test or a 
thrush-with-test so something which looks like

(-%?>  (init)
 (operator-1 %)  (post-condition)
 (operator-2 %)  (post-condition) )

where if I don't have a post condition I could just use 'true'. Then this 
expands to doing a quick '(if (not (postcondition (intermedia-result 
throw...)

but that's a crazy thing to want. So curious how you all tackle this.

Thank you all for your consideration. And apologies again if this is 
covered elsewhere or I should have asked in a different forum.

Best,

  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.

[ANN] pjstadig/reducible-stream 0.1.0

[Paul Stadig]

I have released a library for fusing a stream, decoder, and resource 
management into a reducible object with the intent to automatically manage 
resources. You can then apply a transducer to this object. This means you 
can apply a transducer pipeline that only partially consumes the stream, 
yet will close the stream nonetheless.

You can also use this object as a sequence, though in that case it will 
load the entire decoded sequence into memory at the same time. There's a 
big difference between `(into [] (take 1) (decode-edn! stream))` and `(take 
1 (decode-edn! stream))`.

The library is called pjstadig/reducible-stream, and is at 
https://github.com/pjstadig/reducible-stream/

There is also a blog post covering the concepts: 
http://paul.stadig.name/2016/08/reducible-streams.html

I hope others find this useful. It's somewhat experimental, so caveat 
emptor. I welcome feedback.


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

Should spec used to check the sematics of DSL arguments?

[Paul Bennett]

Hi All,

I have a library that provides a DSL to build a composite hierarchy of UI 
objects for a server-side Web framework 
(https://github.com/wizardpb/functional-vaadin). RIght now, I have a whole 
bunch of custom code that checks the validity of arguments passed to the 
builder functions, and I'm seeing that I could use spec to radically 
improve the readability and maintainability of that code.

However, it seems to me that spec is mostly oriented to checking syntax and 
basic content, and not so much towards complex semantics relating different 
parts of a data form. For instance, in my DSL, the arguments can be a set 
of constructor arguments for the underlying Java object, and/or a Map with 
keys and values corresponding to setters on that object. This means that 
argument correctness depends on the object being constructed, which defines 
the ctor argument types and specific combinations of map keys and values.

However, the syntax for these is uniform, which implies that a single spec 
could be used to check the syntax of the call. It would be possible to 
augment this basic form with additional semantic checking, probably using 
the spec regex '&' operator, but I'm wondering what the trade-offs are 
here. At one extreme I could have a single spec that checks syntax (and 
extracts the different parts using destructuring - very useful), and a 
bunch of custom code that checks the more complex semantics, OR a set of 
custom specs, probably one for each different class I want to build an 
instance of (possibly generated automatically from a base and type specific 
parts)

My question is: where's the sweet spot between these two extremes - or is 
there another approach entirely?

Any ideas most welcome!

-- 
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 
<https://groups.google.com/forum/#!forum/pedestal-users>).  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.

[ANN] functional-vaadin 0.1.1

[Paul Bennett]

Hi Everyone,

I'd like to announce functional-vaadin, a library for building Clojure 
webapps using the Vaadin UI framework. Since Vaadin is Java-based, this can 
already be done - but it's clunky: lots of doto and setter calls, 
temporaries to hold parts of the UI being constructed, etc. etc. This 
library is aimed at making all that a thing of the past. 

The code is open-source: https://github.com/wizardpb/functional-vaadin

Jars are deployed to Clojars: 
https://clojars.org/com.prajnainc/functional-vaadin

There is still work to be done, mostly on the documentation, as well as 
some final components and event handling

The primary goal is to use the homoiconic nature of clojure to make the 
code that builds a UI as structurally similar as possible to the UI itself. 
The library provides builder functions for each component, these take 
constructor arguments and/or a configuration Map, as well as any children 
components. This effectively eliminates the clutter.

The other main feature is an integration with RxClojure, which makes 
explicit event handling a thing of the past. Instead, sequences of 
Observers can be created, allowing arbitrary processing of events from the 
UI. It is quite possible have these chains receive an event, process it 
with arbitrary code, and return new data to other parts of the UI.

Other features include a component naming scheme that allows access to 
components via their ID (eliminates temporaries), conversion functions that 
interface Clojure immutable data structures to Vaadin data binding objects, 
and a better Form mechanism, integrating FieldGroups, layouts and 
function-based validation and conversion.

I hope you find this useful! Please feel free to contact me with any 
further questions.

-- 
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] pedestal-api 0.2.0 release - Swagger for pedestal

[Paul deGrandis]

Congrats!

-- 
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: IoT: Clojurescript -> Jerryscript?

[Paul deGrandis]

Hi Gregg,

I've previously used ClojureScript to target other JavaScript engines (on 
small devices and on Android), without any issue.  You shouldn't need to do 
anything special, but if something comes up and you hit a snag, just post 
here.

Good luck and have fun!

Cheers,
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: Encapsulating Local Mutable State

[Paul Mooser]

One thing you can do is use 'reify', which will allow you to implement a 
protocol but also have your state atom hidden in a closure. You'll still be 
passing an 'object' to all of the protocol methods (obviously), but it 
won't be the atom itself. 

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

Language-agnostic schema definition for Transit?

[Paul Lam]

Is there something like JSON Schema http://json-schema.org/examples.html 
specifically for Transit? Perhaps with a validator tool too.

-- 
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: Clojure as first language

[Paul Gowder]

Thinking about this a little more, it seems to me that the real 
beginner-unfriendly bits of clojure that actually are a problem for basic 
learning (so not legitimately difficult stuff like quoting and macros) all come 
from the JVM.  Errors that are incomprehensible? JVM. Classpath confusion? JVM. 
Need for tooling and complex directory structures? That's probably the JVM too. 
Having to wrap half of the verbs you use in anonymous functions in order to get 
them to map and filter and reduce and such because they're really methods that 
have arcane and incomprehensible rules about whether they're "static" or 
(whatever the opposite of static is) and have to be attached to nouns to make 
them do work? Oh hai JVM.  Lack of tail call... Well... Yeah.

So... what do folks think about something like Hy for beginners instead? All 
the Lispy goodness, all the "hey there's a serious batteries-included library 
back here" hosting, but with a kind and gentle Dutch hug behind them instead of 
the punch in the face that is the JVM? After all, the slow performance of 
Python isn't a big deal for total beginners, and total beginners also don't 
need all the sexy advanced stuff like concurrency that makes Clojure worth the 
JVM pain. 

craxy thought... But not insane?

-- 
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: Clojure as first language

[Paul Gowder]

On Thursday, March 17, 2016 at 12:10:21 PM UTC-5, blake watson wrote:
>
> On Sat, Mar 12, 2016 at 2:42 PM, Lee Spector <lspe...@hampshire.edu 
> > wrote:
>
> > Is "lein new app foo" that complicated?
>
> If I understand Paul correctly—and am not just imposing my own similar 
> feelings on him—the problem is not that "lein new app foo" is complicated, 
> it's that it creates a directory structure that is complicated for the 
> beginner. Clojure is by far not the worst in this regard, but a new app 
> creates seven folders (root, doc, resources, src, test, src/root and 
> test/root) and nine files (.gitignore, .hgignore, CHANGELOG.md, LICENSE, 
> project.clj, README.md, intro.md, core.clj and core_test.clj). This is a 
> lot for someone just trying to grasp "Hello, world."
>
> The less you have to say to the student ("you can ignore all that for 
> now") the better. The less you have to tell the user to toggle mysterious 
> switches (as with the JVM stack options) the better.
>
>

Partly this, yes.  And partly also that there's a lot of semi-documented 
magic behind the scenes.  For example: leiningen has "new" and "new app." 
The tutorial says that they're different, and that one is appropriate for 
applications and the other for libraries, but doesn't offer any clue why, 
or what the differences might be---and it's hard to see, even coming from 
other languages, why there might be a reason for the difference. Is it 
something about namespacing and some kind of "main" path through the code 
for applications?  That's just my guess... 

Or the classpath.  Apparently this is a JVM thing, and leiningen hides it 
from the user, but sometimes it breaks, and then it's kind of a guessing 
game why unless one knows Java.  

And it doesn't help that it also makes unintuitive default decisions for 
one sometimes.  For example, I actually just spend several hours last night 
beating my head against the REPL's refusal to let me use core.matrix in a 
library I'm working on---it took a SO post plus some good luck to learn 
that core.matrix requires clojure 1.7+, and then notice that for some 
mysterious reason the version of leiningen I didn't install all that long 
ago defaulted to 1.6.   (The REPL, of course, didn't actually throw an 
error that gave any hint that there were version problems; the dependency 
just silently failed, and then when I tried to use the namespace that 
required core.matrix, it just threw an incomprehensible error claiming that 
it couldn't find the file --- see 
http://stackoverflow.com/questions/36051140/clojure-classpath-troubles-loading-code-and-dependencies-with-leiningen/36052171#36052171
 
--- that's just unfriendly behavior.)

Don't get me wrong. I'm not complaining. The more I learn about leiningen, 
the more I like it---the power to just swap out language versions 
altogether by changing one line in a config file, for example, is 
wonderful---and makes a lovely contrast with, for example, the Python 2/3 
craziness. But the fact that there's a ton of machinery going on behind the 
scenes to actually get anything running, even with good tools that abstract 
it away (when they work right), makes the ecosystem less beginner-friendly, 
because when something goes wrong it's a beast to figure out why. 

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Paul L. Snyder]

Yow, old indeed!

In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
I've used it for a bunch of projects, and it works great. Of course, it 
does look like Swing, but it's plenty usable. (It's also still being
maintained, so if you're looking for a toolkit that you can use right now,
it's a good way to go.)

  https://github.com/daveray/seesaw

That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly, 
Cognitect talked about a project where they'd used it extensively:

  https://www.youtube.com/watch?v=ajX09xQ_UEg

It's definitely piqued my interest.

Paul

On Sat, 12 Mar 2016, Jason Zwolak wrote:

> +1 JavaFX.
> 
> I know this is an old thread... but in case anyone comes across it (like I 
> did just now) and wants to see where things are, they should know that 
> JavaFX has come a long way and seems to be Oracle's replacement for Swing. 
> Now JavaFX is no longer only in JavaFXscript... in fact, I believe 
> JavaFXscript is deprecated in favor of the JavaFX Java classes.
> 
> I've seen some major projects done with Clojure and JavaFX... even from the 
> guys at Cognitect.
> 
> On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
> >
> > My side project is a fairly complex GUI application written in
> > Clojure. Recently, I've become irritated with using Java interop for
> > everything. It's not that Clojure doesn't have nice java interop - it
> > does. It's just that when interacting with a GUI framework, which is a
> > large part of my app, I have to be back in mutable object-oriented
> > land, worrying about class hierarchies, mutable state, locks, etc.
> > Yucky.
> >
> > So, with a perhaps dangerous lack of sanity and without any guarantee
> > of success, I've decided to try my hand at writing an idiomatic
> > Clojure GUI library. If I have success (which I doubt) I will of
> > course make it available as open source.
> >
> > I intend for it to be mostly declarative, with a nice DSL for defining
> > GUI elements. Each component will also implement map, and use one of
> > Clojure's reference types as an interface for inspecting / updating
> > its state. I may also implement some aspects of Functional Reactive
> > Programming wherever it's convenient to do so.
> >
> > What you all must help me decide is what GUI framework to use as the
> > underpinnings of it. It's genuinely hard to decide. I have at least
> > some experience with all of them, so I have no strong preference, but
> > I'd like to get your input. I did consider trying to make it abstract
> > enough that you could plug in *any* of them under the hood, but
> > there's enough differences between the frameworks that that would get
> > very ugly very fast.
> >
> > Possibilities are:
> >
> > AWT
> > Pros: native widgets, bundled with Java, low-level
> > Cons: few widgets, considered somewhat obselete
> >
> > Swing
> > Pros: bundled with Java, good widget selection
> > Cons: non-native widgets
> >
> > SWT
> > Pros: native widgets, widely used
> > Cons: requires platform-specific libs
> >
> > QT Jambi
> > Pros: native widgets, huge widget selection, highly-regarded framework
> > Cons: requires platform-specific libs, writing custom widgets is
> > hairy, momentum and support seem to be lagging since Nokia dropped
> > official support.
> >
> > Remember, the actual API won't matter - that will be completely
> > abstracted away. So try to focus on the framework's look and feel.
> > Also let me know if I've missed any of the framework's key
> > characteristics.
> >
> > Thanks!
> >
> > -Luke
> >
> >
> 
> -- 
> 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: Clojure as first language

[Paul Gowder]

As a clojure beginner and programming semi-beginner (advanced beginner? I'm 
decent but not pro dev level at Python and R and have messed around with a few 
others), switching to clojure because the functional style feels more natural 
than all that object ick, I can speak from personal experience here:

1.  Yeah, the stack traces are horrible.  
2.  The other big beginner barrier I feel is the tooling.  In lots of ways, 
leiningen is amazing (particularly the automatic grabbing of dependencies), but 
the forced project structure is really painful. It feels like a massive barrier 
to not just be able to throw up some code and have it run without having to set 
up a whole directory structure and all the rest.  (It would be nice in 
particular to be able to use gorilla-REPL without having a project for 
it---maybe with lein-try somehow??)  Been thinking about trying boot to make 
this simpler, but since every library seems to be documented in terms of 
leiningen, that means just means learning two tooling systems instead of just 
one.  

So just from my standpoint, those are the two big things to work on to make 
clojure appropriate as an absolute beginner language.  

-- 
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: Welcome the new maintainer of Loom: Paul Snyder

[Paul L. Snyder]

On Mon, 15 Feb 2016, Gregg Reynolds wrote:

> On Feb 11, 2016 6:19 AM, "Aysylu Greenberg" <aysy...@gmail.com> wrote:
> >
> > I'm pleased to announce that Paul Snyder
> (@pataprogramming, pataprogramming on Github) has joined me in maintaining
> Loom. I'm excited for the coming year for Loom, with more excellent
> contributions accepted faster.
> 
> Your Readme doesn't even bother to say what loom is.

Hi, Gregg,

Thanks for pointing out an area where additional clarification would be
helpful to potential users of Loom. 

Who is the 'you' that this criticism is intended to address? Aysylu, who's
been serving as maintainer for this library over the last years? Justin,
who originally created it? The over two dozen contributors who have helped
build its functionality? Suggesting that they didn't "even bother" with
something is, frankly, rude and unproductive.

I'm happy we don't see much of this sort of casual disrespect in the
Clojure community (with the exception of occasional bad actors on the
mailing list). The worst of what we do see is, largely, aimed at those who
contribute the most: the team that maintains Clojure itself.

People who are willing to invest their time to make and share useful tools
are a resource. They should be allowed to direct their energy toward making
those tools better, rather than having it drained by jerky interactions.
Whether we find a project personally useful or not, we owe Open Source
authors, at a minimum, politeness. This is at least partially in our own
interest: we want them to keep making those tools, rather than burning out
and switching to a more rewarding activity.

Here's an article on framing feedback in a less confrontational and
accusatory manner.

  http://personalexcellence.co/blog/constructive-criticism/

"Thanks for sharing Loom. There's a lot of information in the README, but
I found it difficult to figure out what the library actually does. It
would be helpful to have a concise, up-front description of its purpose."

Regards,
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: Welcome the new maintainer of Loom: Paul Snyder

[Paul L. Snyder]

On Thu, 11 Feb 2016, Aysylu Greenberg wrote:

> I'm pleased to announce that Paul Snyder (@pataprogramming, pataprogramming 
> on Github <https://github.com/pataprogramming>) has joined me in 
> maintaining Loom. I'm excited for the coming year for Loom 
> <https://github.com/aysylu/loom>, with more excellent contributions 
> accepted faster.

Thanks very much, Aysylu, and thanks to Justin for creating Loom and to
everyone who's contributed its lifetime. This library for easily
manipulable, moderate-scale persistent graphs occupies a useful niche in
the Clojure ecosystem.

I'm starting to review the open pull request and issues. If you have
a particular feature that you'd like to see, or a use case that you'd
like to see Loom work toward supporting, please let me know.

One things that I particularly hope to improve is the ability to 
easily visualize and interact with your graphs. Graphviz is a nice
starting point, but it's limited to static images.

In previous projects, I've interfaced Loom with JUNG (http://jung.sf.net)
to add interactive, Swing-based graph visualizations.  As a library, JUNG
is getting rather stale (its last release was in January 2010), but some
of its facilities and APIs may serve as inspiration for future
directions.

I've pulled some of the interface code out of a previous project, cleaned
it up, and added better support for the Seesaw library for using Swing
from Clojure (http://github.com/daveray/seesaw).  This is not likely to
be immediately useful to anyone, but it's a nice proof-of-concept.

You can give it a try from

  http://github.com/pataprogramming/loom-jung

There is a short walkthrough on using the library to visualize simple
graphs. Doing anything more complicated will likely require digging into
JUNG's (exceedingly ugly) API, but it's enough to play around with.  The
library is also available from Clojars:

  [pataprogramming/loom-jung "0.1.0"]

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: Clojure beyond Java 6 ?

[Paul deGrandis]

Hi All,

Jloj is/was a quick spike into what it'd take to make interop play nicely 
with later Java features (New trait-like interfaces, FunctionalInterface, 
Optional, Lambdas, Streams, etc.)  It's mostly focused on making the Java 
side more Clojure-like, but does have support for loads of interop that 
works on both sides.
 * From the Clojure side: 
https://github.com/ohpauleez/jloj/blob/master/src/jloj/core.clj#L227-L269
 * All the Java-written interop: 
https://github.com/ohpauleez/jloj/tree/master/java/jloj/lang

You'll see that with some Java shims in place, it's easy to get all the 
things listed in this thread.

Cheers,
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: [ANN] data.avl 0.0.13 – fast sorted collections with O(log n) slices and nth

['Jan-Paul Bultmann' via Clojure]

Very awesome :D!

Cheers, Jan

> On 09 Dec 2015, at 10:39, Michał Marczyk  wrote:
> 
> Hi,
> 
> I am pleased to announce the 0.0.13 release of data.avl, a Clojure
> Contrib library providing highly performant drop-in replacements for
> Clojure(Script)'s built-in sorted maps and sets with the following
> headline features:
> 
>  0. performance often superior to the built-ins (owing to the smaller
> height of AVL trees), see end of this email for some benchmarks
> 
>  1. logarithmic-time slicing and splits:
> 
> (avl/split-key 3 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1 2} 3 #{4 5 6}]
> 
> (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
> ;= [#{0 1} #{2 3 4 5}]
> 
> (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 2 < 5)
> ;= #{2 3 4}
> 
> All returned collections are independent from the originals for GC
> purposes (no holding on to out-of-range keys present in the
> original collections), all operations run in O(log n) time in
> asymptotic terms, and actually fast in real-world terms.
> 
>  2. logarithmic-time access by rank and rank queries:
> 
> (nth (avl/sorted-set 0 1 2) 1)
> ;= 1
> 
> (avl/rank-of (avl/sorted-map-by > 0 0 1 1 2 2) 0)
> ;= 2
> 
>  3. nearest-neighbour lookups:
> 
> (avl/nearest (avl/sorted-set 0 1 2) < 1)
> ;= 0
> 
> The complete clojure.core sorted collections API is also supported, as
> is the transient API. See the README for more detailed examples and
> feature descriptions.
> 
> Fixed in this release:
> 
>  1. IMeta and IFn implementations now use correct method names in the
> ClojureScript version.
> 
>  2. sorted-map/sorted-map-by now throw exceptions if no value is
> provided for the final key (in other words, if an odd number of
> arguments is passed in) – patch by Andy Fingerhut, thanks!
> 
> Changed in this release:
> 
>  1. Seqs over data.avl maps now use node objects themselves as map
> entries. This is in line with the behaviour of Clojure's built-in
> sorted maps. Previously seqs over data.avl maps used
> freshly-allocated map entry objects; this had the benefit of not
> holding on to subtrees in some scenarios, however not without some
> performance and GC pressure cost to regular traversals. Note that
> the new behaviour allows the user to rewrap key/value pairs as map
> entries if they so choose in a separate map step.
> 
>  2. Because of 1., AVL nodes now implement vector and map entry
> interfaces.
> 
> Cheers,
> Michał
> 
> 
> ;;; A handful of benchmarks
> 
> ; CIDER 0.9.1 (Java 1.8.0_45-internal, Clojure 1.8.0-RC2, nREPL 0.2.10)
> 
> user> (def ks (range 1))
> #'user/ks
> user> (def ksks (doall (interleave ks ks)))
> #'user/ksks
> user> (def m1 (apply sorted-map ksks))
> #'user/m1
> user> (def m2 (apply avl/sorted-map ksks))
> #'user/m2
> user> (.tree m1)
> [4095 4095]
> user> (.getTree m2)
> [4095 4095]
> user> (let []
> (prn :> 0)
> (c/quick-bench (get m1 0))
> (c/quick-bench (get m2 0))
> (prn :> 4095)
> (c/quick-bench (get m1 4095))
> (c/quick-bench (get m2 4095))
> (prn :> )
> (c/quick-bench (get m1 ))
> (c/quick-bench (get m2 )))
> :> 0
> WARNING: Final GC required 9.525315094951035 % of runtime
> WARNING: Final GC required 88.3127760569387 % of runtime
> Evaluation count : 2280474 in 6 samples of 380079 calls.
>  Execution time mean : 262.138936 ns
> Execution time std-deviation : 56.938518 ns
>Execution time lower quantile : 237.779848 ns ( 2.5%)
>Execution time upper quantile : 360.756510 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 64.2134 % Variance is severely inflated by outliers
> WARNING: Final GC required 78.56747149813818 % of runtime
> Evaluation count : 2280498 in 6 samples of 380083 calls.
>  Execution time mean : 261.626921 ns
> Execution time std-deviation : 42.454179 ns
>Execution time lower quantile : 241.444705 ns ( 2.5%)
>Execution time upper quantile : 335.120524 ns (97.5%)
>Overhead used : 20.503990 ns
> 
> Found 1 outliers in 6 samples (16.6667 %)
>   low-severe   1 (16.6667 %)
>  Variance from outliers : 47.5275 % Variance is moderately inflated by 
> outliers
> :> 4095
> WARNING: Final GC required 168.0614206986717 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>  Execution time mean : 25.939625 ns
> Execution time std-deviation : 4.135726 ns
>Execution time lower quantile : 22.648015 ns ( 2.5%)
>Execution time upper quantile : 32.134865 ns (97.5%)
>Overhead used : 20.503990 ns
> WARNING: Final GC required 293.8046791844393 % of runtime
> Evaluation count : 1056 in 6 samples of 176 calls.
>

Re: best practice with forked libraries

[Paul deGrandis]

In addition to Ray's response (which I would also suggest), I'd encourage 
you to reach out to the project maintainer/author with your additions - 
it's always nice to see how your project is being used and the shortcomings 
that others are hacking around.

Cheers,
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: [ANN] core.async-0.2.371

[Paul Mooser]

I think the problem isn't the name - it just isn't clear if a channel which 
behaves unlike any other channel when closed can qualify as having channel 
semantics.

On Thursday, October 29, 2015 at 2:10:43 PM UTC-7, Alex Miller wrote:
>
> We are not going to change the name - it is a channel with promise 
> semantics.
>

-- 
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: How is core.async/go related to go-lang's concurrency?

[Paul deGrandis]

I'm sure Timothy Baldridge will speak to the core.async specifics, but I'll 
offer a high level.

libmill is a library for C coroutines (using jumps), with Go-style syntax.  
It's more similar to Lua's coroutines than Go's goroutines.  In libmill, 
there is only one thread performing the concurrency (and all the issues of 
combining coroutines with pthread apply).

Go uses a threadpool to run as many goroutines in parallel as possible - 
it'd be like backing libmill's scheduler with a threadpool.

Clojure's core.async is based on Go's goroutines - there is a threadpool 
and execution happens in parallel when possible.

Cheers,
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: Awesome Clojure Engineer Opportunity

['Jan-Paul Bultmann' via Clojure]

Hey Rameen,

Cool, I didn’t know that Apple was using Clojure internally.

Cheers, Jan

> On 12 Oct 2015, at 22:00, Rameen Fattahi  wrote:
> 
> Hi Everyone,
> 
> My name is Rameen and I'm looking for a passionate Clojure engineer for a 
> very confidential project at one of the biggest companies in the world 
> (cannot name it here for privacy reasons).
> 
> This is a full time role on our Applied Machine Learning team. If you're 
> interested, please send me your resume and I'd be happy to chat with you.
> 
> Thanks a lot,
> Rameen Fattahi, Technical Recruiter
> 
> 
> -- 
> 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: rand-nth on empty collections

['Jan-Paul Bultmann' via Clojure]

Throwing an exception is probably the right thing to do if it's supposed to 
closely model the behavior of `nth`, but it wonder if it's the most usefull 
behavior in practice.
I would guess that it introduces `not-empty` checks everywhere, instead of only 
for the cases where you want to be shure that the nil returned is actually an 
element of the collection.

cheers Jan

> On 30 Sep 2015, at 20:18, Mark Engelberg  wrote:
> 
>> On Wed, Sep 30, 2015 at 12:14 PM, Mark Engelberg  
>> wrote:
>> I also think it makes perfect sense for rand-nth to throw an error on an 
>> empty collection.  That's because the first step is it needs to generate a 
>> random number between 0 and the length of the collection (0), which is 
>> impossible.  So it should throw an error.  Note that it is the *random 
>> generation of the index*, not the nth that conceptually is throwing the 
>> error.
> 
> To be clear, when I say that nth "conceptually is throwing the error", I just 
> mean that's how I rationalize Clojure's behavior.  That's not really what's 
> going on.  (rand-int 0) returns 0 (which it probably shouldn't, given that 
> the input is meant to be an exclusive upper bound).  So in fact, the error is 
> thrown by clojure.lang.RT.nthFrom, which is surprising.
> 
>  
> -- 
> 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: Clojure/Pedestal vs Go

[Paul deGrandis]

Hi Alan,

Thanks for reaching out on the Pedestal mailing list!
Most web benchmarks care more about throughput and concurrent connection 
than latency, but sadly, nearly all benchmarks show these measurements as 
scalars instead of distributions.  The "errors" number is the number of 
requests that resulted in a server error (because of 
overload/mishandling).  A robust server that correctly understands 
back-pressure and can efficiently process requests on a queue should result 
in no errors, assuming that it can process the queued requests at the rate 
in which they're being received.

The "keepalive" flag refers to TCP keepalive, which will affect speed and 
connection timeout.

While I'm not aware of any benchmark between Pedestal and Go, I would be 
highly skeptical of such a benchmark.  Web benchmarks are often very 
misleading - they represent an application you'd never write, integrated 
into a server in a way you'd never do, just to get the highest overall 
number possible.  I would instead encourage you to look for measurements 
related directly to the quality attributes you care about, for the specific 
pieces of your overall application.  I'd also think about what you're 
really trying to optimize.

With Clojure you get the power of Lisp - you get to use go-channels, 
property-based generative testing, pattern matching, logic programming - 
all as libraries.  You can extend the language however you need, to build 
the most efficient system.  Hell, you can even write directly to the LLVM 
<https://github.com/halgari/mjolnir> compiler to get bare-metal speed 
(again, just a library).  You get the power and speed of interactive 
development, with the focus of small, composable, functional units (first 
class functions, immutable data structures, protocols).
I recently needed to do very fast binary processing for a wire protocol, 
and I was able to utilize Netty within Clojure to do the entire thing 
off-heap (no GC impact), and with native byte handling - Clojure gives you 
immediate access to the powerful library ecosystem on the JVM.  You can 
even connect your editor to a running system to inspect, debug, evolve, and 
patch it.

While Golang's community is growing and great libraries are appearing in 
the ecosystem (Pedestal's router 
<https://github.com/pedestal/pedestal/pull/330> was heavily influenced by 
httprouter), the language and runtime aren't nearly as powerful as Clojure, 
for me.  I have far greater flexibility and power with Clojure, and the 
opportunity to optimize my application and process where it matters most.

We benchmark Pedestal against other web libraries with real production 
systems.  In every benchmark we've done so far, Pedestal has come out on 
top.  We also look at more than just runtime performance characteristics - 
we consider code size, system complexity, etc.
Additionally Pedestal is secure by default - all of the best security 
practices are automatically enabled in Pedestal (you have to explicitly 
asked for them to be turned off).  We're also only one of two Clojure web 
systems that is truly asynchronous.  You can also take a look at Pedestal's 
other notable features 
<https://github.com/pedestal/pedestal#notable-capabilities>.

Hope this helps!  Reach out with any other questions you may have.

Regards,
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: Advice on introducing a Java dev to Clojure

[Paul deGrandis]

I have had success here with a few approaches.

For every company I work with that is new to Clojure, I provide them with a 
Quick Learn document.  The document is split into 5-7 days, and every day 
they skim/read an article, poke around a resource (like ClojureDocs), and 
watch a talk.  Sometimes that resource item is an exercise or something 
interactive.

Your goal should never be to convince someone of Clojure - Clojure itself 
is convincing enough.  Instead motivate someone to want to learn more - get 
them curious and self-driven to dive in wherever their interests lay.  Get 
them well adapted to the Clojure culture and the radical approach to 
simplicity.  Get them questioning their own practices and technologies.  
Entice them with the functional approach to system creation.

Leon mentioned my talk, which claims, Clojure manages risk better than any 
other technology - 
http://www.infoq.com/presentations/Clojure-powered-Startups
For well-established enterprise shops, I think my most recent Conj talk is 
more convincing - https://www.youtube.com/watch?v=BNkYYYyfF48

Consider the following talks by Rich:
 * Clojure, Made Simple - https://www.youtube.com/watch?v=VSdnJDO-xdg
 * Are we there yet? - 
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
 * Simple Made Easy - http://www.infoq.com/presentations/Simple-Made-Easy

Nothing is more convincing than a working system.  If it's possible, 
illustrate the virtues of Clojure and its approach to problem solving by 
walking the walk on a small scale, where the stakes and risks are low.  
Build a tool, prototype an idea in half the time it would normally take, 
show the power of Protocols within your own existing system, etc.

Regards,
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: [ANN] clj-kafka 0.3.1

[Paul Ingles]

Understood- almost all the functions in the zk namespace were intended for 
occasional/admin type use so they open/close the ZK connection.

It should be pretty easy to refactor that around so connections are passed 
in (allowing you to retain a connection across multiple operations).

I'll see if I can get time today to do it. If not I'd happily take pull 
requests :)


On Monday, June 15, 2015 at 5:29:30 PM UTC+1, Omri Hurvitz wrote:

 I see it now. I am concerned though that this will create a new zk 
 connection every time I use it. 

 On Friday, June 12, 2015 at 1:46:46 PM UTC-4, Ragnar Dahlén wrote:

 Hi Omri,

 There's clj-kafka.zk/set-offset! for exactly that purpose: 
 https://pingles.github.io/clj-kafka/clj-kafka.zk.html#var-set-offset.21

 Thanks,
 Ragnar

 On Friday, 12 June 2015 18:23:23 UTC+1, Omri Hurvitz wrote:

 Hi Paul.

 This looks great - I am looking forward to replace my hacked wrapper for 
 the Java (and Scala...) API with this code.
 One question: if I have a zk consumer stream with auto.commit.enable set 
 to false, how do I manually commit the changes?

 Thanks,

   Omri

 On Friday, June 12, 2015 at 11:35:44 AM UTC-4, Paul Ingles wrote:

 Hi all,


 I'm delighted to say 0.3.1 is released and available on Clojars.


 It's been a long while since we've made any big changes to clj-kafka so 
 I'm very happy to say we've caught up over the past couple of days. Most 
 of 
 the changes were the result of submissions from the community but I have 
 to 
 give most of the credit to Ragnar Dahlen :)


 Notable changes:


 - Refactored Zookeeper consumer to expose underlying streams 
 (transducer compatible :)

 - New Producer API support

 - Topic Administration

 - Updated to Kafka 0.8.2.1

 - Removed Kafka deps from clj-kafka


 https://github.com/pingles/clj-kafka/

 http://pingles.github.io/clj-kafka/



 Zookeeper Consumer

 =

 We've broken the old messages function apart into two pieces: 
 create-message-stream will connect the consumer to a message stream (topic 
 + number of threads when consuming more than 1 partition) and stream-seq 
 (recast the stream as a lazy sequence as with earlier releases).


 This change addresses a bunch of other requests/changes people had 
 submitted. Hopefully most stuff that was a little tough to do before is 
 now 
 easier to integrate- composition with other libs like manifold[1] should 
 be 
 easier.


 Transducer Support

 

 This also means that the lib is easier to use with transducers[2] which 
 should be useful for people doing stream processing.



 New Producer API

 ==

 We have integrated support for the New Producer API[3,4]. This is 
 asynchronous by default but provides both futures and callbacks to return 
 the offset/error.


 Topic Administration

 

 A new namespace exists that wraps some of the Kafka admin utils for 
 checking if topics exist, creating/removing topics and changing per-topic 
 configuration.


 No Kafka deps in clj-kafka

 

 I think* this was inherited from back when the Kafka releases had no 
 dependencies specified and so clj-kafka had to specify them instead. This 
 is no longer necessary so the project config is substantially tidier. This 
 is quite a substantial difference so please just check that this doesn't 
 break anything you were depending on.




 1) https://github.com/ztellman/manifold

 2) 
 https://github.com/pingles/clj-kafka/blob/master/README.md#usage-with-transducers

 3) 
 http://blog.confluent.io/2014/12/02/whats-coming-in-apache-kafka-0-8-2/

 4) 
 http://kafka.apache.org/082/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

 5) 
 https://github.com/pingles/clj-kafka/blob/master/README.md#administration-operations



-- 
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] clj-kafka 0.3.1

[Paul Ingles]

 

Hi all,


I'm delighted to say 0.3.1 is released and available on Clojars.


It's been a long while since we've made any big changes to clj-kafka so I'm 
very happy to say we've caught up over the past couple of days. Most of the 
changes were the result of submissions from the community but I have to 
give most of the credit to Ragnar Dahlen :)


Notable changes:


- Refactored Zookeeper consumer to expose underlying streams (transducer 
compatible :)

- New Producer API support

- Topic Administration

- Updated to Kafka 0.8.2.1

- Removed Kafka deps from clj-kafka


https://github.com/pingles/clj-kafka/

http://pingles.github.io/clj-kafka/



Zookeeper Consumer

=

We've broken the old messages function apart into two pieces: 
create-message-stream will connect the consumer to a message stream (topic 
+ number of threads when consuming more than 1 partition) and stream-seq 
(recast the stream as a lazy sequence as with earlier releases).


This change addresses a bunch of other requests/changes people had 
submitted. Hopefully most stuff that was a little tough to do before is now 
easier to integrate- composition with other libs like manifold[1] should be 
easier.


Transducer Support



This also means that the lib is easier to use with transducers[2] which 
should be useful for people doing stream processing.



New Producer API

==

We have integrated support for the New Producer API[3,4]. This is 
asynchronous by default but provides both futures and callbacks to return 
the offset/error.


Topic Administration



A new namespace exists that wraps some of the Kafka admin utils for 
checking if topics exist, creating/removing topics and changing per-topic 
configuration.


No Kafka deps in clj-kafka



I think* this was inherited from back when the Kafka releases had no 
dependencies specified and so clj-kafka had to specify them instead. This 
is no longer necessary so the project config is substantially tidier. This 
is quite a substantial difference so please just check that this doesn't 
break anything you were depending on.




1) https://github.com/ztellman/manifold

2) 
https://github.com/pingles/clj-kafka/blob/master/README.md#usage-with-transducers

3) http://blog.confluent.io/2014/12/02/whats-coming-in-apache-kafka-0-8-2/

4) 
http://kafka.apache.org/082/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

5) 
https://github.com/pingles/clj-kafka/blob/master/README.md#administration-operations

-- 
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] Pedestal 0.4.0 and doc updates

[Paul deGrandis]

Hi all,

Pedestal https://github.com/pedestal/pedestal 0.4.0 has been released, 
featuring:

   - A very fast and efficient prefix-tree router
   - The ability to plug-in new routers
   - A simplified and improved Interceptor API
   - Advanced error handling capabilities for async systems
   - and more!
   
For a list of all changes, please see the release notes 
https://github.com/pedestal/pedestal/releases.

Additionally, the README 
https://github.com/pedestal/pedestal#notable-capabilities has been 
updated to highlight why Pedestal is a compelling option when building 
Clojure web services.
I encourage everyone to give Pedestal another look!

Cheers,
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: [ANN] Pedestal 0.4.0 and doc updates

[Paul deGrandis]

Effort was invested in updating the `samples 
https://github.com/pedestal/pedestal/tree/master/samples` over the docs, 
since it seemed like more people used those and we knew there were 
architectural changes coming down the roadmap.  We added the API docs 
http://pedestal.github.io/pedestal/ which we update with every version.  
The prose-oriented documentation will be updated immediately after the 
0.5.0 releases (which have the last significant change - Pedestal will no 
longer be Servlet-specific, but rather Servlet-optional).

Given the API docs, the updated samples, and the wealth of information and 
help on the mailing list 
https://groups.google.com/forum/#!forum/pedestal-users, now is a great 
time to take another look.  The APIs have gotten smaller and simpler, the 
performance and default security have greatly improved, and there are 
unique, compelling features within Pedestal that make it clearly stand out 
from the pack.

Cheers,
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: [ANN] darwin and algebolic - genetic algorithms, and evolving mathematics

[Paul deGrandis]

It's great to see all of these!  Thank you both!

Cheers,
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: Embedded systems and transpiling Clojure to Nim

[Paul deGrandis]

Hi Alan,

Yep, you can cross compile the output from Terra - you can even set it up 
to output compilations dynamically for any platform you want.  Replacing 
LuaJIT with Lua would just be a matter of changing the library that you 
link when building Terra itself.  As Timothy pointed out, Pixie is just 
going to be C, so you should be able to cross-compile the base for whatever 
platform you need (someone recently blogged about putting Pixie on the 
Raspberry Pi).

Cheers,
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: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Paul deGrandis]

This is for Sean specifically, but hopefully this will clear some things up 
for other people

I would argue that Pedestal is perhaps objectively simpler than Ring.  I 
would also add it's more performant, more flexible, and more secure (by 
default).

In Pedestal, everything is an interceptor - a record that has `:enter`, 
`:leave`, and `:error` actions/functions (there is no distinction between 
handlers and middleware).  Interceptors take a context (a map that holds 
the `:request` and `:response`), and returns a context.  Requests and 
Responses are exactly the same as they are in Ring.  As soon as a 
`:response` is present in the context, it's returned through the 
interceptor chain (sent to the client and processing is stopped).  If you 
want to go async, your interceptor returns a core.async channel (instead of 
a context), which will eventually receive a context.  Your response bodies 
can be just about anything, including NIO things (byte-buffers, etc.).

Everything in Pedestal is programmed against a protocol, allowing you to 
extend every piece of the system to fit your application.

By default, Pedestal uses secure headers, CSRF protection, and a host of 
other best-practices for secure web services.

You know how everything works in Pedestal.  Release notes are very 
detailed: https://github.com/pedestal/pedestal/releases

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

Job opening at Teradata

[Paul Gearon]

Hi,

Our team at Teradata is looking for new Clojure devs. Ideally we are hoping
to find people in/around Boston, but we are prepared to consider remote
candidates for the right people.

The role involves a lot of interaction with Hadoop, with all the metadata
for managing datasets stored in Datomic. The job description mentions a
functional language such as Clojure but this is just to advertise for a
wider field of candidates. Any candidates who are unfamiliar with Clojure
would be expected to learn.

Details can be found at:

https://teradata.taleo.net/careersection/prof/jobdetail.ftl?job=160789


For people unfamiliar with Teradata Loom, our team used to be with
Revelytix until the company was acquired by Teradata last year.

Regards,
Paul Gearon

-- 
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: Dynamic/Convention-based routing libraries? (was: Clojure needs a web framework with more momentum

[Paul deGrandis]

Hi Sean,

Pedestal's router is just an interceptor in the chain.  You could easily 
write an interceptor that looks at the request and sees if it can resolve a 
var by that name.  You could even stack multiple routers - first the var/fn 
lookup and failing that, a more explicit router.

Cheers,
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: Embedded systems and transpiling Clojure to Nim

[Paul deGrandis]

I'm just going to echo a few things -

Timothy and I have talked at length about Clojure-like languages on other 
platforms.  His ideas and general approach have led to some very promising 
work (Pixie), and I can personally vouch for RPython as a platform.  My 
ideas led me to Terra ( http://terralang.org ) - which supports LLVM-based 
compilation (AOT and JIT), dynamic typing/programming via LuaJit 
integration, macros and AST manipulation, etc.  Based on this and some 
needs I was trying to fill, I produced cljs-terra ( 
https://github.com/ohpauleez/cljs-terra ).  The trade-off is the that 
library support is a mix of Lua and C libs all intertwined.

There is also the option of ClojureScript on top of Node.js (which I 
recently used for an IoT system) - which has an ecosystem of libraries.

All of that aside, I still tend to do my low-level work in C and C++14, 
with some Lua and Terra occasionally.  I also recently used Oracle's 
Embedded JVM with great success (producing a custom JRE for exactly what I 
needed).

Cheers,
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: Clojure web server capacity

[Paul deGrandis]

Also note that Compojure (and Ring) applications are artificially limiting, 
because they cannot utilize the containers' full capabilities (Ring apps 
can't go async at the container level, they can't use NIO responses, etc).

For these use-cases, you'll have to program directly to container itself, 
use Pedestal (limiting to the Servlet-only case), or use Aleph (rides on 
top of Netty).

I'd also encourage you to reconsider your benchmark - ask yourself, What 
does this really tell me?  Is the benchmark an accurate representation of 
the kinds of HTTP services you build?  Are the payloads (parsing and 
generation) representative of common data you deal with in the systems you 
build?  Is the network, topology, and traffic generation realistic (or at 
least analogous) to production systems?  Can the results of the benchmark 
directly inform architectural considerations of real systems?

Food for thought!  Good luck!

Cheers,
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: How to coerce to bigint ?

[Paul Roush]

On Saturday, April 4, 2015 at 12:09:36 PM UTC-4, Andy Fingerhut wrote:



 On Sat, Apr 4, 2015 at 8:52 AM, Paul Roush pro...@gmail.com javascript:
  wrote:

 I have 2 questions related to bigints.

 1) I've read things suggesting Clojure auto-converts between int, long, 
 and bigint to prevent overflow.  That isn't the behavior I've experienced.  
 Did something change from an older release of Clojure to more recent ones?


 Clojure 1.2 and earlier auto-promoted, if I recall correctly, but that has 
 not been the case since Clojure 1.3, released in Sep 2011.  You may have 
 found something published before then.

 Clojure 1.3 and later do give a bigint result for integer arithmetic if 
 any of the arguments are bigints, e.g. (+ 1N 1) = 2N



Thanks for the historical info. 

 


 2) I found myself wanting to write a function that would use bigint math 
 vs not depending on whether I passed a bigint in as arg.  Internally I 
 wanted to seed a reduce call with either 1 or 1N as appropriate.  So I 
 wanted to write something like this (except I'd like it to work):

 (defn foo [n]
   (cast (type n) 1))

 ; (foo 3) = 1
 ; (foo 42N) = 1N

 The following works, but I'd like to understand if I can avoid the 
 conditional:

 (defn foo [n]
   (if (= clojure.lang.BigInt (type n)) 1N 1))


 More commonly I have seen (instance? clojure.lang.BigInt n) rather than (= 
 clojure.lang.BigInt (type n)), but I do not know any way to avoid the 
 conditional here.

 I would ask that you consider whether you really do need this check, 
 though, since if your argument is BigInt and is combined with any 
 arithmetic operation with a local long value in the function, the result 
 will be BigInt.

 Andy


I like your conditional better, so seeing that is welcome.

Regarding the last point, I understand that what you say is generally true, 
but in this specific case my function arg was defining the end of a 'range' 
call that was fed into other logic.

(range  5N) = (0 1 2 3 4)  ;  i.e. the bigint-ness is lost

So in this particular case I needed to inject bigint into the process 
later in some way.

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

How to coerce to bigint ?

[Paul Roush]

I have 2 questions related to bigints.

1) I've read things suggesting Clojure auto-converts between int, long, and 
bigint to prevent overflow.  That isn't the behavior I've experienced.  Did 
something change from an older release of Clojure to more recent ones?

2) I found myself wanting to write a function that would use bigint math vs 
not depending on whether I passed a bigint in as arg.  Internally I wanted 
to seed a reduce call with either 1 or 1N as appropriate.  So I wanted to 
write something like this (except I'd like it to work):

(defn foo [n]
  (cast (type n) 1))

; (foo 3) = 1
; (foo 42N) = 1N

The following works, but I'd like to understand if I can avoid the 
conditional:

(defn foo [n]
  (if (= clojure.lang.BigInt (type n)) 1N 1))

-- 
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: Newbie question about filtrering defrecord

[Paul L. Snyder]

On Sun, 05 Apr 2015, Michael Blume wrote:

 your list doesn't contain the records, your list contains the symbols 'a1
 and 'a2. You can't make a list the way you're trying to.

To be specific, you're quoting the list in your def, so the a1 and a2 symbols 
are
not evaluated.

  user= (defrecord Ape [fname lname])
  user.Ape
  user= (def a1 (-Ape test1 test2))
  #'user/a1
  user= (def a2 (-Ape test3 test4))
  #'user/a2

  user= '(a1 a2)
  (a1 a2)
  user= (quote (a1 a2))
  (a1 a2)
  user= (list a1 a2)
  (#user.Ape{:fname test1, :lname test2} #user.Ape{:fname test3, :lname 
test4})

  user= (def alist (list a1 a2))
  #'user/alist
  user= (filter #(= test1 (:fname %)) alist)
  (#user.Ape{:fname test1, :lname test2})

  ;; Clojure idioms tend toward vectors and vector literals rather than
  ;; lists. If you have a background in Common Lisp or Scheme, this can
  ;; take some getting used to. One nice consequence is you don't have
  ;; to worry about quoting most of the time.
  user= (filter #(= test1 (:fname %)) [a1 a2])
  (#user.Ape{:fname test1, :lname test2})

Cheers,
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: How to coerce to bigint ?

[Paul Roush]

On Saturday, April 4, 2015 at 1:00:46 PM UTC-4, Michael Gardner wrote:

 On Sat, Apr 4, 2015 at 11:36 AM, Paul Roush pro...@gmail.com 
 javascript: wrote:

 (range  5N) = (0 1 2 3 4)  ;  i.e. the bigint-ness is lost

 So in this particular case I needed to inject bigint into the process 
 later in some way.


 You could try (range (* 0 n) n). A little silly, but does avoid the 
 conditional.

 You could consider also creating a JIRA issue asking for range to match 
 the type of its argument in the 1-arity case. No idea whether it would be 
 accepted, though. 


Interesting.  My code was actually calling range with 2 args, as I want a 
1-based range.  The 1 was a literal, and to support the non-bigint case I 
don't want to hardwire it to 1N.  Now I see that:

(range 1N 5N) = (1N  2N 3N 4N)
(range 1 5N) = (1 2 3 4)

So I could pass (/ n n ) as my first arg to range and I'll get the desired 
type in all cases.

But this behavior of 'range' now feels quirky to me.

-- 
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: Immutant survey

[Paul deGrandis]

Thanks for the summary!

I just want to publicly say thanks for Immutant and the hard work you, 
Toby, and others put into it.  It's a fantastic set of tools and libraries 
and deserves more recognition than it receives.

Cheers,
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: State of the Art in Clojure Debugging

[Paul deGrandis]

Because of the blocking nature of vim-fireplace (really of vim itself), 
you'll have to run most of the debuggers from a live, dedicated repl.

I've been slowly evolving my own debug-repl for a few years now.  It works 
in a `user.clj` setting or in a project related file.  At a quick glance, 
it supports the major features found in clj-debugger (file info exists, but 
no file pretty-print).  You can see a recent gist of it here: 
https://gist.github.com/ohpauleez/4ca0b646b89512f38ea2

Some people may want to rename `debug-repl` to `break`, and `quit-dr` to 
`continue`.

 * Locals are in a map, easy to print or consume
 * The debug repl captures the metadata about the call-site, so you can 
easily print the file contents based on that information
 * There's a shorthand to bounce the debugger into the namespace where the 
call happened, `in-debug-ns`
 * There's tooling/functions to make any uncaught exception trigger the 
debugger/repl
 * There's a `try-repl` (try an expression and launch the debugger/repl on 
an exception)
 * There's an `assert-repl` (like `try-repl` but with an assert - useful 
when testing function contracts/invariants)
 * One can make the debug repl return a new form into the call-site (at 
`quit`/`continue`) or establish a default one.
 * This debug repl nests correctly

In a more recent version (not in the gist), I've toyed with capturing 
stackframes as objects, allowing you to go up/down in the stack within a 
limited scope.  I don't think this is a particularly good idea, but in 
certain contexts, it works nicely.

While I've never used it, you may want to look at vim-redl - 
https://github.com/dgrnbrg/vim-redl.  You could also use emacs with evil, 
and then use ritz for a true JVM debugger - https://github.com/pallet/ritz

Cheers,
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: Is this the good way to write get-percentage

[Jan-Paul Bultmann]

I really don't think that calculating percentages warrants a DSL.
(I'm not even sure if percent warrants a function ;} )

`(round (percent ...))
 (round-up (percent ...))
 (round-down (percent ...))`

Seems far more readable to me than having a function that does many things at 
once, be it higher order, keyword configured or pre `comp`ed.

Cheers Jan

-- 
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: Architectural doubts

[Jan-Paul Bultmann]

Why not stream frames directly into the datomic db as they fall out of gloss?
This should be faster at query time anyhow due to indexes,
and let's datomic handle the memory management.

cheers Jan

 On 31 Jan 2015, at 11:39, Milton Silva milton...@gmail.com wrote:
 
 While using wireshark to analyse libpcap files (= 200 MB) I routinely think 
 that it would be great to preform relational queries but, wireshark only 
 supports search. 
 
 I thought I would decode the entire file, hold it in memory as clojure data 
 structures and use datomic's datalog.
 
 Besides relational queries, a requirement is for the file to be decoded 
 (libpcap, ethernet-II, IP, TCP, diameter) in less then a minute(for a 200MB) 
 and the typical queries should also be less than a minute.
 
 I thought the frames could be represented like this:
 
 {:frame-id 1
 :timestamp java's instant-object
 :src-mac string
 :dest-mac string
 :src-ip
 :dest-ip ...
 ...}
 
 {:frame-ids [1 3]
 :diameter-session-id ...}
 
 So, I started by using gloss to decode a 200MB file. Gloss is fantastic to 
 specify frames  but, it is not meeting the time requirements. It appear the 
 problem has to do with the creation of a lot of objects. Even with 3G of ram 
 for the heap, it still crawls to a halt.
 
 I could try to perform some experiments to determine approximate answers but, 
 I think it is better to talk with people with more experience in order to 
 avoid common pitfalls..
 My questions are:
 
 Will the JVM (with 3G) support a million hashmaps like the above?
 Is Buffy able to do something like what I want? 
 Will datomic be able to handle this use case? 
 What would you suggest to solve this(e.g. don't use clojure data structures.. 
 but then datomic's datalog is not available to query?)?
 -- 
 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: if-not implementation

[Jan-Paul Bultmann]

Even with inlining the code is rather silly ;)

[x] (if x false true)

so you'd get,

   (if (if test false true) then else)

Which relies a bit too much on the JVM's JIT for my taste :D

I've always wondered what the reason for the original implementation is.
Keep closer to the implementation of not, so that no incompatibilities arise
should not become a protocol one day?

Cheers Jan


 On 22 Jan 2015, at 01:32, Mikera mike.r.anderson...@gmail.com wrote:
 
 Interesting -  there seems to be a very slight performance advantage to your 
 version on my machine (consistently about 25% faster for if-nots in a tight 
 loop).
 
 I think the problem is actually with not - which isn't getting inlined 
 currently. If I patch not so that it is inlined, the difference disappears.
 
 Worth a quick patch maybe?
 
 On Thursday, 22 January 2015 03:51:37 UTC+8, Leon Grapenthin wrote:
 I am surprised to find the two branch implementation of if-not as follows:
 
 
 ([test then else]
`(if (not ~test) ~then ~else))
 
 
 What I expected was:
 
 
 ([test then else]
`(if ~test ~else ~then))
 
 
 -- 
 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 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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: DSL in RTL (Right to Left) languages.

[Jan-Paul Bultmann]

I would wrap everything in a tree walking macro that first reverses all lists 
and then starts evaluating other macros.

I'd love to see an Arabic clojure file btw :D
But non English source always makes me shudder a bit, one of the great things 
about programming is that everybody speaks English ;)

cheers Jan

 On 14 Jan 2015, at 05:52, clojure.u...@gmail.com wrote:
 
 Hi
 
 I need to write a dsl in Arabic which is a RTL. I am not sure how to get 
 started with such a dsl in clojure. Any pointers with be really appreciated.
 
 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.

-- 
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: A (foolish) plan to re-invent IO on top of core.async

[Paul deGrandis]

There was another discussion on this list regarding async IO and web 
servers.  It may be rather informative to you: 
https://groups.google.com/d/msg/clojure/rKqT13Ofy4k/H9xvkZA9Yy4J

To my knowledge, Pedestal is the only web library that let's you go async 
all the way down to the wire (potentially the latest Aleph also allows for 
this).  The benefit provided is that Pedestal manages the NIO integration 
directly with the container for you - optimized to the specific container.  
You may thumb through the implementation for some ideas.

You also have to be very mindful about back-pressure when using core.async 
in certain combinations.  Zach Tellman has covered the major points here: 
https://groups.google.com/d/msg/clojure/TVMQJwaij1U/dQxyBxxbIjQJ

Cheers,
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: Author a Book on Clojure - Packt Publishing

[Jan-Paul Bultmann]

Just my 50 cent.

I was asked to do a technical review on a Clojure podcasts by packtpub once.

The storyboard they send me consisted of a word file containing a huge table 
with text and source code.

Why would anybody send a technical reviewer source code in a word document, yet 
alone in a table column that has a width of 50 characters which causes it to 
line-wrap everywhere?!

It feels to me that this publisher is just a book mill that goes for quantity 
and not quality.
I couldn't make it thought a single book I bought from them because reading 
them felt like a waste of time.

Of course things might have changed by now and your mileage may vary.
I'm just thinking that if somebody takes the time of writing a book on Clojure,
it should at least be worthwhile.

All the best, Jan

 On 20 Dec 2014, at 09:07, Tushar Gupta tos...@gmail.com wrote:
 
 I am Tushar Gupta, an Acquisition Editor at Packt Publishing. We specialise 
 in publishing books, eBooks, video tutorials and articles for IT developers, 
 administrators and users. 
 We are currently planning to develop a book on Clojure Data structures and 
 Algorithms. 
 
 We are looking for an expert to author this book and share their knowledge 
 and skills with our readers.
 
 For more information you can mail me on tush...@packtpub.com.
 
 Looking forward to have some legit responses. :)
 
 -- 
 Regards,
 Tushar Gupta
 Acquisition Editor
 Packt Publishing 
 www.packtpub.com http://www.packtpub.com/
 Skype: packt.tusharg x-msg://4/tush...@packtpub.com%3C
 
 
 
 
 
 
 
 -- 
 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 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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: Getting sick and tired of [trace missing]

[Paul L. Snyder]

On Wed, 03 Dec 2014, Fluid Dynamics wrote:

 It's a giant pain to debug exceptions without stack traces. This seems to 
 be a problem specific to CCW, as I don't encounter it using other 
 development environments.
 
 Is this going to be fixed anytime soon?

Pseudonymous obnoxious person:

You have many options.

(a) Submit a (polite) issue to the CCW tracker with sufficient information
to reproduce the behavior. If an issue already exists, comment (politely)
on the issue to register that it's one toward which you would like the
project's volunteers to consider allocating their efforts.

(b) If the issue is of sufficient importance to you, offer a bounty
(payable in actual money) for an implementation of your desired behavior.
If you ask (politely), someone may be willing to implement it for you in
exchange for cash.

(c) Determine the source of the undesired behavior and implement a fix
yourself. I'd suspect the project's maintainers would happily entertain
a pull request. If you do not have sufficient knowledge to understand
how to approach an implementation, others may be willing to guide you if
you ask. Politely.

(d) Stop whinging and use the free software.

(e) Stop whinging and don't use the free software.

(f) Take your whinging somewhere else.

Moderators:

Many, many people sincerely attempted to help this person during the last
round of self-obsessed, abusive entitlement. May I request that you step in
if it looks like this thread is going down the same path?

I do not wish this community to become one that tolerates incivility.

  http://jacobian.org/writing/assholes/

Thanks to all of those on this list and behind the scenes who work to
support this great programming language, its tooling, and the vibrant
ecosystem of libraries.

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: If code is data why do we use text editors?

[Jan-Paul Bultmann]

Yeah this would be awesome, but sadly representing Clojure code as data is as 
hard as representing Java.
All the reader macros make it a nightmare, and the closest thing you'll get is 
tools.analyzer AST nodes.

Session is certainly a step in the right direction, and I wish more people 
would embrace it,
but it works on text as well. Same pretty much goes for codeq, if that is not 
dead.

One could define a Clojure subset that is valid EDN though,
which would make everything from serialisable functions to a nano-pass compiler 
a lot easier.
This has to be the first step imho.

Cheers Jan

 On 14 Nov 2014, at 17:09, atucker agjf.tuc...@gmail.com wrote:
 re
 As I understand it, Session https://github.com/kovasb/session and codeq 
 https://github.com/Datomic/codeq are tools that somehow keep your code in a 
 database instead of plain text.
 
 On Friday, 14 November 2014 12:42:57 UTC, Thomas Huber wrote:
 Hi, here is an idea that has been in my mind for a while. I wonder what you 
 think about it.
 
 In Clojure code is data, right? But when we program we manipulate flat text 
 files, not the data directly.
 Imagine your source code where a data structure (in memory). And programming 
 is done by manipulating this data structure. No text editor and text files 
 involved. 
 Your editor directly manipulates the source data and later saves it on disk 
 (maybe as a text file). 
 
 These are the benefits I can think of:
  - It enables you to use any Clojure function to manipulate your source 
 „code“. Giving you hole new opportunities for refactoring.This functions can 
 be provides as library. 
 
 - Really nice auto complete. 
 
 - Visual programming. Source code can be represented in many different ways 
 (not just text) . The easiest example I can think of is color. It can be 
 represented as text of course (#23FF02)
 but that’s a quite bad interface for humans. Why not display the actual color 
 and provide a color picker? Or what about music notes? Or Math formulars? Or 
 what about a tree view to move and rename functions like files? 
 This could all be implemented in a way that every library can ship there own 
 „views“. I think this „views“ are basically macros that are not limited to 
 text. 
 
 - You don’t have to worry that you text files are in the same state as your 
 JVM (when developing interactive). You only work on your sourcedata and it 
 gets loaded into the JVM automatically.
 
 - Answer questions about your source code. What is the most called function? 
 Who depends on this namespace? Where is this function used? What is the 
 biggest function? Thinks like that become easy. Again you can ship this 
 queries as a library.
 
 
 
 The drawback is you can’t simply program using any text editor. You need a 
 special tool. But we have that anyway (syntax highlighting, paredit etc.). 
 Nobody programs using a bare text editor. 
 
 Maybe this idea is not new? What do you think?
 
 -- 
 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 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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: a nicer way to write 1 - 2 + 3 - 4 ... +/- n

[Paul English]

You could use (-1)^{i+1}, which would be a bit more mathy but it may not be 
efficient.

(defn altsum [n] 
  (-
(range 1 (inc n))
(map #(* % (Math/pow -1 (inc %
(reduce +)))


On Nov 13, 2014, at 6:31 PM, Andy L core.as...@gmail.com wrote:

 Hi,
 
 All I was able to come up with was this 
 
 (defn altsum[n] (reduce + (map * (range 1 (inc n))  (interpose -1 (repeat 
 1)
 
 ... works quite well, however I was wondering if there is more idiomatic way 
 to write that.
 
 Thanks,
 Andy
 
 -- 
 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: better way to group consecutive numbers in a vector?

[Jan-Paul Bultmann]

I think what you want is `partition-between` as implemented by amalloys useful 
lib 
(https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224
 
https://github.com/amalloy/useful/blob/develop/src/flatland/useful/seq.clj#L224).

`(partition-between (fn [x y]
(not= (inc x) y))
   coll)`

Why this isn’t in the standard library is beyond me tbh,
as `partition-by` is a special case for `partition-between`.

`(def partition-by (partial partition-between not=))`

Maybe adding it to clojure.core should be considered?
Also I’d be intrigued to know the rationale behind `partition-by`.

Cheers, Jan

 On 07 Nov 2014, at 18:56, Alex Hammel ahamme...@gmail.com wrote:
 
 Here's my take on the 'add delimiters and split' approach. Bonus `congeal 
 function, which chunks collections on any condition you like:
 
 (defn- insert-gaps
   [coll pred gap-symbol]
   (reduce (fn [acc x]
 (if (pred (peek acc) x)
 (conj acc x)
 (conj acc gap-symbol x)))
   [(first coll)]
   (rest coll)))
 
 (defn split-coll
   [coll delimiter]
   (- coll
(partition-by (partial = delimiter))
(remove (partial = (list delimiter)
 
 (defn congeal
   [pred coll]
   (let [gap-symbol (gensym)]
 (- coll
 (insert-gaps pred gap-symbol)
 (split-coll gap-symbol
 
 (defn consecutive? [p q]
   (= (inc p) q))
 
 (println (congeal consecutive? [1 3 4 5 7 9 10 11 12]))
 #= ((1) (3 4 5) (7) (9 10 11 12))
 (println (congeal  [1 2 3 1 2 3 1 2 3]))
 #= ((1 2 3) (1 2 3) (1 2 3))
 (println (congeal not= [:foo :foo :bar :bar :foo :bar]))
 #= ((:foo) (:foo :bar) (:bar :foo :bar))
 
 
 
 
 On Fri, Nov 7, 2014 at 4:09 AM, Paweł Rozynek pro...@gmail.com 
 mailto:pro...@gmail.com wrote:
 (def data '(1 3 4 5 7 9 10 11 12))
 (map #(map last %) (partition-by #(apply - %) (map-indexed vector data))) = 
 ((1) (3 4 5) (7) (9 10 11 12))
 
 regards
 PR
 
 
 -- 
 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 
 mailto: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 
 mailto:clojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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: [ANN] Quickie 0.3.5

[Paul deGrandis]

Congrats on publishing the tool!

Just to clarify - this isn't quite a parallel test runner.  You're just 
testing the namespaces in parallel.

Consider the case where you have 5 namespaces, 4 of which have a single 
test in them, and one of which has 100 tests in it.  Assume all tests have 
two assertions.
In this scenario, your test suite will actually run faster in a standard, 
serial test run, than in the parallel (by namespace) test run.

Feel free to benchmark your testing tool against Pedestal's test suite - 
it's a good mix of different size testing namespaces.

Cheers,
Paul

On Tuesday, October 14, 2014 4:00:57 PM UTC-4, Jake Pearson wrote:

 Hi,
 I got to spend some hack days and created a parallel test runner for 
 clojure.test. It is part of an autotester I wrote a couple of years ago 
 called quickie. To run your tests add [quickie 0.3.5] to your :plugins. 
 Then run lein quickp. Stacktraces get filtered. The return code is equal to 
 the number of failed tests, so a return code of 0 is a passing test run.

 If you use with-redefs, you will probably want to switch over to the 
 with-local-redefs function from the gist below:

 https://gist.github.com/gfredericks/7143494

 https://github.com/jakepearson/quickie

 Enjoy,
 Jake


-- 
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: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

Transducers build up transformation steps, with new generic operations like  
single arg `map` and `filter`, and then apply these transformations to a 
collection using an evaluation function.
This function decides if operations are done lazily, eagerly, or on a channel.

Note that while this makes the place where laziness occurs more obvious, it is 
not really new.
You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
While `mapv` or `filterv` are not.


On 11 Oct 2014, at 00:28, Mars0i marsh...@logical.net wrote:

 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 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: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

I feel that there are some misconceptions here,
Clojure is not a language that has lazy evaluation,
but is instead completely eager.
Macros are the closest thing that come to laziness, but they are still 
different.
However, Clojure has a data structure, that also serves as an abstraction layer,
that implements laziness, called a sequence or seq.

Therefor turning of laziness makes no real sense. You could say disable the 
laziness of seqs,
but that doesn't really make sense either. It's like disabling the FIFO nature 
of a queue or a channel.
If you don't want the properties of a seq, then use another data structure, 
like a vector.


On 11 Oct 2014, at 18:14, Mars0i marsh...@logical.net wrote:

 Thanks Jan-Paul.  That's helpful.  I wonder whether, if all lazy functions 
 were rewritten in terms of transducers, it would then be easy to turn 
 laziness on and off.  (I am not suggesting that this should be done.  No 
 doubt it would entail a lot of work, and performance tradeoffs.  I'm quite 
 happy with Clojure as it is, despite anything negative I might say about 
 impacts of laziness in some circumstances.)
 
 On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote:
 Transducers build up transformation steps, with new generic operations like  
 single arg `map` and `filter`, and then apply these transformations to a 
 collection using an evaluation function.
 This function decides if operations are done lazily, eagerly, or on a channel.
 
 Note that while this makes the place where laziness occurs more obvious, it 
 is not really new.
 You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
 While `mapv` or `filterv` are not.
 
 
 On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote:
 
 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 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.

-- 
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: Schrodinger's cat in clojure?

[Jan-Paul Bultmann]

Yes you are right, currently a lot of stuff is seq only.
I think that reducers provide a lot of eager operations, but not everything.

So yeah, transducers are exactly what you are looking for.

If you call `sequence` with the transducer you get laziness, if you call `into` 
with a collection and a transducer, you get eagerness :).
No decision about the evaluation strategy has to be made up until that point, 
and afaik transducers implement most classical seq constructs.

On 11 Oct 2014, at 21:09, Mars0i marsh...@logical.net wrote:

 I don't think I have any misconceptions.  I probably haven't expressed myself 
 clearly.  Clojure has many very useful functions that return lazy sequences.  
 Analogous functions in other languages perform what are exactly the same 
 operations, except for the fact that what's returned is not a lazy sequence, 
 but instead is a different kind of sequential structure.  For example, Common 
 Lisp'smapcar is very much like Clojure's map, but mapcar returns a (non-lazy) 
 singly-linked list.  As you point out, there are also functions in Clojure 
 that return sequential structures that are not lazy.  Moreover, it's easy to 
 convert a lazy sequence into a non-lazy sequence through use of, for example, 
 doall or vec.
 
 However, writing code in Clojure that only used non-lazy sequences would be 
 unnatural and verbose, as Lee points out.  No one would bother doing that.  
 Part of what's great about Clojure is the convenience of its set of sequence 
 operations.  If you're not using those, you're not getting full benefit from 
 Clojure.  So as a practical matter, one must deal with laziness in Clojure.  
 
 However, almost the same language could be constructed without any laziness, 
 just by replacing lazy functions such as map with non-lazy analogues.  In 
 that case, you could do all of the same things in those situations that don't 
 require laziness.  (You couldn't use lazy infinite sequences, and you'd have 
 to worry about keeping large data structures in memory, etc.  But in many 
 situations, those features aren't needed.)  
 
 That's what I mean by turning off laziness: Replacing every function that 
 returns a lazy sequence with its closest non-lazy analogue.
 
 On Saturday, October 11, 2014 12:01:34 PM UTC-5, Jan-Paul Bultmann wrote:
 I feel that there are some misconceptions here,
 Clojure is not a language that has lazy evaluation,
 but is instead completely eager.
 Macros are the closest thing that come to laziness, but they are still 
 different.
 However, Clojure has a data structure, that also serves as an abstraction 
 layer,
 that implements laziness, called a sequence or seq.
 
 Therefor turning of laziness makes no real sense. You could say disable 
 the laziness of seqs,
 but that doesn't really make sense either. It's like disabling the FIFO 
 nature of a queue or a channel.
 If you don't want the properties of a seq, then use another data structure, 
 like a vector.
 
 
 On 11 Oct 2014, at 18:14, Mars0i mars...@logical.net wrote:
 
 Thanks Jan-Paul.  That's helpful.  I wonder whether, if all lazy functions 
 were rewritten in terms of transducers, it would then be easy to turn 
 laziness on and off.  (I am not suggesting that this should be done.  No 
 doubt it would entail a lot of work, and performance tradeoffs.  I'm quite 
 happy with Clojure as it is, despite anything negative I might say about 
 impacts of laziness in some circumstances.)
 
 On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote:
 Transducers build up transformation steps, with new generic operations like  
 single arg `map` and `filter`, and then apply these transformations to a 
 collection using an evaluation function.
 This function decides if operations are done lazily, eagerly, or on a 
 channel.
 
 Note that while this makes the place where laziness occurs more obvious, it 
 is not really new.
 You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. 
 While `mapv` or `filterv` are not.
 
 
 On 11 Oct 2014, at 00:28, Mars0i mars...@logical.net wrote:
 
 
 
 On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote:
  Maybe an ideal world would be one in which there was a global setting to 
 turn laziness on and off.  When you want it, have it, and know your risks.  
 After looking at the source for some of the lazy functions, I've come to 
 suspect that such a feature would be completely nontrivial.
 
 Oh, wait, Rich Hickey's blog post about transducers says:
 
 But transducers can also be used for:
 
 a la carte laziness
 ...
 collection/iteration/laziness-free transforming reductions 
 
 Not certain what this means.  Haven't fully grokked reducers.
 
 -- 
 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

ANN: Pedestal 0.3.1

[Paul deGrandis]

I'm extremely happy to announce the release of Pedestal 0.3.1

In this release you'll find many goodies:
 * NIO support
 * Immutant added as a platform type
 * Transit support
 * Improved SSE capabilities
 * A new route format
 * And more

Please see the official release notes for all of the details: 
https://github.com/pedestal/pedestal/releases/tag/0.3.1

Thanks to everyone who helped out in anyway, and many thanks to those who 
are happily using Pedestal.  There's even more great stuff coming up in the 
next release!

Cheers,
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: `as-` does not work with `recur`.

[Jan-Paul Bultmann]

Ah thanks, I did a JIRA search for `as-`  before but nothing had popped up.


On 05 Oct 2014, at 03:06, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote:

 This issue has been reported
 
 May be you should upvote this..
 
 http://dev.clojure.org/jira/browse/CLJ-1418
 
 
 
 On Sun, Oct 5, 2014 at 4:56 AM, Leon Grapenthin grapenthinl...@gmail.com 
 wrote:
 Thought:
 
 (defmacro as-
 [expr name  forms]
 `(let [~name ~expr
~@(interleave (repeat name) (butlast forms))]
~(last forms)))
 
 
 
 
 On Sunday, October 5, 2014 1:02:50 AM UTC+2, Jan-Paul Bultmann wrote:
 Hey, 
 I just noticed that while recur can be the last statement in most threading 
 macros, 
 it can't be used within an `as-` macro. 
 
   user= (macroexpand '(- x (recur))) 
   (recur x) 
 
   user= (macroexpand '(as- x % (recur %))) 
   (let* [% x % (recur %)] %) 
 
 This means that a recur within a `as-` will cause a CompilerException, 
 because it is not at the tail position. 
 
 Thoughts? 
 
 Cheers, 
 Jan-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.
 
 
 -- 
 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.