Re: [ANN] Discontinuing 4clojure.com

[Colin Yates]

Thanks for all your work Alan - a decade is a lifetime in open source :-).

Sent from my iPhone

> On 4 Jul 2021, at 21:26, Alan Malloy  wrote:
> 
> 
> TL;DR: Turning off 4clojure.com by the end of July 2021
> 
> Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
> 4clojure.com over the last week. The old decrepit system 4clojure runs on has 
> finally gotten out of date enough that I can't even figure out how to get it 
> recent enough that SSL certs will auto-renew anymore.
> 
> In principle I could start from scratch on a new server and move 4clojure 
> over, but I won't. 4clojure has been piggybacking along on a server that I 
> use for personal reasons, and over the years I have less and less reason to 
> keep paying for that server - it's now pretty much just 4clojure costing me 
> an embarrassing amount of money every month because I haven't wanted to 
> disappoint the community by shutting it down. This SSL thing is just what 
> made me finally pull the trigger.
> 
> I don't have a specific EOL date in mind, but sometime near the end of the 
> month, since that's the billing cycle. Until that time, 4clojure still works, 
> as long as you don't mind clicking through the security warnings - it really 
> is still me hosting the site, and since the connection is still HTTPS (albeit 
> with an invalid cert) I think that means your data is still safe. If you have 
> solutions to problems you're proud of, you've still got some time to print 
> them out and put them up on your refrigerator.
> 
> I'm not seeking new maintainers. I'd feel uncomfortable handing over a 
> database with so many email addresses and password hashes in it to anyone. 
> The service has had a good run - just over a decade since the first release. 
> I hope you enjoyed it during that time.
> -- 
> 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/385cdef8-fa40-47ba-b5b1-0b3a7cc34935n%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/0AB2143D-E87D-4BCD-B590-EB895B06044B%40gmail.com.

Re: 100x startup for Clojure using GraalVM

[Colin Yates]

Do we have any idea how that memory saving scales? 

I know a bunch of meta data isn’t needed as it is hotspot specific, but are 
there any other memory savings?

Sent from my iPhone

> On 12 Nov 2019, at 18:42, Alan Thompson  wrote:
> 
> In my initial post, I failed to mention the huge memory savings achieved by 
> the standalone executable (in addition to the startup time savings).  
> 
> Note that using time at the command line resolves to a shell built-in 
> command. We can get more information from the standard Unix version of time:
> # JVM+UberJar
> > /usr/bin/time -l  java -jar target/hello-world-0.1.0-SNAPSHOT-standalone.jar
> Hello, World!
> Goodbye...
> 1.20 real 2.47 user 0.24 sys
>409  maximum resident set size (MB)
> 100469  page reclaims
>   3569  involuntary context switches
> 
> # Static Executable
> > /usr/bin/time -l  target/hello-world
> Hello, World!
> Goodbye...
> 0.00 real 0.00 user 0.00 sys
>  2  maximum resident set size (MB)
>657  page reclaims
>  4  involuntary context switches
> So we see that the maximum RSS memory requirement was reduced from 409 MB to 
> 2 MB. Yes, an improvement over 200x!  Note also that context switches have 
> been reduced by 900x, and page reclaims by about 200x.
> 
> So, it is the combination of reduced startup time and vastly reduced memory 
> requirements that make standalone executables ideal for short-lived tasks, 
> especially in constrained environments such as serverless/lambda.
> 
> 
> 
>> On Sun, Nov 10, 2019 at 7:54 AM Michiel Borkent  
>> wrote:
>> Might be worth mentioning that lread and I are collecting information about 
>> GraalVM here:
>> 
>> https://github.com/lread/clj-graal-docs
>> 
>> -- 
>> 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/8dbd1a23-61b4-42dc-8815-3d8422956901%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/CAN67zA1USV_sX0bP%3Dg-p0r7%2BqMOvYscWY9aj7yBnYsSeikcskQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/9657973F-BAD3-4EBE-8648-7FA492F19E76%40gmail.com.

Re: [ANN] Oz 1.4.0 - Interactive data visualizations and scientific documents with Vega/Vega-Lite

[Colin Yates]

Looks great! The link to examples (https://vega.github.io/examples) 404s.

Sent from my iPhone

> On 17 Dec 2018, at 20:41, Christopher Small  wrote:
> 
> 
> Greetings!
> 
> I'm happy to announce today the release of Oz 1.4.0.
> 
> https://github.com/metasoarous/oz
> 
> If you're on the Slack #datascience channel, you may have already caught wind 
> of some earlier versions. But in the interest of introducing it more broadly, 
> I'm posting an overview here for those of you who aren't familiar. If you are 
> familiar, you may still wish to scroll down to the bottom as there are some 
> new features available in the latest release.
> 
> 
> Vega & Vega-Lite
> 
> Oz is based on the fantastic Vega & Vega-Lite data visualization JS 
> libraries, and so to really understand what Oz has to offer, it's best to 
> start here. Vega & Vega-Lite are based on the seminal Grammar of Graphics, an 
> approach to data visualization which emphasizes writing declarative 
> descriptions of how properties of data should translate to aesthetic 
> attributes of a visualization. This approach guided the design of the R's 
> popular ggplot2 library, and has since influenced numerous libraries in other 
> languages.
> 
> Vega & Vega-Lite take this vision further in two important ways:
> In Vega & Vega-Lite, data visualizations are described using pure data. This 
> makes it more declarative, and confers all the benefits we know and love 
> about data-driven programming in Clojure. For instance, you can send a chunk 
> of Vega or Vega-Lite data over the wire from one program to another 
> effortlessly (as Oz does), and load it up in another process without having 
> to worry about the security concerns of executing someone else's code. The 
> bottom line is that Vega & Vega-Lite are philosophically and technically 
> compatible with "the Clojure way" (IT'S. JUST. DATA.).
> Vega & Vega-Lite take the Grammar of Graphics one step further by introducing 
> a Grammar of Interaction. You can declaratively describe the addition of 
> controls (dropdowns, checkboxes, etc) and interactive properties of the 
> visualization itself (click, hover, etc), and use the data from these 
> interactions to inform other parts of a visualization. For example, you might 
> highlight a set of points in one part of a visualization, and display summary 
> statistics about that selection in another. This is facilitated in part by a 
> general purpose dataflow language as part of the greater spec.
> Vega itself is highly customizable and flexible, but somewhat verbose and not 
> suitable for day to day visualization tasks. Vega-Lite steps in as a somewhat 
> higher level and more automated flavor which itself compiles down to Vega. I 
> have been using them together for a better part of a year now, and can say 
> without reservation that they are amazing. For years I've longed for a 
> ggplot2 from Clojure, and at long last I've found something that to my 
> surprise has not only matched, but truly surpassed the standard bearer. In 
> short, I'm sold.
> 
> If you want to get a better sense of Vega, and Vega-Lite in particular, I'd 
> recommend this great talk from the creators at the Interactive Data Lab at 
> the University of Washington in Seattle: 
> https://www.youtube.com/watch?v=9uaHRWj04D4
> 
> If you're interested in a (mostly) more philosophical look at Vega & 
> Vega-Lite, and their connections to Clojure philosophy, I did a little talk 
> at a local Clojure meetup which you may find interesting: 
> https://www.youtube.com/watch?v=hXq5Bb40zZY=815s
> 
> 
> Oz
> 
> Oz itself is a very small and focused library, as most of the work falls on 
> Vega & Vega-Lite. It offers the following features:
> A REPL API for for pushing vega and vega-lite data to a browser window over 
> websockets, for REPL-based data science workflows
> Client side vega and vega-lite Reagent components, for more dynamic usage 
> from ClojureScript apps
> A grammar for composing Vega & Vega-Lite together in the context of html as 
> hiccup, for document and dashboard generation
> Plot/document publishing/sharing features via GitHub gists, the IDL's live 
> vega editor, and the new http://ozviz.io
> The last two features in particular are where Oz really brings some 
> interesting value to the table beyond the role of a minimal wrapper. I have 
> found the ability to create and quickly share visualizations and scientific 
> documents from the comfort of my favorite text editor and REPL a godsend. 
> While the first several years of my programming experience were in notebook 
> environments (Mathematica, MATLAB, Sage, etc), I now find the experience of 
> writing and executing code from a web application a burden. Part of my goal 
> with Oz was to create a viable alternative to this workflow, and so far I've 
> been very pleased. The last piece to this now in place (the ability to share 
> hiccup+vega documents via http://ozviz.io), I'm excited to put this work out 
> more broadly 

Re: [ANN] 'Elements of Clojure' is complete

[Colin Yates]

That’s awesome - congratulations!

Sent from my iPhone

> On 2 Dec 2018, at 23:25, Zach Tellman  wrote:
> 
> I'm very happy to announce, only two and a half years after the release of 
> the first chapter, that Elements of Clojure is completely finished.  Further 
> details can be found here: 
> https://groups.google.com/forum/#!topic/elements-of-clojure/UUJjqU1rllU.
> 
> If you've never heard of the book before, please check out its website: 
> http://elementsofclojure.com/
> 
> Zach
> -- 
> 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: mu4e:view show email address after display name in message headers

[Colin Yates]

Come one now, mocking _AND_ being helpful, that’s just not on! What sort of 
internet would this be if we all went around, (shudder) helping (urgh) each 
other ;-).

> This is definitely the wrong list, but given how easy it is to do this, I 
> thought I'd help you out.
> 
> (setq mu4e-view-show-addresses t)
> 
>> Going a step farther, it would be great to use a function with access to 
>> this information ...
> 
> Setting it to a function is harder, but you could advise 
> mu4e~view-construct-contacts-header if you really wanted to. That's not a 
> public function, though, so it might change in future.

-- 
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: mu4e:view show email address after display name in message headers

[Colin Yates]

I guess you could do this in clojure, but you might want to try elisp first ;-).

(I expect the overlap of emacs, clojure and mu users to be significant, so 
maybe this wasn’t the wrong group after all!)

Sent from my iPhone

> On 24 Sep 2018, at 18:26, Jeff Kowalczyk  wrote:
> 
> I would like to configure mu4e:view to display the email address along with 
> the display name in the To: From: Cc: Bcc: etc fields. Is this possible with 
> current mu4e customization options? The information is already present in the 
> buffer: if I hover over the name with the mouse cursor, email addresses are 
> displayed in a tool tip. That's not ideal for hands on keyboard usage, 
> however. 
> 
> Going a step farther, it would be great to use a function with access to this 
> information to selectively show the email address or otherwise decorate the 
> display name. i.e. Having the display name read: "John Smith (ACME)", or 
> "Fred Factor (outside)" would be highly convenient.
> 
> Thanks,
> Jeff
> -- 
> 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: Bazel as Clojure build tool

[Colin Yates]

If we are off topic... I once worked with a really smart guy who decided that 
AOP (using the Spring proxying mechanisms) was a great way of enforcing that 
customers could only see their line items. Only he did this before he went on 
holiday, didn’t tell anybody about it and whilst the filtering logic was unit 
tested there were no integration tests.  Boy, did I (and the other 
programmers), who hadn’t even heard of AOP, have a fun time figuring out why 
the 1500 JDBC rows turned into 6 instances of a LineItem.

Oh, the XML hell :-).

For the record, I think AOP is a massively underused yet incredibly powerful 
tool, but please, for the love of sanity, understand the cognitive load it 
brings with it.

Another anecdote from when I worked for the the Spring Framework days: the AOP 
tooling mechanism in Eclipse was shoe-horned in using guess what? Yep, AOP :-).

Sent from my iPhone

> On 11 Jun 2018, at 21:03, Erik Assum  wrote:
> 
> Totally off topic, but I once worked on a Java project where some of the 
> tests were written in groovy and they were a huge PITA:
> 
> 1) The refactoring tools never found, nor refactored the groovy code
> 2) The compilation errors introduced by 1) never showed up in my IDE
> 3) Having to relate to tests I didn’t know about in a language I don’t care 
> about when I thought I was done was not great for my general mood at the time
> 
> I used to think that sneaking in another language by using it in the 
> test-code was a stellar idea. Now I’m quite certain it isn’t. 
> 
> Erik. 
> -- 
> i farta
> 
>> 11. jun. 2018 kl. 21:55 skrev Rick Mangi :
>> 
>> Next time you have to write unit tests for java, give groovy a try. It has a 
>> lot of features that make this easy, 1 line map construction, overriding of 
>> private methods, super easy to make mocks. There's definitely some weird 
>> syntax, and it's slow, but I'm fine using it for glue or scripting.
>> 
>> 
>>> On Mon, Jun 11, 2018 at 3:48 PM Gregg Reynolds  wrote:
>>> 
>>> 
 On Mon, Jun 11, 2018, 2:44 PM Rick Mangi  wrote:
 Believe it or not, I actually like groovy a lot. I used to use it to write 
 unit tests for java code. It's very easy to learn.
>>> 
>>> 
>>> Will wonders never cease? I had to learn a bit of groovy a while back while 
>>> dealing with Gradle, and came to hate it. Maybe I just have a bad attitude 
>>> - I blame Clojure!
 
> On Mon, Jun 11, 2018 at 3:40 PM Gregg Reynolds  wrote:
> 
> 
>> On Mon, Jun 11, 2018, 2:30 PM  wrote:
> 
> ...
>> We're starting to lean towards gradle 
> 
> 
> You do understand that that means you have to deal with groovy? ;)
> 
> Fwiw I've been working with Bazel a lot lately and I would never go back.
> 
> 
> -- 
> 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 

Re: doall

[Colin Yates]

If you have a sequence of maps then merge is your friend:

(def maps = [{:2 1} {:4 1}])
(apply merge maps)

To create convert a sequence into a map whose key is always 1:
(into {} (map (fn [x] [x 1]) [:2 :4]))  

HTH

> On 16 May 2018, at 18:08, Renata Soares  wrote:
> 
> Hello,
> 
> I have this vec called inviteds [:2 :4]
> 
> and I want to produce something like (hash-map :2 1, :4 1)
> 
> (doall (map #(hash-map % 1) inviteds))
> 
> but returns ({:2 1} {:4 1})
> 
> How can I produce the same result as (hash-map :2 1, :4 1) with doall (or 
> other similar function)?
> 
> 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: [ANN] CIDER 0.17 (Andalucía) is out!

[Colin Yates]

Awesome - well done to all involved!

Sent from my iPhone

> On 7 May 2018, at 21:07, Gregg Reynolds  wrote:
> 
> Looks awesome!
> 
> Any idea when 1.0 will be out?
> 
>> On Mon, May 7, 2018, 2:55 PM Bozhidar Batsov  wrote:
>> Hey everyone!
>> 
>> I'm happy to share with you that CIDER finally made it all the way to 
>> Andalucía! This was a massive release that added a lot of new functionality 
>> and improved much of the existing one. Here are the most important changes 
>> in a nutshell:
>> 
>> - improved ClojureScript support
>> - the ability to display images in the REPL
>> - support for deps.edn "projects"
>> - support for test selectors
>> - much of the core functionality on the Clojure side was been extracted to a 
>> stand-alone library https://github.com/clojure-emacs/orchard (that's step 
>> towards socket REPL support and stronger cross-editor collaboration)
>> 
>> And here are all the details:
>> 
>> ### New features
>> 
>> * [#2248](https://github.com/clojure-emacs/cider/pull/2248): `cider-repl` 
>> can now display recognized images in the REPL buffer.
>> * [#2172](https://github.com/clojure-emacs/cider/pull/2172): Render diffs 
>> for expected / actual test results.
>> * [#2167](https://github.com/clojure-emacs/cider/pull/2167): Add new 
>> defcustom `cider-jdk-src-paths`. Configure it to connect stack trace links 
>> to Java source code.
>> * [#2161](https://github.com/clojure-emacs/cider/issues/2161): Add new 
>> interactive command `cider-eval-defun-to-point` which is bound to `C-c C-v 
>> (C-)z`. It evaluates the current top-level form up to the point.
>> * [#2113](https://github.com/clojure-emacs/cider/issues/2113): Add new 
>> interactive commands `cider-eval-last-sexp-in-context` (bound to `C-c C-v 
>> (C-)c`) and `cider-eval-sexp-at-point-in-context` (bound to `C-c C-v (C-)b`).
>> * Add new interactive command `cider-repl-set-type`.
>> * [#1976](https://github.com/clojure-emacs/cider/issues/1976): Add new 
>> interactive command `cider-connect-clojurescript`.
>> * Add a menu for `cider-browse-ns-mode`.
>> * [#2160](https://github.com/clojure-emacs/cider/issues/2160): Make it 
>> possible to configure the default `*print-level*` and `*print-length*` via 
>> defcustoms (`cider-repl-print-level` and `cider-repl-print-length`).
>> * New interactive command `cider-cheatsheet` allows you to browse the 
>> Clojure Cheatsheet with an Emacs interface.
>> * [#2191](https://github.com/clojure-emacs/cider/issues/2191): Add support 
>> for jacking-in just with the `clojure` command-line tool and `tools.deps`.
>> * Make it possible to start a Nashorn ClojureScript REPL.
>> * [#2235](https://github.com/clojure-emacs/cider/pull/2235): Make the REPL 
>> ignore blank input rather than evaluating.
>> * [#2241](https://github.com/clojure-emacs/cider/pull/2241): Make 
>> `cider-test-ediff` diff eval'ed values.
>> * Add support for shadow-cljs to `cider-jack-in`.
>> * [#2244](https://github.com/clojure-emacs/cider/issues/2244): Display the 
>> REPL type in the modeline.
>> * [#2238](https://github.com/clojure-emacs/cider/pull/2238): Allow 
>> specifying predicates for entries in `cider-jack-in-lein-plugins` and 
>> `cider-jack-in-nrepl-middlewares`.
>> * Add support for test selectors. If test all or all loaded is called with a 
>> prefix ask for filter test selectors in the minibuffer and only run those 
>> tests in the project which match the filters. Add variation of test 
>> namespace which asks for filter selectors the same way and only runs a 
>> subset of the namespace tests.
>> * Add a configuration variable allowing to control whether server output 
>> should be redirected to the REPL (`cider-redirect-server-output-to-repl`).
>> 
>> ### Bugs Fixed
>> 
>> * [#1913](https://github.com/clojure-emacs/cider/issues/1913): Fix 
>> `cider-toggle-buffer-connection` to allow cycling of connection and 
>> restoring all connections in cljc buffers.
>> * [#2148](https://github.com/clojure-emacs/cider/issues/2148): Fix `jump to 
>> definition` working properly when remote `cider-jack-in` and `cider-connect`.
>> * Font-lock failed assertions even in tests that were evaluated 
>> interactively.
>> * [#2102](https://github.com/clojure-emacs/cider/issues/2102): Make 
>> `cider-format-buffer` handle mismatched parens gracefully.
>> 
>> ### Changes
>> 
>> * [#2163](https://github.com/clojure-emacs/cider/issues/2163): Add 
>> `cider-browse-spec-regex`, and changed `cider-browse-spec-all` to use it.
>> * [#2029](https://github.com/clojure-emacs/cider/pull/2154): Make cider-doc 
>> use cider-browse-spec functionality to print the spec part of the doc buffer
>> * [#2151](https://github.com/clojure-emacs/cider/pull/2151): Improve 
>> formatting of spec in `cider-doc` buffer.
>> * Remove support for CLJX.
>> * Fix `cider-eval-region` masking `clojure-refactor-map` in 
>> `cider-repl-mode`.
>> * [#2171](https://github.com/clojure-emacs/cider/issues/2171): Update `See 
>> Also` 

Re: [reagent] ANN: re-frame-10x 0.3.0

[Colin Yates]

This looks awesome - well done to you all!

Sent from my iPhone

> On 24 Mar 2018, at 08:49, Daniel Compton  
> wrote:
> 
> Look, without wanting to hype it too much, re-frame-10x 0.3.0 contains a 
> feature likely to send ecstatic, Kundalini energy surging through every 
> chakra in your body. The windows of your room might blast outwards as you 
> read about it. (In a world where everything is "awesome", "all the time", how 
> do we indicate something is interesting and worth a look?).
> 
> `re-frame-10x` now provides an interactive, explorative UI through which you 
> can browse the form-by-form execution trace of the ClojureScript code in your 
> event handlers.  You can inspect the data produced by every ClojureScript 
> form, while retaining overall context.
> 
> 
> 
> To instrument the code in an event handler, simply replace your current use 
> of `fn` or `defn` with with the alternatives `fn-traced` or `defn-traced`. 
> 
> (ns my.app
>   (:require [day8.re-frame.tracing :refer-macros [fn-traced defn-traced]]))
> 
> (re-frame.core/reg-event-db 
>   :some-event
>   (fn-traced [db event] ;; <--- use `fn-traced` instead of `fn`
>  ; ... code in here to be traced
>  ))
> 
> Instructions for enabling the code tracing are available at 
> https://github.com/Day8/re-frame-debux.
> 
> Limitations/cautions:
> * This code tracing feature should be considered experimental but still 
> useful. 
> * Currently only first level re-frame event handlers should be traced (not 
> the functions they call).
> * Operations like `map` or `for` operating on big sequences will generate too 
> much trace.  That will be a problem. Don't enable tracing for event handlers 
> which have that sort of processing. Not yet. 
> * Our logic for tracing may still have a few bugs. Early days. Please report 
> issues, we'll try and take care of them ASAP.
> 
> Credit:
> 
> This new feature wouldn't have been possible without the great work of Philos 
> Kim on debux. We have forked debux to make it fit with the re-frame tracing 
> system, and extend the code tracing, but a lot of the credit goes to him for 
> creating it in the first place.
> 
> Enjoy!
> 
> Daniel Compton, Mike Thompson, Gregg Ramsey, and the Day8 team.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Reagent-Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to reagent-project+unsubscr...@googlegroups.com.
> To post to this group, send email to reagent-proj...@googlegroups.com.
> Visit this group at https://groups.google.com/group/reagent-project.
> 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: Grateful Appreciation

[Colin Yates]

This.

Sent from my iPhone

> On 31 Oct 2017, at 23:59, Alan Moore  wrote:
> 
> All,
> 
> I want to give a shout out to all the Clojure, ClojureScript, library and 
> tool developers (all y’all really) to say how much I appreciate your efforts. 
> 
> It takes a lot of time out of your busy lives to make this community tick and 
> I hope you know I for one am very grateful. I was hoping to connect w many of 
> you at the Conj but my day job foiled those plans...
> 
> My recent learning detour through VR/AR development has calmed down to a 
> sustainable level so I am now getting back to building a platform using all 
> the goodness you have been perfecting. As I ease back into Clojure I hope to 
> give back in kind.
> 
> That’s it. Take care.
> 
> Alan
> -- 
> 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: [ANN] Instaparse 1.4.8

[Colin Yates]

Thanks Mark, Instaparse is invaluable for us.

Sent from my iPhone

> On 23 Sep 2017, at 06:18, Mark Engelberg  wrote:
> 
> Instaparse 1.4.8 has been updated to support a breaking change that was made 
> in Clojurescript 1.9.854, relating to the reader.  The change has been tested 
> with Clojurescript versions 1.7.28 and up.
> 
> No functionality changes, and this update should not matter for Clojure users.
> Instaparse supports Clojure 1.5.1 and up.
> 
> Thanks to pkpkpk for providing the pull request with the necessary fix:
> https://github.com/Engelberg/instaparse/pull/169
> 
> (Please note that Clojurescript does not currently work with Clojure 
> 1.9-alpha20 or newer: https://dev.clojure.org/jira/browse/CLJS-2352)
> 
> --Mark
> -- 
> 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: Starting Clojure again

[Colin Yates]

The only way of answering that is with numbers, and I understand
https://github.com/hugoduncan/criterium/ is excellent for that.

Personally, if I was asking that question I might also be wondering if
using a mutable data structure might be worth it 
(https://clojure.org/reference/transients).

> ​By the way. I am using a lazy sequence here. Could it be updated with
> using a vector when creating very long strings, or is that not a
> significant performance increase?​
>
> -- 
> Cecil Westerhof

-- 
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: Starting Clojure again

[Colin Yates]

Hi Cecil - welcome back!

This would be perfect to test using the new clojure.spec. I can't give
you any advice on the specifics as I have yet to break into it myself,
but the properties of this function are crying out for generative
testing.

Cecil Westerhof writes:

> I want to start using Clojure again. I made the following simple function
> to generate a PIN:
> (defn create-pin
>   ([] (create-pin 8))
>   ([n]
>(let [chars (map char (range (int \0) (inc (int \9]
> (reduce str (repeatedly n #(rand-nth chars))
>
> So far so good. But I want to improve a little.
>
> I think n should at least be four, but not greater as 16. What is the
> Clojure way to do this?
>
> The next step is that I want to use hexadecimal numbers. So I should use
> (range (int \0) (inc (int \9))) combined with (range (int \A) (inc (int
> \F))).
> How would I do that?
>
> Is there anything I should do differently?
>
> Of-course I make a general function that is then called from create-pin and
> create-pin-hex.
>
> -- 
> Cecil Westerhof

-- 
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: SRSLY? (= (true? identity) (false? identity)) => true

[Colin Yates]

A more revealing name for 'true?' and 'false?' would be
'boolean-which-equals-true?' and 'boolean-which-equals-false?'. Since
the 'identity' function isn't a boolean both functions return 'false',
and '(= false false)' is 'true'.

'(true? (true? identity) (false? identity))' would return, you guessed
it, 'true'.

A more revealing name for the _implementation_ you assumed 'true?' and
'false?' had would be 'truthy?' and 'falsey?'

HTH.

On 2 September 2017 at 04:43, Rostislav Svoboda
 wrote:
> Hi, can anybody explain it please?
>
> $ java -cp clojure-1.8.0.jar clojure.main
> Clojure 1.8.0
> user=> (= (true? identity) (false? identity))
> true
>
> And in 1.9.0-alpha19 it behaves the same.
>
> thx Bost
>
> --
> 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: Sum types in Clojure? Better to represent as tagged records or as variant vectors?

[Colin Yates]

Just a casual bystander here, and this is fascinating to read. The
question screaming out to be answered is what problem are you trying
to solve with your choice of encoding? It seems both James and Timothy
have different requirements, both of which are valid but incompatible
with each other.

Nothing is simple and everything is a decision, and the more explicit
we can make those decisions the better we all becomes as software
engineers..

Anyway, I had better get back to work where I model everything as a
map, just because... ;).

On 23 August 2017 at 06:00, James Reeves  wrote:
> On 23 August 2017 at 05:15, Timothy Baldridge  wrote:
>>
>> Simple: because failing to put it in a map constrains future growth.
>
>
> Sometimes that's what you want. A constrained function is a simple function.
>
> Should (find {:a 1} :a) produce {:key :a, :val 1} instead of [:a 1]? No,
> because it doesn't need to be extensible.
>
> And for that matter, where do we stop? Should:
>
>   {:person/score 89}
>
> Be:
>
>   {:person/score {:val 89}}
>
> Just in case we want to extend it in future?
>
>   {:person/score {:val 89, :max 100}}
>
> Any argument about extensibility around [[k v]] also applies to {k v}.
>
>> But I guess I'd flip it around. Why would I ever want:
>>
>> [:response val]
>>
>> when I could have
>>
>> {:status :response
>>  :result val}
>
>
> Well, going purely by syntax, it's more concise, (IMO) more readable, easier
> to match and destruct, and intrinsically compatible with "into" like
> functions:
>
>   (def latest-values (async/into {} ch))
>
> I don't see how you can say {k v} is somehow fine, but a stream of [k v]
> pairs over time is somehow bad.
>
> --
> James Reeves
> booleanknot.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] CIDER 0.15 (London)

[Colin Yates]

Congratulations and thanks Bozhidar and all involved!
Bozhidar Batsov writes:

> Hey everyone,
>
> Just in the time for EuroClojure 2017, we've released a major update to
> CIDER - the popular Clojure interactive development environment, built on
> top of Emacs and nREPL.
>
> The big news is that CIDER 0.15 ships with a lot of features related to
> clojure.spec and that the debugger is now much more robust than it used to
> be in previous releases!
>
> As usual - there are many other small new features, improvements and
> bugfixes. Go over the release notes for all the details!
>
> Enjoy CIDER 0.15 (responsibly) and have a lot of fun at EuroClojure!
>
> ### New Features
>
> * [#2050](https://github.com/clojure-emacs/cider/pull/2050) Use `view-mode`
> for `cider-grimoire` buffers
> * Make stacktraces and other location references in REPL clickable.
> * Highlight root namespace in REPL stacktraces.
> * Filter stacktrace to just frames from your project.
> * [#1918](https://github.com/clojure-emacs/cider/issues/1918): Add new
> commands `cider-browse-spec` and `cider-browse-spec-all` which start a spec
> browser.
> * [#2015](https://github.com/clojure-emacs/cider/pull/2015): Show symbols
> as special forms *and* macros in `cider-doc`
> * [#2012](https://github.com/clojure-emacs/cider/pull/2012): Support
> special forms in `cider-apropos` and `cider-grimoire-lookup`.
> * [#2007](https://github.com/clojure-emacs/cider/pull/2007): Fontify code
> blocks from `cider-grimoire` if possible.
> * Add support for notifications from the NREPL server.
> * [#1990](https://github.com/clojure-emacs/cider/issues/1990): Add new
> customation variable `cider-save-files-on-cider-refresh` to allow
> auto-saving buffers when `cider-refresh` is called.
> * Add new function `cider-load-all-files`, along with menu bar update.
> * Add new customization variable `cider-special-mode-truncate-lines`.
> * Add an option `cider-inspector-fill-frame` to control whether the cider
> inspector window fills its frame.
> * [#1893](https://github.com/clojure-emacs/cider/issues/1893): Add negative
> prefix argument to `cider-refresh` to inhibit invoking of
> cider-refresh-functions
> * [#1776](https://github.com/clojure-emacs/cider/issues/1776): Add new
> customization variable `cider-test-defining-forms` allowing new test
> defining forms to be recognized.
> * [#1860](https://github.com/clojure-emacs/cider/issues/1860): Add
> `cider-repl-history` to browse the REPL input history and insert elements
> from it into the REPL buffer.
> * Add new customization variable `cider-font-lock-reader-conditionals`
> which toggles syntax highlighting of reader conditional expressions based
> on the buffer connection.
> * Add new face `cider-reader-conditional-face` which is used to mark unused
> reader conditional expressions.
> * [#1544](https://github.com/clojure-emacs/cider/issues/1544): Add a new
> defcustom `nrepl-use-ssh-fallback-for-remote-hosts` to control the behavior
> of `nrepl-connect` (and in turn that of `cider-connect`) for remote hosts.
> * [#1910](https://github.com/clojure-emacs/cider/issues/1910): Add custom
> company-mode completion style to show fuzzy completions from Compliment.
> * Introduce `cider-*-global-options` for customizing options that are not
> related to tasks.
> * [#1731](https://github.com/clojure-emacs/cider/issues/1731): Change code
> in order to use the new `cider.tasks/add-middleware` boot tasks.
> * [#1943](https://github.com/clojure-emacs/cider/pull/1943): Add
> interactive function to flush Compliment caches.
> * [#1726](https://github.com/clojure-emacs/cider/issues/1726): Order keys
> in printed nrepl message objects.
> * [#1832](https://github.com/clojure-emacs/cider/issues/1832): Add new
> customization variable `cider-eldoc-display-context-dependent-info` to
> control showing eldoc info for datomic query input parameters.
> * Make it possible to disable auto-evaluation of changed ns forms via the
> defcustom `cider-auto-track-ns-form-changes`.
> * [#1991](https://github.com/clojure-emacs/cider/issues/1832): Make it
> possible to disable the prompt to open a ClojureScript in a browser on
> connect via `cider-offer-to-open-cljs-app-in-browser`.
> * [#1995](https://github.com/clojure-emacs/cider/pull/1995): Add new
> customization variable `cider-doc-auto-select-buffer` to control cider-doc
> popup buffer auto selection.
> * Ensure that `cider-current-connection` picks the most recently used
> connection in ambiguous cases.
> * Ensure that `cider-switch-to-repl-buffer` picks the most recent repl
> buffer if multiple connections are available.
> * Add new function `cider-project-connections-types`.
>
> ### Changes
>
> * Handle ANSI REPL evaluation created by Puget.
> * Drop support for Emacs 24.3.
> * Don't try to use ssh automatically when connecting to remote hosts and a
> direct connection fails. See `nrepl-use-ssh-fallback-for-remote-hosts`.
> * [#1945](https://github.com/clojure-emacs/cider/pull/1945): Start 

Re: What is juxt really doing?

[Colin Yates]

(defn ->k->node [m k] (into {} (map (juxt k identity) m)) is really useful,
particularly (->k->node m :id)

On Sunday, 16 July 2017,  wrote:

> If I do this:
>
> ((juxt :who :what :when) {:who 1 :when 2} {:who 4 :what 99})
>
> I get:
>
> [1 {:who 4, :what 99} 2]
>
> Why does a map come back instead of a number?
>
> Does anyone use juxt in the real world, or is mostly for examples?
>
>
> --
> 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: Been away a while

[Colin Yates]

Welcome back :-). Our latest application utilises EventSourcing,
domain events, DDD and CQRS and with Clojure's data-first and "it's
all just maps" it is a nice place to be. We are quite fortunate in
that all our consumers are Clojure(Script) so cljc, EDN and transmit
have made it even nicer.

The most overriding impression I have is just how little ceremony this
stack requires. Seeing the data model described using Schema and then
just passing maps around - bliss.

Datomic wasn't an option so the event store is a good old tradition
RDBMS, but the ability to have multiple views, optimised for the UI,
each with their own schema has so many benefits.

Highly recommend you start simple though - it is incredible how far
you can go without pulling in 3rd party libraries until you need them.

On 14 July 2017 at 12:09, Adrian Mowat  wrote:
> Hi Everyone,
>
> I've been out of the Clojure scene for about 18 months due to an ill-advised
> detour into management.  Don't worry!  I've recovered pretty well but I was
> wondering if anyone can suggest what I should be looking at to bring me back
> up to speed.
>
> My current context is that I have a mediums sized rails monolith (~27,000
> LOC excluding tests) that I want to gradually break up into an event
> sourced/CQRS architecture.  I'm evaluating different approaches to writing
> my read and write services and I'm happy to rewrite some code. Spec looks
> like a very exciting way to define services.  Maybe there are some good
> libraries that might help.
>
> Thanks very much
>
> Adrian
>
> --
> 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 In London: HealthUnlocked

[Colin Yates]

Nice write up. I highly recommend healthunlocked as well, it was very
helpful when I did the #c25k

On Thursday, 6 July 2017, Jon Pither  wrote:

> Hi All,
>
> Read about Clojure being used to build a social network to help medical
> patients share experiences and advice: https://juxt.pro/blog/posts/
> clojure-in-health-unlocked.html,
>
> Regards,
>
> Jon.
>
> --
> 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: error in nrepl

[Colin Yates]

Spacemacs is worth a look for a very different emacs experience. Used with
emacs from homebrew and macports (at different times :-)). If you are
heavily invested in your own init.el then maybe not as a full time
replacement but it is worth a look for its evil, which-key and hydra config
alone.

On Saturday, 24 June 2017, Peter Hull  wrote:

> On Friday, 23 June 2017 23:14:55 UTC+1, lawrence...@gmail.com
>  wrote:
>>
>>
>> I'm curious if folks think it is easier to work with Emacs on a Linux
>> machine, or on a Mac?
>>
>> I use Emacs on Mac, Linux and Windows. I disagree that it's more
> difficult to use on the Mac vs Linux. On Windows I get my emacs from cygwin
> so there is a bit of 'mental gear shifting' required between path names and
> line endings.
>
> On the Mac I installed homebrew and installed Emacs that way. Once in
> Emacs, I did exactly the same for all three platforms - added MELPA to the
> packages list and then installed cider (and paredit). I can post more
> details if you want but it sounds like you're an Emacs veteran already!
>
> I've used Atom+protorepl on Windows. It gives you a more modern/better
> integrated system but IMO it doesn't have all the features/reliability of
> Emacs+cider. (this might just be down to my unfamiliarity with Atom)
>
> Hope that helps.
>
>
> --
> 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: slackpocalypse?

[Colin Yates]

I've only been skimming this but "analysis paralysis" comes to mind :-).
What is the harm in establishing a presence in matrix (bagsy the "neo"
handle) and letting people know? As has been said, people will vote with
their feet so if in a months time matrix is a Clojure ghost town then
lesson learned.

Or, if I have missed some pertinent fact then by all means, sigh, tut and
mutter "sheesh, these drive by commenters are annoying" :-).

On Wednesday, 24 May 2017, Herwig Hochleitner 
wrote:

> 2017-05-23 23:04 GMT+02:00 Colin Fleming  >:
>
>> On 24 May 2017 at 00:13, Herwig Hochleitner > > wrote:
>>
>>> I doubt the whole community would want to move anywhere from Slack.
>>>
>>
>> Perhaps this will have to wait until Slack inevitably throws us off, then.
>>
>>
> What I'm saying is, that the whole community isn't in a single place
> anyway. Slack happens to be most popular, right now, but we are spread
> across IRC, gitter / github, slack, mailing lists, discord, stack overflow,
> reddit and probably many more.
>
> IMO trying to move everybody to one thing is an exercise in futility, but
> consuming / producing to / from all those places through a generic protocol
> is a realistic hope, as matrix is proving right now.
>
> It's a far cry from searching for "cursive" from anywhere in Clojurians,
>> though. Searching for channels based on some vague criteria seemed
>> difficult, and searching for Clojure related content across channels is
>> also a pretty bad experience.
>>
>
> Granted, matrix' search facilities are far from optimal, as of now. But
> unlike the alternatives, just about everybody could be (and somebody
> probably is) improving on that.
>
> There has been some talk of making a Clojure-related room directory in an
>> external webpage or something but it's still a kludge. I'm not sure to what
>> extent this would be fixed if we ran our own room server, but then someone
>> has to maintain that.
>>
>
> Same. This is currently being worked on: https://github.com/vector-
> im/riot-web/issues/2454
>
> I'd just like to mention, that in the year or so, that I've been using
> matrix, the stream of improvements has been pretty steady. So while it
> might not currently do everything we need, it's the best hope for bridging
> the community across all the various services that (will continue to) exist.
>
> 2017-05-23 23:31 GMT+02:00 Alan Moore  >:
>
>> I watched the matrix video linked above and it seems there is a Slack
>> bridge that would allow Slack fans to stay put and others to choose their
>> own client or even go back to IRC. What am I missing?
>>
>
> The slack bridge is working fine, but slack has a nagging limitation of
> one bridged room per organization or some "monetization incentive" like
> that.
>
> If slack allowed a full bridge, "slackpocalypse" and its message limit
> would already be a solved problem. Such are the ways of proprietary
> services ...
>
> I too have no skin in this game... I still prefer this mailing list, as is
>> self evident. I suppose I could build a matrix bridge for Google Groups.
>>
>
> related: https://github.com/turt2live/matrix-email-bot
>
> On Tue, May 23, 2017 at 2:22 PM, Andy Fingerhut > > wrote:
>>
>>> I have no skin in this game, but wasn't the move to Slack pretty much a
>>> "vote with your feet" combined with word of mouth advertising?  It seems to
>>> me the same could happen to add another on-line chat tool/system, without
>>> anyone taking a poll/voting on this or any other medium.  We'll know when
>>> it has happened by the rumor mill on Slack, IRC, and/or this email group.
>>>
>>
> Agreed, hence I advertise matrix because I hope more people will see it as
> a way, better than just a different silo.
> If "feet" will still choose a silo, there'll be a matrix bridge, as good
> as silo allows. Hence the risk of choosing wrong is minimized for everybody
> switching to matrix.
>
> --
> 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, 

Re: Rust intro for Clojurists

[Colin Yates]

+1 :-)

On 30 April 2017 at 14:40, Herwig Hochleitner  wrote:
> 2017-04-30 2:24 GMT+02:00 Alan Thompson :
>>
>> https://gist.github.com/oakes/4af1023b6c5162c6f8f0
>
>
> ,,Many people try to compare Rust to Go, but this is flawed. Go is an
> ancient board game that emphasizes strategy.''
>
> This made me actually LOL. Instant classic! Please write more, Mr. Oakes!
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

They look great. My main reservation about Kotlin (and Fantom?) is the
mutability. I fear Clojure has spoiled mutable data structures for me :-).

On Saturday, 8 April 2017, Didier  wrote:

> I have longed for a statically compiled language with type inference with
>>> the simplicity and consistency of Clojure's syntax that also supports
>>> generative testing and works on the JVM but alas, I have not found one.
>>> Frege and PureScript both look interesting but I am unsure of Frege's
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>
> ShenLanguage  is maybe the closest thing from a
> fully typed Clojure on the JVM, though it also suffers from poor interop.
>
> I'd like to suggest Fantom . I wish more people used
> it. It is a functional/oop, actor concurrent, inference typed, static with
> optional dynamic typing language with good interop that runs on top of the
> JVM, CLR and JavaScript. It has a lot of similarities with Clojure, like a
> strong support for data literals such as for maps and lists, looping is
> mostly done through higher order functions, it has a subset of its own
> language as a data declaration format, immutable by default, strong
> concurrency support using actors model, etc. It just needs some love. I
> find at its core, its got a better offering than Kotlin.
>
> On Friday, 7 April 2017 20:34:34 UTC-7, Colin Fleming wrote:
>>
>> I have longed for a statically compiled language with type inference with
>>> the simplicity and consistency of Clojure's syntax that also supports
>>> generative testing and works on the JVM but alas, I have not found one.
>>> Frege and PureScript both look interesting but I am unsure of Frege's
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>> On 8 April 2017 at 14:57, Didier  wrote:
>>
>>>  | I think you missed my point, which is only "Spec is great as we have
>>> the power of Clojure" - sure, just don't forget you have the power of
>>> ANOther language in that language as well.
>>>
>>> Hum, I've probably missed your point sorry, I'm still not following.
>>>
>>>  | no, this will, or at least should, be caught. 10/0 is not an int, and
>>> typed "/' would reject 0 as an ill-typed denominator.
>>>
>>> In most static type systems this will not be caught, because they don't
>>> have a fraction type. So this is actually a function that takes two number
>>> types, and 0 is a number too, so it will type check, but throw an exception
>>> at runtime.
>>>
>>> --
>>> 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 

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

Not sure where you are getting the assertion of equivalence from, it
certainly isn't what I meant. I think you missed my point, which is only
"Spec is great as we have the power of Clojure" - sure, just don't forget
you have the power of ANOther language in that language as well.

I think comparing Clojure Spec against _only_ a static typing machine to be
disingenuous, that's all.

Love, peace and goodwill to all :-).

On Friday, 7 April 2017, Didier <didi...@gmail.com> wrote:

> @Colin Yates
>
> If spec is a DSL to describe invariants and the static typing of other
> languages are too, then it's not true that all static typing DSLs can
> express what the spec DSL can.
>
> If you say, could I build spec in other languages, or can I put asserts in
> the code using the full languages, ya off course you can, but not without
> considerable effort. Similarly, you can add static typing to Clojure, but
> that also comes with considerable effort.
>
> That's why people skip over this. Can I embed a haskell inside Clojure? I
> could. I could embed a Clojure inside Haskell too. But those are not a
> given feature provided to me for free as standard.
>
> So the discussion should center around what features I get for free. With
> spec, you get a very powerful description DSL, more powerful than most
> static typing ones. You get generative testing, parsing, validation,
> asserts and documentation. With static typing systems, you get a often less
> powerful description DSL, compile time type assertions, and documentation.
>
> --
> 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
> <javascript:;>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com <javascript:;>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com <javascript:;>.
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

So I see Clojure Spec as an "internal DSL if you squint" for
describing invariants that are enforced at runtime. Static typing is
also an "internal DSL if you squint" for describing
data-shape-invariants at compile time. With Clojure Spec you have the
entirety of Clojure to describe those invariants, with a static typing
lib you are limited to whatever constructs language provides. So
Clojure Spec is much more open and extensible in that regard.


However, I see a lot of people stopping the discussion there without
accounting for the fact that you _also_ have the "entirety of
language-X to describe those invariants" for any given language. Pre
and Post conditions have been around since the dawn of time and most
languages (I know about) have asserts. If the language has support for
AOP then even better as the description and application of those
invariants don't need to be embedded in the code in question. This
means that any given language, purely from a "can it enforce this?" is
at least as powerful as Clojure Spec.

And Clojure Spec's ability to feed the generative testing machine is
awesome if you can describe your accepted inputs in that way.

So, in terms of "can I express this invariant" in both static and
statically typed languages? Yep, of course.


Clojure Spec and static type systems are both tools for enforcing
invariants. Can Clojure Spec describe invariants that
StaticTypingLanguage-X can't? No, of course not. Is the machinery
around Clojure Spec useful - absolutely.

I have longed for a statically compiled language with type inference
with the simplicity and consistency of Clojure's syntax that also
supports generative testing and works on the JVM but alas, I have not
found one. Frege and PureScript both look interesting but I am unsure
of Frege's longevity and PureScript's performance on the JVM's
Javascript environment.

On 7 April 2017 at 06:07, Didier  wrote:
> It's different, yet related.
>
> Static type systems and clojure.spec both try to prevent bugs. They're tools 
> to help you write correct programs, the same way that a testing framework is. 
> Neither of them will catch all your bugs unfortunately.
>
> Static type systems catches bugs where you would try to do an operation over 
> a type which does not support it. Types are not very precise though, like it 
> will catch 10/"123", but not 10/0, because the type isn't more precise then 
> int. So int/int will be ok, but int/string will be caught at compile time as 
> a bug.
>
> The advantage of static type systems is that what they do catch, they will 
> catch 100% of the time and they generally run pretty quickly.
>
> Clojure.spec catches bugs where you'll try to do something on a value which 
> isn't acceptable, as well as catch bugs where the relationship between the 
> input and output values is wrong. So it can catch 10/0 and 10/"123". If a 
> parameter was true and functionally that means the output should be false, 
> but a bug causes it to be true instead, well it can also catch that.
>
> The disadvantage of clojure.spec is that you cannot be sure it caught 100% of 
> those bugs. It will catch some, but maybe not all. It will also be much 
> slower to run.
>
> Now, clojure.spec has one more trick up its sleeves. It can be used for 
> static analyses on steroids. If you've ever used Find bugs in java, you know 
> a little what I'm talking about. If you use Spectrum, it will try to catch 
> some of those same bugs at compile time, and it could in theory be made to 
> catch 100% of the bugs static type systems catch. Spectrum is new and not 
> fully featured yet, but so is clojure.spec, so this is a possible future 
> which you can have a taste for today. I recommend checking it out: 
> https://github.com/arohner/spectrum
>
> Alright, that's the part about catching bugs. Now there's more to it. Type 
> declarations are normally helpful documentation too, and so is clojure.spec. 
> Spec, once again, can be way more precise in documenting. Similarly, types 
> can help tooling and error messages, so can spec.
>
> Finally, spec also allows some things types don't even cover, such as parsing 
> and validation of non typed data like json. Spec can parse a complex 
> structure into an AST. It can also validate EDN, or json that was 
> unmarshalled into clojure.
>
> As time goes on, I'm sure someone will find other use cases for it too.
>
> Hope this helps.
>
> P.S.: Clojure also has a static type system called core.typed. It is not as 
> widely used though, and has only one developer working on it. It also doesn't 
> compare to the languages you listed, since it is a gradual type system, more 
> inline with typescript, typed racket and hack.
>
> --
> 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 

Re: ANN: Cognitect acquired by Microsoft

[Colin Yates]

Oh, very good. Linux on Windows, MSSQL on Linux and Mac, modern day
politics (on both sides of the pond) and I am not sure what would be
unbelievable nowadays :-).

On Saturday, 1 April 2017, Gregg Reynolds  wrote:

> made ya look!
>
> --
> 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: What makes Clojure Clojure?

[Colin Yates]

cljs = ClojureScript
clr = Clojure on the Common Language Runtime (aka .NET)
cljc = Something that can be interpreted in either clj and cljs (and
clr I assume?) using Clojure conditionals.

For more info on the excellent cljc read
https://clojure.org/guides/reader_conditionals.

If you haven't yet experienced an app with Clojure on the backend,
ClojureScript on the front end and the messaging logic using cljc,
transit and EDN then you should treat yourself and try it :-).

On 5 March 2017 at 16:44, Kevin Baldor  wrote:
> I feel like it should be obvious, but what are the acronyms (initialisms?)
> clj and cljc?
>
> I'm assuming that cljs is ClojureScript.
>
> Sent from my iPhone
>
> On Mar 4, 2017, at 6:46 PM, John Newman  wrote:
>
> Yeah, only Rich can really answer that question, right? :) But for me,
> Clojure is increasingly becoming cljc. When a library advertises
> compatibility in both clj and cljs, it just looks shinier to me. Feels like
> a trend for Clojure libraries in general. And if agents and STM were on
> cljs, I'd probably reach of those tools more often on both platforms.
>
> On that note, if some Clojure concurrency magician would implement a
> lightweight threading library in cljc, which worked on both single-threaded
> cljs (offloading to webworkers where available) and JVM/CLR, allowing for
> STM on cljc... Hell, I'd throw down on a bounty for that. It would really
> bring cljs and clj into closer parity. And it would make cljs even more
> appetizing to js programmers. And it would reunite cljs with one of clj's
> original selling points - how immutability and persistent structures allow
> for unparalleled (lol) concurrency solutions.
>
> I almost got a rudimentary pmap thing working in cljs on core.async with
> webworkers by using a binding-hack macro I found online somewhere. I
> couldn't find great docs out there though on how to implement a lightweight
> threading library.
>
> On Sat, Mar 4, 2017 at 6:51 PM Didier  wrote:
>>
>> The Specter post about if it should be made into core or not got me
>> wondering what makes Clojure Clojure.
>>
>> I'm trying to wrap my head around what is the most minimal set of things
>> that uniquely make up Clojure.
>>
>> Right now, in that set I've got:
>>
>> The Clojure syntax and its semantics
>> The Clojure special forms and their semantics
>> The Clojure core libraries and their semantics
>>
>> So if I implemented a compiler that worked with the above set, it would be
>> a valid Clojure compiler.
>>
>> Now, ClojureScript appears to me like it is not Clojure, but a dialect of
>> it. I say that because it breaks some of the syntax semantics of Clojure,
>> like not allowing macros in the same namespace as functions. It also breaks
>> some of the core semantics, like def creating standard JS vars and not
>> Clojure Vars. In this respect, a language like hy-lang is also a Clojure
>> dialect, granted it shares even less of the Clojure set.
>>
>> Is ClojureCLR a dialect of Clojure, or is it a true Clojure
>> implementation?
>>
>> One last thing that is interesting about Clojure versus other languages is
>> that it does not provide standard IO. These two things make it so that it is
>> kind of dependent on its host to complete its offering as a programming
>> language, which means any Clojure compiler will need to provide a mechanism
>> for IO. Those would always differ from Clojures to Clojures, so I don't
>> think that's part of what makes Clojure Clojure.
>>
>> What are others thoughts on this?
>>
>> P.S.: There's no point to this thread, its mostly curiosity.
>>
>> --
>> 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 

Re: New to Clojure - productivity and debugging with Emacs

[Colin Yates]

The big barrier for me with emacs was discovering and then remembering
all of the various finger-bending chords to do things. Spacemacs uses
hydra so all the key mappings are grouped in a very logical way. Have
a read of http://spacemacs.org, particularly the horizontal image
slide show.

But yeah, spacemacs was a breath of fresh air - and if you like vim it
gets even better :-).

On 11 January 2017 at 20:09, ahawk <aho...@gmail.com> wrote:
> Thanks a lot for the very elaborate reply.
>
> I should probably buy SICP.
>
> With regards to discovery, I will have a closer look at clojure.spec. It
> looks interesting. I've previously (perhaps wrongfully) discarded Prismatic
> Schema, thinking something like "don't you really just want static types?"
> (which is apparently not the case according to this background info:
> http://plumatic.github.io/schema-for-clojurescript-data-shape-declaration-and-validation/).
> Anyway, some of these libraries seem like they try to mix Clojure with ideas
> derived from other languages. I would like to learn to develop Clojure
> productively in an idiomatic way.
>
> With regards to developer tools, spacemacs seems interesting. What do you
> mean by keymap discoverability?
>
> Den søndag den 8. januar 2017 kl. 10.52.55 UTC+1 skrev Colin Yates:
>>
>> Hi ahawk and welcome to Clojure!
>>
>> Your question seems to cover multiple domains:
>>  - navigating/discovery in non-statically typed languages, specifically
>> Clojure
>>  - developing in Clojure
>>  - developer tools (e.g. IDE for Clojure)
>>
>> (I can feel a stream of consciousness/ramble coming so so this might
>> take a while; settle in ;-)).
>>
>> [discovery]
>> Clojure apps tend to prefer data over functions, so the data itself
>> becomes part of the API. The notion of 'it's just a map' is very
>> prevalent. How is that addressed? Well, it typically comes down to:
>>  - ad-hoc documentation of the shapes
>>  - pre/post conditions (not very scalable but works OOTB)
>>  - Plumatic (previously known as Prismatic) Schema became the de-facto
>> standard for describing and asserting conformity to a given shape at
>> runtime
>>  - core.typed was an attempt to apply static typing that could be
>> validated as a compilation step. I am not sure it was as wildly
>> successful in terms of implementation as it was as an intriguing
>> possibility?
>>  - core.spec - a new, blessed and very exciting part of Clojure v1.9
>> which promises to bring the power of Clojure to creating 'specs' that
>> your data but follow. It also has the very neat trick of producing
>> generators (for property based testing) from those specs. I haven't
>> used this in anger, but like all the best things Clojure it promises
>> to bring simplicity to a previously complex and convoluted space. Very
>> interested to see how this plays out.
>>
>> None of that addressed your question of "how do I know what to expect"
>> _unless_ the tool author has documented it. I would expect more and
>> more libraries to ship with Clojure specs over time (although there is
>> some controversy over this).
>>
>> The other common thing to expect is lots of data-driven unit tests
>> which can also document your code. Clojure's preference of pure forms
>> makes this much more feasible.
>>
>> You mention looking at the source, yeah, that is another assumed tool
>> developers will employ. The nice thing is that Clojure, being such a
>> 'small' language has quite a low barrier to entry so reading other's
>> source code becomes quite efficient quite quickly.
>>
>> Unfortunately, the lack of a blessed code style and the rush of OO
>> developers moving to Clojure _without_ reading SICP (yeah, I'm talking
>> about me) means some of the code might make your eyes bleed.
>>
>> [developing in Clojure]
>> Briefly:
>>  - data over forms
>>  - no global state/pure forms
>>  - REPL, REPL and more REPL
>>
>> Rich Hickey did a great talk about 'systems' development rather than
>> 'function' (that isn't right but I can't remember the exact phrasing)
>> development where in LISP you build a living system made up of lots of
>> living components. In other languages you build chunks of code.
>>
>> This mindset, coupled with the desire for 'pure' forms makes the REPL
>> an indispensable and incredibly powerful tool.
>>
>> In other languages (e.g. Java) you don't have a living system, you
>> have a bunch of small chunks of code and you frequently start/stop
>> that system. In Clojure you start the REPL once and then build the
>&g

Re: New to Clojure - productivity and debugging with Emacs

[Colin Yates]

Hi ahawk and welcome to Clojure!

Your question seems to cover multiple domains:
 - navigating/discovery in non-statically typed languages, specifically Clojure
 - developing in Clojure
 - developer tools (e.g. IDE for Clojure)

(I can feel a stream of consciousness/ramble coming so so this might
take a while; settle in ;-)).

[discovery]
Clojure apps tend to prefer data over functions, so the data itself
becomes part of the API. The notion of 'it's just a map' is very
prevalent. How is that addressed? Well, it typically comes down to:
 - ad-hoc documentation of the shapes
 - pre/post conditions (not very scalable but works OOTB)
 - Plumatic (previously known as Prismatic) Schema became the de-facto
standard for describing and asserting conformity to a given shape at
runtime
 - core.typed was an attempt to apply static typing that could be
validated as a compilation step. I am not sure it was as wildly
successful in terms of implementation as it was as an intriguing
possibility?
 - core.spec - a new, blessed and very exciting part of Clojure v1.9
which promises to bring the power of Clojure to creating 'specs' that
your data but follow. It also has the very neat trick of producing
generators (for property based testing) from those specs. I haven't
used this in anger, but like all the best things Clojure it promises
to bring simplicity to a previously complex and convoluted space. Very
interested to see how this plays out.

None of that addressed your question of "how do I know what to expect"
_unless_ the tool author has documented it. I would expect more and
more libraries to ship with Clojure specs over time (although there is
some controversy over this).

The other common thing to expect is lots of data-driven unit tests
which can also document your code. Clojure's preference of pure forms
makes this much more feasible.

You mention looking at the source, yeah, that is another assumed tool
developers will employ. The nice thing is that Clojure, being such a
'small' language has quite a low barrier to entry so reading other's
source code becomes quite efficient quite quickly.

Unfortunately, the lack of a blessed code style and the rush of OO
developers moving to Clojure _without_ reading SICP (yeah, I'm talking
about me) means some of the code might make your eyes bleed.

[developing in Clojure]
Briefly:
 - data over forms
 - no global state/pure forms
 - REPL, REPL and more REPL

Rich Hickey did a great talk about 'systems' development rather than
'function' (that isn't right but I can't remember the exact phrasing)
development where in LISP you build a living system made up of lots of
living components. In other languages you build chunks of code.

This mindset, coupled with the desire for 'pure' forms makes the REPL
an indispensable and incredibly powerful tool.

In other languages (e.g. Java) you don't have a living system, you
have a bunch of small chunks of code and you frequently start/stop
that system. In Clojure you start the REPL once and then build the
system over time. That won't make sense until it does :-).

Yeah, there is much more I could write about this but it is long enough

[developer tools]
If you are an emacs developer then CIDER and clj-refactor is an
incredibly powerful toolset. If you haven't already looked then
checkout spacemacs as well, just for the keymap discoverability if
nothing else.

Cursive an IntelliJ plugin is also fantastic and brings a lot of the
power of IntelliJ to Clojure. Code navigation, refactoring etc. Colin
(Flemming) has done a _great_ job.

I, like a bunch of people I expect do both. I use space macs 90% of
the time and then occasionally throw the project into Cursive to find
unused code and other polishings.

You could live in exclusively emacs or Cursive perfectly happily, but
both brings to spoils I think. There are a bunch of other IDEish
tools; NightCode, CounterClockwise etc. I lost track since finding
spacemacs ;-).

Both tools will let you debug although to be honest, I haven't needed
to use a debugger in the 5+ years I have been contorting Clojure. In a
large part, because of the succinctness and small footprint of the
language, 'pure' forms and common idioms (sequences, sequences and
more sequences) you end up with a very small toolset which is
amazingly powerful.

Other essential tools are either leiningen or boot. Leiningen is the
'old guard' whereas boot is the newer one. Both are actively
maintained and developed but have different mindsets. Leiningen is
similar to maven; 'declare your project' and plugins use that
declaration as a source of truth. Boot is more like gradle, it is just
another Clojure program. Boot looks like the more flexible
but if you don't need that flexibility then leiningen will get you
started quicker 

[Summary]
If you are still reading this then congrats :-).

If you are new to LISP then SICP is a must. To get used to Clojure:
 - go and watch almost all of Rich Hickey's videos
 - get used to REPL development
 - get 

Re: [ANN] 2016 State of Clojure Community Survey

[Colin Yates]

Oh the joys of a lack of a ubiquitous language :-). I was only
surprised it didn't start at 0 ;-).

On 13 December 2016 at 15:46, Jose Figueroa Martinez  wrote:
> Me too :-|
>
>
> El martes, 13 de diciembre de 2016, 2:44:08 (UTC-6), Patrick Kristiansen
> escribió:
>>
>> On Tuesday, December 13, 2016 at 2:00:10 AM UTC+1, Mike Rodriguez wrote:
>>>
>>> Uh oh. I should have asked. I ranked my priorities in the exact opposite
>>> order since I thought 1 was lowest.
>>
>>
>> I did 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.

-- 
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] An exploration of Hash Array Mapped Tries

[Colin Yates]

The "Link" doesn't seem to be working for me (it isn't actually a
link). Is this some sort of gateway tested - if you aren't clever
enough to figure it out you don't deserve to get in? ;-).

On 6 December 2016 at 21:16, Ambrose Bonnaire-Sergeant
 wrote:
> Hi,
>
> I've been having a ton of fun this semester learning about
> Hash Array Mapped Tries (like PersistentHashMap).
>
> Link
>
> I have written a visual tutorial for HAMT's, as well
> as a reference implementation in Clojure that supports
> trie visualisations with Rhizome.
>
> There's also a little prototype+writeup of an idea I had about
> generating defrecords at runtime based on the frequency
> of certain keysets at runtime.
>
> Enjoy!
>
> Ambrose
>
> --
> 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: Returning multiple values

[Colin Yates]

I bet you it doesn't :-). It may be rendered like that but I doubt
very much the server is returning the form ({..} {..} {..}) as that is
interpreted as a function call. It will almost certainly be returning
a sequence of the form '({..} {..} {..}) which isn't a functional call
but is a sequence of maps.

Let's break it down a bit.

The arguments to map are (map fn sequence) so it returns the result of
executing fn with each element in the sequence. Rather than (map (->
class1 :people) [:name :age])) you want something like (map [:name
:age] (-> class1 :people)). That still isn't going to work though as
it will execute [:name :age] against each element in the value of the
key :people in the class1 map.

(remember that keywords (e.g. :people) are functions that look
themselves up in the argument to the keyword which is assumed to be
associative. So (:people class1) will be replaced with the value of
calling :people on class1 which will retrieve the value of :people in
class1.

Getting closer though. You want to extract the :name and :age from
each map in (:people class1). A perfect function for that is juxt
which returns a vector filled with the results of calling each
function passed to juxt. So (juxt :name :age) returns a function,
which when called with a parameter will return a vector of the result
of calling :name against the parameter and :age against the parameter.
Remember that keywords are functions. A longer, but maybe more
transparent way would be (map (fn [m] [(:name m) (:age m)]) (:people
class1)).

Finally, map returns a sequence but you want it to be a vector (why?)
so you can use either (into [] sequence), (vector sequence) or mapv
which is identical to map except it returns a sequence.

So, all together:

(
-- returns a sequence by applying
mapv
-- a function which returns [(:name m) (:age m)] which is applied to
(juxt :name :age)
-- each item in the sequence that is the value of :people in the map class1
(:people class1)
)

HTH.

On 30 November 2016 at 11:54, 'Rickesh Bedia' via Clojure
<clojure@googlegroups.com> wrote:
> Because the information is coming from a table I don't know if I can change
> it to look like that.
>
> The information from the table looks like {:people ({:name "John" :age 25}
> {:name "Harry" :age 23} {:name "Peter" :age 24})}
>
> I was wondering if you could apply (into [] (map (-> class1 :people) [:name
> :age])) to each of the {:name "Peter" :age "24"}, {:name "John" :age "25"},
> {:name "Harry" :age "23"} and then put that into a vector so the final
> vector is in the form
> [["John" "25"]
>  ["Harry" "23"]
>  ["Peter" "24"]]
>
> On Wednesday, 30 November 2016 10:37:04 UTC, Colin Yates wrote:
>>
>> (def class1 {:people '({:name "John" :age "25"} {:name "Harry" :age
>> "23"} {:name "Peter" :age "24"})}) or (def class1 {:people [{:name
>> "John" :age "25"} {:name "Harry" :age "23"} {:name "Peter" :age
>> "24"}]}) is probably what you want.
>>
>> (mapv (juxt :name :age) (:people class1)) on either of those will give
>> you your result.
>>
>> On 30 November 2016 at 10:34, Colin Yates <colin...@gmail.com> wrote:
>> > Ah, I just realised people is _not_ a sequence of maps but the result
>> > of calling '{:name "John" :age "25"}' passing in the other two maps as
>> > arguments. You probably want a literal literal '({:name "John" :age
>> > "25"}.) or a vector [{:name "John" :age "25"}...]
>> >
>> > On 30 November 2016 at 10:29, Colin Yates <colin...@gmail.com> wrote:
>> >> (mapv (juxt :name :age) (:people class1)) should work
>> >>
>> >> On 30 November 2016 at 10:27, 'Rickesh Bedia' via Clojure
>> >> <clo...@googlegroups.com> wrote:
>> >>> I have a definition:
>> >>> (def class1 {:people ({:name "John" :age "25"}
>> >>>   {:name "Harry" :age "23"}
>> >>>   {:name "Peter" :age "24"})})
>> >>>
>> >>> The result I want is a vector that looks like
>> >>> [["John" "25"]
>> >>>  ["Harry" "23"]
>> >>>  ["Peter" "24"]]
>> >>>
>> >>> If I call (map (-> class1 :people) [:name :age])
>> >>> then I get the result ("Peter" "24&quo

Re: Returning multiple values

[Colin Yates]

(def class1 {:people '({:name "John" :age "25"} {:name "Harry" :age
"23"} {:name "Peter" :age "24"})}) or (def class1 {:people [{:name
"John" :age "25"} {:name "Harry" :age "23"} {:name "Peter" :age
"24"}]}) is probably what you want.

(mapv (juxt :name :age) (:people class1)) on either of those will give
you your result.

On 30 November 2016 at 10:34, Colin Yates <colin.ya...@gmail.com> wrote:
> Ah, I just realised people is _not_ a sequence of maps but the result
> of calling '{:name "John" :age "25"}' passing in the other two maps as
> arguments. You probably want a literal literal '({:name "John" :age
> "25"}.) or a vector [{:name "John" :age "25"}...]
>
> On 30 November 2016 at 10:29, Colin Yates <colin.ya...@gmail.com> wrote:
>> (mapv (juxt :name :age) (:people class1)) should work
>>
>> On 30 November 2016 at 10:27, 'Rickesh Bedia' via Clojure
>> <clojure@googlegroups.com> wrote:
>>> I have a definition:
>>> (def class1 {:people ({:name "John" :age "25"}
>>>   {:name "Harry" :age "23"}
>>>   {:name "Peter" :age "24"})})
>>>
>>> The result I want is a vector that looks like
>>> [["John" "25"]
>>>  ["Harry" "23"]
>>>  ["Peter" "24"]]
>>>
>>> If I call (map (-> class1 :people) [:name :age])
>>> then I get the result ("Peter" "24"). Why do I only get the values from the
>>> last hashmap and not the others?
>>>
>>> If I then call (into [] (map (-> class1 :people) [:name :age]))
>>> then I get the result ["Peter" "24"]
>>>
>>> What I need to do is run the 'into' function again on the other two hashmaps
>>> and then put the 3 results into a vector but I don't know how to do this.
>>>
>>> Any help would be much appreciated
>>>
>>> --
>>> 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: Returning multiple values

[Colin Yates]

Ah, I just realised people is _not_ a sequence of maps but the result
of calling '{:name "John" :age "25"}' passing in the other two maps as
arguments. You probably want a literal literal '({:name "John" :age
"25"}.) or a vector [{:name "John" :age "25"}...]

On 30 November 2016 at 10:29, Colin Yates <colin.ya...@gmail.com> wrote:
> (mapv (juxt :name :age) (:people class1)) should work
>
> On 30 November 2016 at 10:27, 'Rickesh Bedia' via Clojure
> <clojure@googlegroups.com> wrote:
>> I have a definition:
>> (def class1 {:people ({:name "John" :age "25"}
>>   {:name "Harry" :age "23"}
>>   {:name "Peter" :age "24"})})
>>
>> The result I want is a vector that looks like
>> [["John" "25"]
>>  ["Harry" "23"]
>>  ["Peter" "24"]]
>>
>> If I call (map (-> class1 :people) [:name :age])
>> then I get the result ("Peter" "24"). Why do I only get the values from the
>> last hashmap and not the others?
>>
>> If I then call (into [] (map (-> class1 :people) [:name :age]))
>> then I get the result ["Peter" "24"]
>>
>> What I need to do is run the 'into' function again on the other two hashmaps
>> and then put the 3 results into a vector but I don't know how to do this.
>>
>> Any help would be much appreciated
>>
>> --
>> 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: Returning multiple values

[Colin Yates]

(mapv (juxt :name :age) (:people class1)) should work

On 30 November 2016 at 10:27, 'Rickesh Bedia' via Clojure
 wrote:
> I have a definition:
> (def class1 {:people ({:name "John" :age "25"}
>   {:name "Harry" :age "23"}
>   {:name "Peter" :age "24"})})
>
> The result I want is a vector that looks like
> [["John" "25"]
>  ["Harry" "23"]
>  ["Peter" "24"]]
>
> If I call (map (-> class1 :people) [:name :age])
> then I get the result ("Peter" "24"). Why do I only get the values from the
> last hashmap and not the others?
>
> If I then call (into [] (map (-> class1 :people) [:name :age]))
> then I get the result ["Peter" "24"]
>
> What I need to do is run the 'into' function again on the other two hashmaps
> and then put the 3 results into a vector but I don't know how to do this.
>
> Any help would be much appreciated
>
> --
> 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: [ANN] Clojure Programming Cookbook

[Colin Yates]

Congrats - it is amazing how much effort this takes :-).

On Tuesday, 15 November 2016, Nicolas Modrzyk  wrote:

> Hi Clojure people,
>
> So after one year and 23 days, (that would be 388 days) the IT book I was
> working on with Makoto (merci!) finally got published!
>
> It has been a long battle with many late nights to get it out, tough
> deadlines and never-ending reviews, but thanks to some skilled people at
> Packt, thank you Sachin, Pranav (and not forgetting Nikhil, you got it all
> started!) (http://packtpub.com/
> )
> it is finally there in all its 635 pages glory ;)
>
> (PACK) https://www.packtpub.com/application-development/
> clojure-programming-cookbook
>
> (AMAZON) http://a.co/3c9ckbp
>
> The book while also presenting Clojure language centric topics, wants to
> be slightly more focused around using Clojure at work and is bringing tons
> and tons of working examples for every day usage. Along its (long!) 10
> chapters, the book goes through many various topics but tries to keep each
> topic easy to follow, with fun and useful recipes for great projects and
> various creative ideas.
>
> The book may sometimes be too simple to many of the members of this
> mailing list, but we hope the book contribute to grow the Clojure community
> by sharing useful (and battled) Clojure code and stories.
>
> This is out now ! Enjoy!
> Nicolas & Makoto, all the way from Japan
>
> --
> 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: Controlling how maps/records/atoms etc. are printed out

[Colin Yates]

Thanks Timothy

On Saturday, 12 November 2016, Timothy Baldridge <tbaldri...@gmail.com>
wrote:

> clojure.core/print-method is a multi method that handles the printing of
> objects. You can override or implement the print method by:
>
> (defmethod print-method my.class.Foo
>   [^my.class.Foo instance ^Writer w]
>   (.write w ...))
>
> I do that to provide custom printing for deftypes, but you can easily
> override how records are printed as well.
>
> Timothy
>
> On Sat, Nov 12, 2016 at 2:35 AM, Colin Yates <colin.ya...@gmail.com
> <javascript:_e(%7B%7D,'cvml','colin.ya...@gmail.com');>> wrote:
>
>> Hi all,
>>
>> I cache quite a bit of stuff on the server, so when I return or print
>> out the 'system' I get the unhelpful recursive stack trace of Java
>> running out of heap.
>>
>> Is there some protocol I can implement on large data structures such
>> that whenever they are serialised they just dump some of their
>> contents?
>>
>> These objects will only ever be printed out either at the REPL,
>> (println) or clojure.tools.logging/log etc. I never expect them to be
>> serialised and then later deserialised from the serialised form.
>>
>> Any suggestions?
>>
>> Thanks all,
>>
>> Colin
>>
>> --
>> 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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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
>> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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
> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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.

Controlling how maps/records/atoms etc. are printed out

[Colin Yates]

Hi all,

I cache quite a bit of stuff on the server, so when I return or print
out the 'system' I get the unhelpful recursive stack trace of Java
running out of heap.

Is there some protocol I can implement on large data structures such
that whenever they are serialised they just dump some of their
contents?

These objects will only ever be printed out either at the REPL,
(println) or clojure.tools.logging/log etc. I never expect them to be
serialised and then later deserialised from the serialised form.

Any suggestions?

Thanks all,

Colin

-- 
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: Using a function in another function

[Colin Yates]

Your inner (add1 [x]) is calling add1 with a vector containing x, you
want (add1 x):

(defn add2 [x]
(add1 (add1 x))

HTH

On 10 November 2016 at 14:51, 'Rickesh Bedia' via Clojure
 wrote:
> I have this function:
> (defn add1 [x]
> (+ 1 x))
> which is just a very simple function that adds 1.
>
> I now want to create a new function called add2 that uses add1 twice.
> I have tried
> (defn add2 [x]
> (add1 (add1 [x]))
> but this doesn't work. (Can someone explain why this doesn't work. I think
> its maybe I am calling the function incorrectly)
>
> I have ideas about using recur because I eventually want to create a
> function addn where the function takes arguments n and x and calls add1 n
> times to x
>
> --
> 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: Voting

[Colin Yates]

And I thought we had it bad with the whole Brexit saga over here :-).

On 9 November 2016 at 12:23, Mikera  wrote:
> Given recent events, I advise caution when it comes to relying on votes to
> make important decisions.
>
> On Tuesday, 8 November 2016 23:33:43 UTC+8, Alex Miller wrote:
>>
>> In the spirit of the US election today, I thought I would mention voting
>> on Clojure tickets. Clojure manages bugs and enhancement requests in JIRA.
>> Anyone can create a JIRA account and vote on open tickets in the system (no
>> contributor agreement is required to vote).
>>
>> In the core team, we look at votes on tickets to be aware of what the
>> community cares about and as one input to the order in which tickets are
>> considered. However, the most-voted tickets in the system have fewer than 30
>> votes and I suspect that there are many thousands of people with opinions
>> about which of these tickets are important.
>>
>> If you'd like to see the lists of the highest voted tickets in the system,
>> you can do so in these reports:
>> - Highest voted defects
>> - Highest voted enhancements
>>
>> Andy Fingerhut also has a weighted voting report that updates about once a
>> week. This show a different perspective - I'm not sure which is more useful
>> but I look at both.
>>
>> If you'd like to learn more about the process:
>> - Overview of contribution links
>> - JIRA workflow
>> - A blog I wrote describing the process
>>
>> A few examples of highly voted issues that have been included in 1.9 so
>> far:
>> - CLJ-1224 Records do not cache hash like normal maps (21 votes)
>> - CLJ-1298 Add more type predicate fns to core (18 votes)
>> - CLJ-1744 Unused destructured local not cleared, causes memory leak (17
>> votes)
>> - CLJ-1242 = on sorted collections with different key types incorrectly
>> throws (7 votes)
>> - CLJ-401Add seqable? predicate (7 votes)
>>
>> Alex
>>
>>
>>
> --
> 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: any? in clojure 1.9.0 alpha

[Colin Yates]

> Back at ya. I respect your opinion - I just see things differently.
I think that is the perfect way to end this conversation :-).

On 8 November 2016 at 16:17, Alex Miller <a...@puredanger.com> wrote:
>
> On Tuesday, November 8, 2016 at 9:34:53 AM UTC-6, Colin Yates wrote:
>>
>> you mean Java with the 'billion dollar mistake' known as null?
>
>
> Yep, that one, which millions of programmers use every day.
>
>>
>> The Java which has just completed changed its Date and Time API _for the
>> better_?
>
>
> They did not "completely change" the API. They embarked on a lengthy (other
> process issues involved of course) process that created a new *additive* API
> with carefully considered integrations with the prior API(s). Every aspect
> of the "old" API continues to work.
>
>>
>> Or maybe you are referring to JavaScript with its insane
>> scoping rules? Maybe Ruby with its ridiculously wide scoping rules?
>> And I am pretty sure Java has and will continue to use the deprecated
>> tag more than once.
>
>
> Yes, but they also continue to NOT remove the deprecated parts, avoiding
> breaking existing code. We have no plans to removed the deprecated parts of
> Clojure either.
>
>>
>> NEW languages are exciting precisely (or at least mainly) because they
>> offer the opportunity to do things better, to evolve and learn from
>> the past
>
>
> Absolutely. But Clojure is no longer a new language and has 10ks of existing
> users. There is only a narrow period of time where a language has the
> latitude to change in significant breaking ways and I think we are past that
> time for Clojure.
>
>>
>> - legacy debt is by definition only legacy. I am not sure you
>> are really suggesting that continuing to pay for a mistake _for ever_
>> is better than paying the cost of change once?
>
>
> I think you are under-estimating the costs of change and over-estimating the
> value of seeking perfection.
>
> I don't even believe that there is some "right" answer to questions of
> language. Choices of language are inherently dependent on context (of the
> language, of the designer, of the users, of history, of meaning) and there
> are too many constraints for any set of words to perfectly convey a large
> set of concepts. So, there will inevitably be function names that do not
> seem right to you, or do not seem in sync with all other semantically
> similar words in the other set of functions. I don't agree with every choice
> Rich has made and we have wide-ranging disagreements about things like this
> constantly. That's ok, I still like Clojure and in hindsight, the majority
> of his choices are either better or unimportantly different.
>
>>
>> Taking your argument literally we are only going to continue to see
>> languages emerge to excitement only to then crumble under previous
>> design decisions.
>
>
> To some degree, yes. Personally, I still find Clojure to be the most fun,
> productive, and useful language I have ever used. I do not have the hubris
> to believe that it is perfect. But I'll take fun and productive over perfect
> every day.
>
>>
>> People make mistakes, new realities emerge, why on
>> earth would you want to prevent the opportunity to upgrade?
>
>
> Because there is tremendous utility in stability.
>
>>
>> Unless I am mistaken any? was only introduced in the Clojure 9 alpha
>> so comparing this to the stability of the Java APIs (which are in some
>> parts horrendous to work with, purely because of legacy) is a bit of a
>> straw man.
>
>
> I'm talking in broader terms than just about any?. But re any?, see the
> language comments above. I think "any?" is exactly the best word for this
> case re spec (note that it's the same word used by both Schema and Herbert).
> It's not the best word in relation to other existing functions. I do not see
> this as the end of the world.
>
>>
>> I entirely agree with your upgraded definition of 'good', I am not
>> sure I buy the size of the constraint you mention (changing an API
>> introduced whilst in alpha).
>>
>> Don't get me wrong, I am no Rich Hickey or Brian Goetz, and I highly
>> rate Clojure and the design decisions behind it. Watching a number of
>> Rich Hickey videos was like a breath of fresh air with a bunch of
>> "yes, that is the nagging feeling I haven't managed to articulate"
>> light bulb moments, but everybody makes mistakes.
>>
>> I can see this getting a bit out of hand, I wrote some inflammatory
>> stuff which you are responding to in absolute terms. I am pretty sure

Re: any? in clojure 1.9.0 alpha

[Colin Yates]

you mean Java with the 'billion dollar mistake' known as null? The
Java which has just completed changed its Date and Time API _for the
better_? Or maybe you are referring to JavaScript with its insane
scoping rules? Maybe Ruby with its ridiculously wide scoping rules?
And I am pretty sure Java has and will continue to use the deprecated
tag more than once.

NEW languages are exciting precisely (or at least mainly) because they
offer the opportunity to do things better, to evolve and learn from
the past - legacy debt is by definition only legacy. I am not sure you
are really suggesting that continuing to pay for a mistake _for ever_
is better than paying the cost of change once?

Taking your argument literally we are only going to continue to see
languages emerge to excitement only to then crumble under previous
design decisions. People make mistakes, new realities emerge, why on
earth would you want to prevent the opportunity to upgrade?

Unless I am mistaken any? was only introduced in the Clojure 9 alpha
so comparing this to the stability of the Java APIs (which are in some
parts horrendous to work with, purely because of legacy) is a bit of a
straw man.

I entirely agree with your upgraded definition of 'good', I am not
sure I buy the size of the constraint you mention (changing an API
introduced whilst in alpha).

Don't get me wrong, I am no Rich Hickey or Brian Goetz, and I highly
rate Clojure and the design decisions behind it. Watching a number of
Rich Hickey videos was like a breath of fresh air with a bunch of
"yes, that is the nagging feeling I haven't managed to articulate"
light bulb moments, but everybody makes mistakes.

I can see this getting a bit out of hand, I wrote some inflammatory
stuff which you are responding to in absolute terms. I am pretty sure
that were this discussion next to the magical water cooler we would be
much more on the same page as I can't believe you mean what you typed
:-).

Peace.

On 8 November 2016 at 14:39, Alex Miller <a...@puredanger.com> wrote:
> On Tuesday, November 8, 2016 at 2:28:54 AM UTC-6, Colin Yates wrote:
>>
>> The ship has indeed sailed. However, it is exactly these moments when
>> software starts to degrade - there are many examples of crufty
>> software crippled by legacy decisions.
>
>
> I completely disagree with this idea, particularly in the realm of
> programming languages. Java did not become one of the most popular languages
> ever by redoing and breaking things every release. The stability of the Java
> APIs is an essential ingredient in their success. Clojure leans far, far in
> this direction. I'll refer you to Brian Goetz's Conj keynote a couple years
> ago:
>
> https://www.youtube.com/watch?v=2y5Pv4yN0b0
>
>>
>> I would much rather have ruthless application of 'good' engineering,
>> deprecating where necessary than continue to pay the cost of a poor
>> decision with every new person.
>
>
> In my opinion, 'good' engineering involves making progress while working
> within your constraints.
>
>>
>> Just remember that every 'yeah, it has
>> always worked like that' or 'yeah, I know, just accept it' a puppy
>> riding on the back of a unicorn led by an angel dies.
>>
>> Optimise for the current users or optimise for the new user? Almost
>> always optimising for the new user is the right decision.
>
>
> Rich has done talks about his perspective on this.
>
> https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md
>
> --
> 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: any? in clojure 1.9.0 alpha

[Colin Yates]

The ship has indeed sailed. However, it is exactly these moments when
software starts to degrade - there are many examples of crufty
software crippled by legacy decisions.

I would much rather have ruthless application of 'good' engineering,
deprecating where necessary than continue to pay the cost of a poor
decision with every new person. Just remember that every 'yeah, it has
always worked like that' or 'yeah, I know, just accept it' a puppy
riding on the back of a unicorn led by an angel dies.

Optimise for the current users or optimise for the new user? Almost
always optimising for the new user is the right decision.

On 8 November 2016 at 07:23, Devin Walters  wrote:
> The more I've thought about it, the more I've resigned myself to the fact
> that any? is the only rational choice. We have `some?`, `some`, `not-any?`,
> and `any?`. There's no resolving the asymmetry without breaking code, and
> it's undeniably true that `any?` reads nicely in the context of specs. I
> don't think I've seen a post mentioning `some?` yet, which surprised me a
> bit. "Fixing" the symmetry of all of this is more than a single name. It is
> a collection of names dating back to 1.0, IIRC. I don't disagree that it
> would be nice if we could go back in time, but generally I think "let it go"
> is good advice. As an aside, the dissonance is more or less consistent. It
> reminds me a little of https://en.m.wikipedia.org/wiki/Multistability.
>
> Perhaps there'll be some liberties taken in 2.0?
>
> Time will tell, but for now I'll echo Alex's suggestion to drop it. This
> particular ship sailed years ago, IMO.
>
> '(Devin Walters)
>
> On Nov 7, 2016, at 10:23 PM, Mars0i  wrote:
>
>
>> Personally I think "any?" and "some?" are aptly named, and that it's the
>> older "not-any?" and "some" functions that mess things up.
>
>
> I can understand the intuition that "not-any?" and "some" are the oddballs,
> but "Are there any Xs?" and "Are there some Xs?" are true in exactly the
> same situations.  Or to remove the predicate, since that's what "some" and
> "not-any?" use: "Is there anything in this thing?" and "Is there something
> in this thing?" are true in the same situations.  So if some? is aptly
> named, then any? is not.  (Maybe "anything?" or "something?" would have been
> better names for some?.)
>
>>
>> Maybe if Clojure were being designed from scratch again, we'd have
>> something like "has" and "not-has?", but it's too late to change common
>> function names now.
>
>
> Yeah--too late.
>
> As well as some still uncommon ones.
> Like "any?".
> :-)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: any? in clojure 1.9.0 alpha

[Colin Yates]

That discussion has left quite a sour taste in my mouth. Naming is so
important and to be blunt, this name is awful:
 - breaks the ubiquitous language of English which already has a very
well defined definition of 'any' and those semantics aren't it
 - breaks the ubiquitous language of Clojure which already has a very
well defined definition for 'predicate'? named fns
 - disregards the very important principle of 'least surprise'
 - is justified and motivated by a very specific contextual use (specs)

The shutting down by Alex is fair enough I think. Clojure was, and
probably will be for the foreseeable future led by a very small,
closely knit design group. Nothing wrong with that.

I am genuinely surprised by this pretty poor engineering on the basis
of a number of pretty fundamental principles. I think "it makes sense
over here" and "b does the semantics associated by a" are both smells
of poor design.

Now, after all that moaning I had better go before somebody asks me
where my perfect bit of software engineering is. Of course, I have
one, but it is unfortunately closed source :-) :-).


On 7 November 2016 at 03:54, Alan Thompson  wrote:
> There was quite a discussion of this topic back in July if you'd like to
> review it:   https://goo.gl/Azy8Nf
>
> The semantic mismatch is unfortunate.
> Alan
>
> On Sun, Nov 6, 2016 at 6:47 PM, waffletower 
> wrote:
>>
>> I disagree, the new implementation is a subset of the code I presented.
>> Here is the docstring from 1.9.0-alpha14
>>
>> (doc any?)
>> -
>> clojure.core/any?
>> ([x])
>>   Returns true given any argument.
>>
>> There isn't a predicate function argument as in (not-any?):
>>
>> (doc not-any?)
>> -
>> clojure.core/not-any?
>> ([pred coll])
>>   Returns false if (pred x) is logical true for any x in coll,
>>   else true.
>>
>> A semantically consistent implementation of (any?), given the current
>> implementation of (not-any?) would provide a similar function prototype
>> where an arbitrary predicate function would evaluate against a collection.
>>
>> On Sunday, November 6, 2016 at 5:05:45 PM UTC-8, James Reeves wrote:
>>>
>>> On 6 November 2016 at 23:31, waffletower  wrote:

 I find the semantic of the new (any?) function to be in conflict with
 (not-any?) and a strange addition, at least with the chosen name.  This
 concern has come up on the "clojure dev" group as well.   I have found a
 different implementation of (any?) useful in my own projects:

 (defn any?
   [pred coll]
   (not (not-any? pred coll)))

 I found it odd that (not-any? pred coll) existed without (any? pred
 coll).
>>>
>>>
>>> The clojure.core/some function does effectively the same thing as your
>>> any? function.
>>>
>>> - James
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 

Re: Dealing with conditional dependencies using reader conditionals

[Colin Yates]

you need to splice the vectors. Flying by so no time but the CLJX
example at http://clojure.org/guides/reader_conditionals gives an
example.



On 30 October 2016 at 17:45, Ricardo Mayerhofer  wrote:
> Hi all,
> I'm developing an isomorphic project with ClojureScript and Clojure. In
> order to solve conditional dependencies I'm trying to use reader
> conditionals just like the code below:
>
> (ns signal.timeline
> (:require #?( :clj  [clj-time.core :as time]
> [clj-time.format :as time-format]
>   :cljs [cljs-time.core :as time]
> [cljs-time.format :as time-format]
> ))
> )
>
>
> The project runs fine in Clojure, however in ClojureScript I get the
> following error, as if it were trying to read clj part and trying to resolve
> Clojure symbols:
>
>
> lein cljsbuild once prod
>
> Feature should be a keyword: [clj-time.format :as time-format] {:type
> :reader-exception, :line 3, :column 58, :file
> "/Users/ricardomayerhofer/Projetos/GB/signal-clojurescript/src/signal/timeline.cljc"}
>
> My configs are as follow:
>
>
> :dependencies [[org.clojure/clojure "1.8.0"]
>[org.clojure/clojurescript "1.9.293"]
>[binaryage/dirac "0.7.2"]
>[binaryage/devtools "0.8.2"]
>[com.andrewmcveigh/cljs-time "0.4.0"]
>[expectations "1.4.35"]
>[clj-time "0.11.0"]
>[cljs-ajax "0.5.8"]]
> :plugins [[lein-figwheel "0.5.4-7"]
>   [lein-cljsbuild "1.1.4"]
>   [lein-expectations "0.0.8"]
>   [lein-autoexpect "1.7.0"]
>   ]
>
> :cljsbuild {
> :builds {:dev {
>:source-paths ["src"]
>:figwheel true
>:compiler {:preloads [devtools.preload
> dirac.runtime.preload]
>   :source-map true
>   :optimizations :none
>   :asset-path
> "http://localhost:3002/js/out;
>   :output-to
> "resources/public/js/main.js"
>   :output-dir
> "resources/public/js/out"}}
>  :prod {
> :source-paths ["src"]
> :compiler {:asset-path
> "https://static.takeabridge.com/js/out;
>:optimizations :advanced
>:pretty-print false
>:output-to
> "resources/public/js/main.js")
>
> Any idea? 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: Java like static typing for Clojure?

[Colin Yates]

Generative testing is great but defining the contract gets more
complex the further away from a 'unit' you get. It is easy to define
extensive generators for (defn length [s]). It is a much bigger
problem to generate extensive inputs for every call-site of (length)
and then every call-site of the call-site of (length) and so on.

This is not a problem limited to clojure.spec, it is a limitation to
any example based testing, and in that sense, a helpful simplifying
lie is to think of generative testing as example based testing on
steroids.

Type systems work across the code base as a whole and are therefore
(in another helpful simplifying lie) more extensive.

The other consideration is that type systems limit the
'specifications' you can give it, clojure.spec specifications can be
as rich as your code and are therefore unbounded.

Don't get me wrong, I am just starting to get into clojure.spec and I
too am very excited, but given the specs are effectively unbounded, it
isn't going to catch all the errors that types are. However, BECAUSE
it is unbounded it can be far more powerful.

Just my 2p (and I haven't had any coffee yet so the above might be
complete drivel).


On 22 October 2016 at 02:00, Daniel  wrote:
>> In this sort of situation, a static type system which provides universal 
>> guarantees (this value can never be null) is more useful than a contract 
>> system (no null values have been seen yet for the test inputs you've tried). 
>> There's simply no way I can test all combinations, or reproduce all 
>> combinations that users might have running.
>
> Isn't a major selling point of generative testing to create loads of unique 
> cases you can't invent on your own?
>
> You don't trust it to do that? Is that from personal experience?  Genuinely 
> curious because I am a little excited about using it in a project at work but 
> this is disheartening.
>
> --
> 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: Java like static typing for Clojure?

[Colin Yates]

Ironically I ran into an issue where I was receiving "" instead of nil
which caused some interesting behaviour.

For those who find these things interesting, this was for capturing
criteria in the UI which was sent to the server to filter. The
behaviour was:

 - form is nil, server ignores the query
 - enter some text, server sends the top N matching records
 - delete the text, you get the first top N records

I am sure you have guessed, but the cause was HTML input fields start
off as nil, enter something and then delete it and you get an empty
"". The server was checking (not (nil? criteria)) rather than (seq
criteria)there is a reason (seq ) is idiomatic :-).

On 21 October 2016 at 19:39, Sean Corfield  wrote:
> On 10/21/16, 10:40 AM, "Colin Fleming"  of colin.mailingl...@gmail.com> wrote:
>
>> Honestly, the easiest solution to my problem is probably just to use
>> Kotlin, which was
>
>> designed by JetBrains for almost exactly my use case, has great IDE
>> support, and has
>
>> a lot of smart people working full-time on it.
>
>
>
> And, to be fair, Kotlin has as a design goal to help address Java’s NPE
> issue. Whereas Clojure has, as part of its design, idiomatic nil-punning. If
> you’re doing a lot of Java interop, Kotlin is going to be a better fit.
>
>
>
> As for Typed Clojure, we’ve tried it a few times and the problems cited by
> CircleCI and by yourself are why we’ve given up on it each time. I will say,
> in Typed Clojure’s defense, that it gets better and better each time I try
> it so it’s definitely going in the right direction – but it is a very hard
> problem to solve!
>
>
>
> Pretty much the only time I ever see NPEs is when my Clojure code touches
> Java interop. And, yes, that can mean numeric ops (since those are
> implemented directly in Java) and string manipulation (again, implemented on
> top of Java).
>
>
>
> As an experiment, I tried a version of clojure.string where nil was always
> treated as “” and it does indeed avoid the NPEs but it comes at a
> performance cost (calling str or adding nil conditions). In the domain in
> which I work, nil -> “” is pretty much universally the right thing so it’s a
> cost we’re considering swallowing, for the extra simplicity it would bring
> to our code (i.e., creating a drop-in replacement of clojure.string that
> implements all of the functions with added str calls as needed – many can be
> handled mechanically).
>
>
>
> We don’t do much numeric work so we don’t hit NPEs in that Java interop
> boundary very often. There tho’ there is almost no argument that nil -> 0
> would be the “right thing” so suffering NPEs instead of some
> NonNumericArgumentException thing isn’t such a horrible trade off.
>
>
>
> 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 10/21/16, 10:40 AM, "Colin Fleming"  of colin.mailingl...@gmail.com> wrote:
>
>
>
> I tried it a couple of years ago, and my impressions were more or less the
> same as CircleCI's here. I found the type annotation burden much higher than
> using a typed language such as Kotlin, the type checking was very slow and
> the boundary between typed and untyped code was really onerous. Ambrose has
> done some great work recently though, so I should check it out again.
> However my general feeling is that retrofitting something like Typed Clojure
> onto an existing language is always going to be more difficult and fraught
> with problems than having a language which was designed with the types in
> mind in the first place.
>
>
>
> Another possibility which I haven't had time to explore properly is Allen
> Rohner's spectrum.
>
>
>
> Honestly, the easiest solution to my problem is probably just to use Kotlin,
> which was designed by JetBrains for almost exactly my use case, has great
> IDE support, and has a lot of smart people working full-time on it. However
> that has a couple of problems: 1) it would make me sad and 2) I would no
> longer be dogfooding Cursive all the time, which is a valuable source of
> finding bugs during development. But at least I'd be spending all my time on
> developing Cursive features, and not chasing NPEs or investigating all this.
>
>
>
>
>
> --
> 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 

Re: Java like static typing for Clojure?

[Colin Yates]

"making me sad" is unsustainable - problem solving with 1s and 0s is
hard enough as it is without using demotivating tools :-).

On 21 October 2016 at 18:40, Colin Fleming  wrote:
> I tried it a couple of years ago, and my impressions were more or less the
> same as CircleCI's here. I found the type annotation burden much higher than
> using a typed language such as Kotlin, the type checking was very slow and
> the boundary between typed and untyped code was really onerous. Ambrose has
> done some great work recently though, so I should check it out again.
> However my general feeling is that retrofitting something like Typed Clojure
> onto an existing language is always going to be more difficult and fraught
> with problems than having a language which was designed with the types in
> mind in the first place.
>
> Another possibility which I haven't had time to explore properly is Allen
> Rohner's spectrum.
>
> Honestly, the easiest solution to my problem is probably just to use Kotlin,
> which was designed by JetBrains for almost exactly my use case, has great
> IDE support, and has a lot of smart people working full-time on it. However
> that has a couple of problems: 1) it would make me sad and 2) I would no
> longer be dogfooding Cursive all the time, which is a valuable source of
> finding bugs during development. But at least I'd be spending all my time on
> developing Cursive features, and not chasing NPEs or investigating all this.
>
> On 21 October 2016 at 19:20, Josh Tilles  wrote:
>>
>> Out of curiosity, did you try Typed Clojure? It certainly has its rough
>> edges, but you sound willing to bear the burden of annotating code with
>> types (at the top-level, at least) and I think its treatment of Java interop
>> does what you want: unless instructed otherwise, the typechecker assumes
>> that arguments to Java methods must not be nil and that any Java method may
>> return nil.
>>
>> On Thursday, October 20, 2016 at 8:39:04 AM UTC-4, Colin Fleming wrote:
>>>
>>> I recently spent a bunch of time researching exactly this. My motivation
>>> was that my main project, Cursive, suffers from a ton of NPEs which I find
>>> very difficult to manage. I wanted to see how difficult it would be to have
>>> a typed Clojure-like thing, using something similar to Kotlin's type system.
>>> Kotlin uses a type system which is similar to Java and has Java interop as a
>>> primary goal, which I would also need since Java interop is essential to me.
>>> It fixes a bunch of flaws in the Java type system and adds new features like
>>> nullable types, which I now find it difficult to live without.
>>>
>>> Before anyone asks, spec is not useful for me because it relies heavily
>>> on generative testing to increase your confidence in your functions. I can't
>>> use generative testing because my application is tied to a large Java
>>> codebase which I cannot model to any useful degree. Essentially, spec
>>> recommends runtime tests at the boundary of your system, and nearly my
>>> entire system is interop boundary. I'm not interested in runtime checks
>>> except where absolutely necessary - Kotlin does this for me transparently,
>>> spec doesn't.
>>>
>>> Here's a short list of my findings. I'm happy to expand on any of these
>>> points if anyone is curious. It bears repeating - Java interop is
>>> non-negotiable for me, and that makes a lot of this harder than it would be
>>> otherwise.
>>>
>>> Disclaimer: I'm no programming language expert. This was hard for me, and
>>> a surprising amount of it was new to me. I'd appreciate any corrections or
>>> clarifications.
>>>
>>> Type systems are hard. I for one didn't appreciate the complexity that
>>> goes into making them easy to use. Don't be fooled by the 20-line
>>> implementations of Hindley-Milner.
>>> In particular, generics are very hard, and variance for generic objects
>>> (i.e. the intersection of generic objects and OO) is the source of much
>>> difficulty.
>>> Type systems are split into two main camps - nominal typing (like Java,
>>> where the types are identified by names) and structural typing, where the
>>> type of an object is defined by it's "shape", like Go's interfaces.
>>> One of the major benefits of Clojure is its heterogeneous collections,
>>> a.k.a. "just use a map". This is very difficult to maintain in a type-safe
>>> manner without losing most of the benefit.
>>> There are two main things I was interested in from a type system - type
>>> checking (i.e. making sure that your program's types are correct) and type
>>> inference (working out what the types of things are from the code, so you
>>> don't have to annotate everything). Type checking is relatively
>>> straightforward, but type inference can be very hard indeed.
>>> Much of the complication comes from the need to interop with Java.
>>> ML-style interface essentially doesn't work if you want to maintain
>>> compatibility with Java since it 

Re: Slides for my talk at EuroClojure 2016

[Colin Yates]

thanks Mauricio

On 21 October 2016 at 14:09, Mauricio Aldazosa
<mauricio.aldaz...@gmail.com> wrote:
>
>
> On Fri, Oct 21, 2016 at 3:36 AM, Colin Yates <colin.ya...@gmail.com> wrote:
>>
>> +1.
>>
>> Remind my old befuddled brain of the JS library used to produce those
>> 3d-like presentations?
>
>
> Looks like reveal.js
>
> Cheers,
> Mauricio
>
> --
> 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: Slides for my talk at EuroClojure 2016

[Colin Yates]

+1.

Remind my old befuddled brain of the JS library used to produce those
3d-like presentations?

On 21 October 2016 at 00:22, Sean Corfield  wrote:
> That is some seriously impressive performance (in the slides) – very nice!
>
>
>
> 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 10/20/16, 4:02 PM, "Dragan Djuric"  draga...@gmail.com> wrote:
>
>
>
> Fixed it to be a hardcoded absolute address. Should work everywhere now.
> Thanks for reporting.
>
>
>
> --
> 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: Slides for my talk at EuroClojure 2016

[Colin Yates]

Chrome manages to interpret it correctly.

Any one fancy a diversion of the 'fail fast/help the user' dilemma? :-)

On 20 October 2016 at 23:40, Sean Corfield <s...@corfield.org> wrote:
> The source of your blog post has
>
>
>
> The slides are available  href="http:/talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html">here,
>
>
>
> I’m surprised any browser manages to make a legal hyperlink out of that… J
>
>
>
> 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 10/20/16, 3:37 PM, "Dragan Djuric" <clojure@googlegroups.com on behalf of
> draga...@gmail.com> wrote:
>
>
>
> Hmm, what browser do you use? The link that I'm been shown in the browser is
> http://dragan.rocks/talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html
>
> and it works...
>
> On Thursday, October 20, 2016 at 11:43:05 PM UTC+2, Colin Yates wrote:
>
> Unfortunately clicking on the 'here' link takes you to a 404:
> http://talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html
>
> On 20 October 2016 at 22:38, Dragan Djuric <drag...@gmail.com> wrote:
>> Hi all, I posted slides for my upcoming EuroClojure talk, so you can enjoy
>> the talk without having to take notes:
>>
>> http://dragan.rocks/articles/16/Clojure-is-not-afraid-of-the-GPU-slides-EuroClojure
>>
>
>
>
>
>
> --
> 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: Slides for my talk at EuroClojure 2016

[Colin Yates]

I'm using Safari on El Capitan - just tried again with the same
effect. However, in Chrome (on the same machine) it works fine.

I wouldn't worry, it is probably just the magnetic force I seem to be
emitting at the moment which makes computers do randomly stupid
things.



On 20 October 2016 at 23:37, Dragan Djuric <draga...@gmail.com> wrote:
> Hmm, what browser do you use? The link that I'm been shown in the browser is
> http://dragan.rocks/talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html
> and it works...
>
> On Thursday, October 20, 2016 at 11:43:05 PM UTC+2, Colin Yates wrote:
>>
>> Unfortunately clicking on the 'here' link takes you to a 404:
>> http://talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html
>>
>> On 20 October 2016 at 22:38, Dragan Djuric <drag...@gmail.com> wrote:
>> > Hi all, I posted slides for my upcoming EuroClojure talk, so you can
>> > enjoy
>> > the talk without having to take notes:
>> >
>> > http://dragan.rocks/articles/16/Clojure-is-not-afraid-of-the-GPU-slides-EuroClojure
>> >
>> > --
>> > 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: Slides for my talk at EuroClojure 2016

[Colin Yates]

Unfortunately clicking on the 'here' link takes you to a 404:
http://talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html

On 20 October 2016 at 22:38, Dragan Djuric  wrote:
> Hi all, I posted slides for my upcoming EuroClojure talk, so you can enjoy
> the talk without having to take notes:
> http://dragan.rocks/articles/16/Clojure-is-not-afraid-of-the-GPU-slides-EuroClojure
>
> --
> 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: Java like static typing for Clojure?

[Colin Yates]

Thanks Sean.

On 17 October 2016 at 19:21, Sean Corfield <s...@corfield.org> wrote:
> We have 1.9 Alpha 13 in production.
>
> We’ve had nearly all the 1.9 Alpha builds in production. After all, right now 
> 1.9 = 1.8 plus clojure.spec with some minor additions to clojure.core (new 
> predicates).
>
> 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 10/17/16, 10:47 AM, "Colin Yates" <clojure@googlegroups.com on behalf of 
> colin.ya...@gmail.com> wrote:
>
> I have finally found time to watch Stu's video. It was very useful
> introducing clojure.spec (even if I thought he over-egged the pudding
> somewhat ;-)).
>
> I know there is a back port, but are there any other strategies of
> using this on 1.9 and building against 1.8? I was thinking of building
> a tower of yaks such that a lein 1.9 profile included a src directory
> which had all of the spec declarations in which the 1.8 profile used
> in production excluded. I am hesitant to rely on 1.9 at the moment -
> how stable have others found it?
>
>
>
>
> --
> 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: Java like static typing for Clojure?

[Colin Yates]

I have finally found time to watch Stu's video. It was very useful
introducing clojure.spec (even if I thought he over-egged the pudding
somewhat ;-)).

I know there is a back port, but are there any other strategies of
using this on 1.9 and building against 1.8? I was thinking of building
a tower of yaks such that a lein 1.9 profile included a src directory
which had all of the spec declarations in which the 1.8 profile used
in production excluded. I am hesitant to rely on 1.9 at the moment -
how stable have others found it?

On 17 October 2016 at 13:08, Timothy Baldridge  wrote:
> I highly recommend this talk on Spec by Stu Halloway. Spec is a new feature
> coming in Clojure 1.9, and this talk goes into the pros/cons of static
> typing and tests and shows how there can be a better way.
>
> https://www.youtube.com/watch?v=VNTQ-M_uSo8
>
>
>
> On Sun, Oct 16, 2016 at 5:58 PM, Alan Thompson  wrote:
>>
>> Be sure to check out Plumatic Schema (previously Prismatic Schema) if you
>> haven't already.  There is also a good Clojure Conj video from 2013.
>> Alan
>>
>> On Sat, Oct 15, 2016 at 3:14 PM, Didier  wrote:
>>>
>>> I know a lot of people like to say how unhelpful Java like static typing
>>> is, and only more powerful type systems of the ML family add value, but I've
>>> been wondering recently if for Clojure it wouldn't make more sense to simply
>>> extend the type hints to enable an optional Java like static typing scheme.
>>>
>>> It is my understanding that ML style static typing is incredibly
>>> difficult to add properly and without compromise to a dynamic language. That
>>> doing so limits the scope of type inference, rendering the task of adding
>>> type info more tedious then in ML languages themselves.
>>>
>>> ML style static typing provide enhanced safety grantees, but seem to add
>>> too much complexity to Clojure to be practical. What about a Java like
>>> static typing scheme though?
>>>
>>> I haven't found in practice that the safety of Clojure was an issue, as
>>> the REPL workflow tend to promote quite a lot of testing. So I'm not too
>>> worried about needing the state of the art of provable correctness for my
>>> programs. What has been a biggest cause of issue to me was refactoring and
>>> shared code base across a team. Those last two use cases are actually pretty
>>> well handled by Java like static type checking. Is it a powerful type
>>> checker, not really, but it enables most trivial type errors to be caught
>>> early, and it allows easier integration points for other devs to follow, as
>>> well as documentation for functions, better tools support and easier
>>> refactoring, while also enabling performance optimizations.
>>>
>>> I have limited knowledge in typing systems, and have no idea how easy it
>>> is to implement them, but as a user of Clojure, I feel like I would find an
>>> optional Java like static typing a great addition, one that I am more
>>> willing to use and benefit from then Typed Clojure's more complex ML style
>>> type checking.
>>>
>>> What do other think?
>>> Can anyone with better knowledge tell me if this would be feasible or if
>>> adding such gradual typing system is effectively as hard as adding ML style
>>> type checking?
>>>
>>> --
>>> 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.
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received 

Re: Any interest in a data-driven build tool?

[Colin Yates]

I can't offer any time unfortunately but you can certainly have a
chunk of my interest - will be fascinating to see how this pans out.

On 15 October 2016 at 15:46, James Reeves  wrote:
> I've been playing around with an idea for a new build tool that I'm
> currently calling "Hop", and I was wondering if there was any interest from
> the community.
>
> I've gotten the barest minimum working here:
> https://github.com/weavejester/hop
>
> Hop uses a data-driven build file, and rather than executing tasks directly,
> it builds a bash script which is then cached and executed. If the build file
> remains the same, Hop uses the cached script directly.
>
> After the cache is established, this should make Hop faster than Leiningen,
> while maintaining process isolation. It also opens up the possibility of
> preloading a pool of VMs to get around load times.
>
> I'll be working on this every so often whenever I'm between projects, but if
> anyone else wants to get involved, I've set up some issues for features that
> should be good starting points.
>
> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: complex made simple?

[Colin Yates]

It has been a while since I watched, but are you asking in terms of
solutions (e.g. process modelling) or implementations (e.g.
architectural styles). It is really hard to give any comprehensive
answer here but some 'tools' I have found useful are:
 - clear thinking
 - identifying abstractions - by abstraction I mean strictly
'something that removes ambiguity and allows you to talk more clearly
about it'
 - Domain Driven Design for a mechanism of breaking down complex
domains. The Ubiquitous Language alone is worth its weight in gold
 - Event Sourcing and hexagonal architectures for handling complex
implementations

By far and away though, "clear thinking" is the tool which had the
most effort. For this, I highly recommend the Theory of Constraints.

Another technique I use heavily is describing things to the duck and
noting how many times I have to use the word 'and' or, 'except in this
case when ...'.

Not sure this answered the question you were asking :-).

On 14 October 2016 at 10:59, 'Alan Forrester' via Clojure
 wrote:
> In Rich Hickey's talk "Simple Made Easy" he mentioned that there are
> ways to take a system that somebody else wrote that is complex and
> simplify it.
>
> Can anyone recommend some resources on how to do this?
>
> Thanks,
> Alan Forrester
>
> --
> 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: Love the Medley library :)

[Colin Yates]

Thanks for the prompt to look at that again. I am not ashamed to say
that after doing Clojure full-time for years now, I still find value
in seeing other people's project.clj let alone their actual code :-).

On 14 October 2016 at 04:17, Alan Thompson  wrote:
> I had nearly forgotten all of the very convenient functions in the Medley
> library until I was reminded by a small mention in the Clojure Cheatsheet.
> It allows you to very easily remove nil values from a list of maps and merge
> them all together:
>
> (ns clj.core
>   (:require [tupelo.core :as t]
> [medley.core :as medley] ))
> (t/refer-tupelo)
>
> (def src [ {:a 1 :b nil}
>{:c 3 }
>{:d nil :e 5 } ] )
>
> (spyx (apply glue src))
> ;=> (apply glue src) => {:a 1, :b nil, :c 3, :d nil, :e 5}
>
> (spyx (medley/remove-vals nil? {:d nil :e 5}))
> ;=> (medley/remove-vals nil? {:d nil, :e 5}) => {:e 5}
>
> (def result (medley/remove-vals
>   nil?
>   (apply t/glue src)))
> (spyx result)
> ;=> result => {:a 1, :c 3, :e 5}
>
>
> Alan
>
>
> --
> 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: newbee mystery

[Colin Yates]

I wouldn't say it is different, only that the REPL is doing an extra
step (printing) which forces the evaluation of that lazy sequence. As
James mentions, your code can force the evaluation of a lazy sequence
using doseq or dorun.

Lazy sequences are great when you get used to them but they can trip
people up, particularly in the fact that often a fn will return a lazy
seq which is then processed into another lazy seq which is then
processed into another lazy seq etc. etc. Finally it is evaluated and
an exception is thrown, and whilst the stack trace will contain the
call site that threw the exception it may be far away from the fn that
actually evaluates the seq.

You might also want to ensure that your REPL has a sensible value for
*print-length* (https://clojuredocs.org/clojure.core/*print-length*)
which stops the REPL evaluating the entire lazy sequence.

Without it, (range) will do nothing in your code but will blow up your
REPL :-).

On 9 October 2016 at 03:29, Phil Virgo  wrote:
> Thanks James.  So the repl behaves differently from some compiled code -
> good to know!
>
> I don't yet know about the "safe" issues "read-eval".  This came with the
> little template built by lein.  But I'll read up on it.
>
> On Saturday, October 8, 2016 at 10:11:29 PM UTC-4, James Reeves wrote:
>>
>>
>>
>> On 9 October 2016 at 03:00, Phil Virgo  wrote:
>>>
>>> WHY?
>>>
>>> The following prints 1/n 2/n 3/n fine in the repl
>>>
>>> (for [f [1 2 3]] (println f))
>>>
>>> But does nothing in this lein project (the "Hello World???" does print)
>>>
>>> (ns slide.core
>>>   (:gen-class))
>>>
>>> (defn -main
>>>   [& args]
>>>   ;; work around dangerous default behaviour in Clojure
>>>   (alter-var-root #'*read-eval* (constantly false))
>>> (for [f [1 2 3]] (println f))
>>>   (println "Hello, World??"))
>>
>>
>> The "for" macro is lazy. It only evaluates the items in the list when it's
>> consumed. You want the "doseq" macro instead, which is used for
>> side-effects.
>>
>> Incidentally, setting *read-eval* to false doesn't make clojure.core/read
>> safe. You should always consider clojure.core/read to be unsafe for use with
>> data from sources you don't control. Instead use something like
>> clojure.edn/read, which is designed to be safe.
>>
>> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Re-launching Expectations!

[Colin Yates]

Thanks Sean.

On 6 October 2016 at 19:03, Sean Corfield  wrote:
>> is there a 'benefits over clojure.test' blog anywhere?
>
> Not that I’m aware of. I added a GH issue against the website content for 
> that. Jay wrote a series of blog posts about Expectations back in 2011 that 
> included the justification for it:
>
> http://blog.jayfields.com/2011/11/clojure-expectations-introduction.html
>
>> I wonder if it is the benefits are more subjective
>
> Yes, I find the BDD-style of Expectations much more to my liking than the 
> assertive style of clojure.test – the latter feels very imperative to me. So 
> there’s definitely an element of stylistic preference at play here.
>
>> I personally like the names I give to tests etc.
>
> Jay has an opinion on that – see 
> http://blog.jayfields.com/2011/11/clojure-expectations-unit-testing-wrap.html
>
> I’m split on the topic. There’s a practical reason for giving tests names, 
> and that relates to tooling and, in particular, what CIDER and other tools 
> expect (and in fact that is what has triggered this whole re-launching: in 
> order to better support tooling at large, Expectations needs to provide a way 
> to give predictable names to tests so that tooling can run and re-run 
> individual tests).
>
> Sean
>
>
>
> --
> 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: [ANN] Re-launching Expectations!

[Colin Yates]

Thanks Sean. I did have a look at that a whilst ago (when I was
considering migrating to core clojure.test from midge). I think I 'get
it', but is there a 'benefits over clojure.test' blog anywhere?

I wonder if it is the benefits are more subjective - I personally like
the names I give to tests etc.

Anyways, thanks for picking this up.

On 6 October 2016 at 18:05, Sean Corfield  wrote:
> Expectations – a minimalist’s unit testing framework – is being re-launched!
>
>
>
> adding signal, removing noise
>
>
>
> Jay Fields’ awesome unit testing library and all of the associated tooling
> has now been pulled together under a single GitHub organization:
>
>
>
> https://github.com/clojure-expectations
>
>
>
> The documentation is available here:
>
>
>
> https://clojure-expectations.github.io
>
>
>
> (for now, this is just a copy of Jay’s documentation site for Expectations
> but the plan is to expand it to include all of the tooling as well)
>
>
>
> If you use Expectations and any of its current tooling, we’d like to have
> your input – please feel free to open GitHub issues with suggestions!
>
>
>
> If you don’t use Expectations but you like BDD-style terminology, perhaps
> it’s time to take a look?
>
>
>
> Why has this happened?
>
>
>
> Expectations doesn’t currently support the clojure.test “protocol” that
> CIDER (and other tooling) expects, but making that happen is going to
> involve quite a few changes (or additions) to how Expectations works, as
> well as a ripple effect through the tooling.
>
>
>
> The current maintainers did not necessarily have the time to invest in such
> changes, but were very open to pooling their work and making it easier for
> others to get involved. World Singles is a heavy user of Expectations so I
> have a vested interest in helping to maintain the Expectations ecosystem
> going forward, especially after adding support for Boot.
>
>
>
> I’d like to thank Jay Fields for creating Expectations – it has made me love
> testing all over again! – and also thanks to Gareth Jones and Jake McCrary
> for their Leiningen and Emacs tooling.
>
>
>
> Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
>
> An Architect's View -- http://corfield.org/
>
>
>
> "Perfection is the enemy of the good."
>
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>
>
> --
> 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: Idiom question

[Colin Yates]

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, p...@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 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-
>> 

Re: Idiom question

[Colin Yates]

You might want to checkout 'cond->', 'condp' and 'as->'. Checkout the
excellent clojuredocs.org website for examples of their usage
(https://clojuredocs.org/clojure.core/condp for example).

Sorry to be so succinct - deadlines etc.

On Wed, 28 Sep 2016, at 03:26 PM, p...@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 (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.

-- 
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: Insane stack trace with no reference to my code

[Colin Yates]

Narrowing the problem down, on an error the error handler serialises
the current UI state (which can be very large) to EDN and persists that
in a DB. I am thinking something in there is throwing an exception
which, when I try to log it out, causes the recursion. This throws
another exception and only the top 1024 frames of the secondary
exception is printed.

Thanks all, this is really helpful.

Digging continues.

On Tue, 27 Sep 2016, at 11:41 AM, Ragnar Dahlén wrote:
> Hi Colin,
>
> I think you're correct in that something is calling print on a largish
> data structure (possibly due to "loops" like Thomas points out), and
> due to the recursive nature of print you're running out of stack
> space. The JVM (hotspot anyway) will by default only keep the top 1024
> stack frames which is likely why you're not seeing your code anywhere:
>
> $ java -XX:+PrintFlagsFinal -version | grep MaxJavaStackTraceDepth
>  intx MaxJavaStackTraceDepth= 1024
>  {product}
>
> You could try increasing that value, or increasing the stack size (-
> Xss), or possibly binding *print-length* to something small to
> troubleshoot this problem.
>
> /Ragnar
>
> On Tuesday, 27 September 2016 11:16:15 UTC+1, Colin Yates  wrote:
>> Thanks Thomas. The NREPL is a red herring as that is a printout from
>> my local machine - the production error doesn't reference any REPLs -
>> I should have stated that. Unfortunately I can't get it from
>> production as it is a very locked down environment (no copy and
>> paste, no internet connection etc.).
>>
>> To be clear, I get this behaviour from a web request.
>>
>> I might be doing something stupid with components referencing
>> themselves but I don't think so - good call though and somewhere to
>> reference. Still mystified as to why there is no reference to my code
>> though.
>>
>> Thanks Thomas.
>
> --
>  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: Insane stack trace with no reference to my code

[Colin Yates]

Great tip - thanks Ragnar

On Tue, 27 Sep 2016, at 11:41 AM, Ragnar Dahlén wrote:
> Hi Colin,
>
> I think you're correct in that something is calling print on a largish
> data structure (possibly due to "loops" like Thomas points out), and
> due to the recursive nature of print you're running out of stack
> space. The JVM (hotspot anyway) will by default only keep the top 1024
> stack frames which is likely why you're not seeing your code anywhere:
>
> $ java -XX:+PrintFlagsFinal -version | grep MaxJavaStackTraceDepth
>  intx MaxJavaStackTraceDepth= 1024
>  {product}
>
> You could try increasing that value, or increasing the stack size (-
> Xss), or possibly binding *print-length* to something small to
> troubleshoot this problem.
>
> /Ragnar
>
> On Tuesday, 27 September 2016 11:16:15 UTC+1, Colin Yates  wrote:
>> Thanks Thomas. The NREPL is a red herring as that is a printout from
>> my local machine - the production error doesn't reference any REPLs -
>> I should have stated that. Unfortunately I can't get it from
>> production as it is a very locked down environment (no copy and
>> paste, no internet connection etc.).
>>
>> To be clear, I get this behaviour from a web request.
>>
>> I might be doing something stupid with components referencing
>> themselves but I don't think so - good call though and somewhere to
>> reference. Still mystified as to why there is no reference to my code
>> though.
>>
>> Thanks Thomas.
>
> --
>  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: Insane stack trace with no reference to my code

[Colin Yates]

Thanks Thomas. The NREPL is a red herring as that is a printout from my 
local machine - the production error doesn't reference any REPLs - I should 
have stated that. Unfortunately I can't get it from production as it is a 
very locked down environment (no copy and paste, no internet connection 
etc.).

To be clear, I get this behaviour from a web request.

I might be doing something stupid with components referencing themselves 
but I don't think so - good call though and somewhere to reference. Still 
mystified as to why there is no reference to my code though.

Thanks Thomas.

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

Insane stack trace with no reference to my code

[Colin Yates]

Hi all,

I have a problem that has been hounding me for a while but has increased in 
frequency. Basically, something goes wrong with my code and I get a mother 
of all stack traces, but my code isn't referenced in it anywhere. 

My gut is telling me it is to do with schema validation - when that fails 
and it tries to print out the error, something gets confused and ends up 
with the stack trace. I had a similar problem using the Component library 
when I printed out a system map which included a heavily populated cache. 
If I recall it was a slightly different stack trace though.

Any ideas as to where to go with this?

The stack trace is:

java.lang.StackOverflowError: null
 at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
 at java.util.regex.Pattern$Branch.match(Pattern.java:4604)
 at java.util.regex.Pattern$Branch.match(Pattern.java:4602)
 at java.util.regex.Pattern$BranchConn.match(Pattern.java:4568)
 at java.util.regex.Pattern$GroupTail.match(Pattern.java:4717)
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4279)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4234)
 at java.util.regex.Pattern$GroupHead.match(Pattern.java:4658)
 at java.util.regex.Pattern$Branch.match(Pattern.java:4604)
 at java.util.regex.Pattern$Branch.match(Pattern.java:4602)
 at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3798)
 at java.util.regex.Pattern$Start.match(Pattern.java:3461)
 at java.util.regex.Matcher.search(Matcher.java:1248)
 at java.util.regex.Matcher.find(Matcher.java:664)
 at java.util.Formatter.parse(Formatter.java:2549)
 at java.util.Formatter.format(Formatter.java:2501)
 at java.util.Formatter.format(Formatter.java:2455)
 at java.lang.String.format(String.java:2940)
 at clojure.core$format.invokeStatic(core.clj:5533)
 at clojure.core$print_tagged_object.invokeStatic(core_print.clj:106)
 at clojure.core$print_object.invokeStatic(core_print.clj:110)
 at clojure.core$fn__6044.invokeStatic(core_print.clj:113)
 at clojure.core$fn__6044.invoke(core_print.clj:113)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_map$fn__6094.invoke(core_print.clj:212)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$print_map.invokeStatic(core_print.clj:208)
 at clojure.core$fn__6097.invokeStatic(core_print.clj:217)
 at clojure.core$fn__6097.invoke(core_print.clj:217)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_map$fn__6094.invoke(core_print.clj:212)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$print_map.invokeStatic(core_print.clj:208)
 at clojure.core$fn__6115.invokeStatic(core_print.clj:271)
 at clojure.core$fn__6115.invoke(core_print.clj:268)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_map$fn__6094.invoke(core_print.clj:212)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$print_map.invokeStatic(core_print.clj:208)
 at clojure.core$fn__6115.invokeStatic(core_print.clj:271)
 at clojure.core$fn__6115.invoke(core_print.clj:268)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_map$fn__6094.invoke(core_print.clj:212)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$print_map.invokeStatic(core_print.clj:208)
 at clojure.core$fn__6115.invokeStatic(core_print.clj:271)
 at clojure.core$fn__6115.invoke(core_print.clj:268)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_map$fn__6094.invoke(core_print.clj:212)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$print_map.invokeStatic(core_print.clj:208)
 at clojure.core$fn__6115.invokeStatic(core_print.clj:271)
 at clojure.core$fn__6115.invoke(core_print.clj:268)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr_on.invoke(core.clj:3566)
 at clojure.core$print_sequential.invokeStatic(core_print.clj:59)
 at clojure.core$fn__6092.invokeStatic(core_print.clj:204)
 at clojure.core$fn__6092.invoke(core_print.clj:204)
 at clojure.lang.MultiFn.invoke(MultiFn.java:233)
 at clojure.core$pr_on.invokeStatic(core.clj:3572)
 at clojure.core$pr.invokeStatic(core.clj:3575)
 at clojure.core$pr.invoke(core.clj:3575)
 at clojure.lang.AFn.applyToHelper(AFn.java:154)
 at clojure.lang.RestFn.applyTo(RestFn.java:132)
 at clojure.core$apply.invokeStatic(core.clj:646)
 at clojure.core$pr_str.invokeStatic(core.clj:4580)
 at 

Re: map/filter/remove etc. change underlying structure

[Colin Yates]

I did look at Specter and it looks nice and well engineered, but I never
really ran into the sorts of problem it solves, at least not enough to
warrant the cost of depending on a new library.

On Fri, 9 Sep 2016, at 12:49 PM, Mamun wrote:
> To me, Changing type or order is a lack of facility for basic task.
> In the end comping task is also become more hard.
> Have you tried to use Specter? Why do you not consider Specter lib?
>
>
> Br,
> Mamun
>
>
>
>
>
> On Friday, September 9, 2016 at 12:23:37 PM UTC+2, Colin Yates wrote:
>> Hi all,
>>
>> So in the spirit of exposing my ignorance to the internet :-), I have
>> just been bitten by a bug due to the behaviour of the core libraries
>> which I find really surprising:
>>
>> (def v [1 2 3])
>> (conj v 4) => [1 2 3 4]
>> (conj (map identity v) 4) => (4 1 2 3)
>> (conj (remove (constantly false) v) 4) => (4 1 2 3)
>> (conj (filter identity v) 4) => (4 1 2 3)
>>
>> In other words, I was relying on map, remove and filter preserving
>> the semantics (other than laziness) of the structure of the input,
>> give it a vector and you get a vector-like lazy sequence. This turns
>> out not to be the case.
>>
>> Now, I know there is mapv which returns a vector but why isn't there
>> a removev and a filterv etc.?
>>
>> What makes it more onerous for me is the fact conj states that its
>> behaviour differs depending on the concrete type, which is great, but
>> how am I supposed to know which concrete type is returned from
>> map|filter|remove? My assumption was it would be semantically
>> equivalent to the input (i.e. a vector in this case).
>>
>> The reason I have dodged this is because I don't frequently rely on
>> vector semantics but I am surprised this isn't better documented?
>>
>> Is it me?
>>
>> Thanks,
>>
>> Colin
>
> --
>  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.

map/filter/remove etc. change underlying structure

[Colin Yates]

Hi all,

So in the spirit of exposing my ignorance to the internet :-), I have just 
been bitten by a bug due to the behaviour of the core libraries which I 
find really surprising:

(def v [1 2 3])
(conj v 4) => [1 2 3 4]
(conj (map identity v) 4) => (4 1 2 3)
(conj (remove (constantly false) v) 4) => (4 1 2 3)
(conj (filter identity v) 4) => (4 1 2 3)

In other words, I was relying on map, remove and filter preserving the 
semantics (other than laziness) of the structure of the input, give it a 
vector and you get a vector-like lazy sequence. This turns out not to be 
the case.

Now, I know there is mapv which returns a vector but why isn't there a 
removev and a filterv etc.?

What makes it more onerous for me is the fact conj states that its 
behaviour differs depending on the concrete type, which is great, but how 
am I supposed to know which concrete type is returned from 
map|filter|remove? My assumption was it would be semantically equivalent to 
the input (i.e. a vector in this case).

The reason I have dodged this is because I don't frequently rely on vector 
semantics but I am surprised this isn't better documented?

Is it me?

Thanks,

Colin

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

[Colin Yates]

This form allows the fn to have multiple arities. So if I call (recursive-
printer) it will 'invoke' ([] (recursive-printer 0)). If I call (recursive-
printer 1) then it will 'invoke' ([iteration] ...).

HTH

--
  Colin Yates
  colin.ya...@gmail.com



On Sun, 4 Sep 2016, at 09:54 PM, Charlie wrote:
> I'm going through the Do Things: A Clojure Crash Course, and the
> following example (in REPL) is presented:
>
> (defn recursive-printer  ([]  (recursive-printer ))  ([iteration]
> (println iteration)  (if (> iteration 3)  (println "Goodbye!")  (recursive-
> printer (inc iteration) (recursive-printer) ; => Iteration 0 ; =>
> Iteration 1 ; => Iteration 2 ; => Iteration 3 ; => Iteration 4 ; =>
> Goodbye!
>
> This works as expected, but I don't understand the syntax of the
> function definition. Specifically: (defn recursive-printer ([] (recursive-
> printer 0)). Isn't the parameter list supposed to be a vector []
> not ([]...)? Also, I don't see how [iteration] is resolved on the
> next line.
>
> Thanx for any help!
>
>
> --
>  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: Frustrations so far

[Colin Yates]

Abstractions and dynamic/static typing are orthogonal. Static/dynamic
is simply _when_ types are considered. Strong/weak typing is arguably
more relevant and is about how narrowly type information is
considered.

I can't find an actual declaration but I consider Clojure is dynamic
but strongly typed. Some dynamically typed languages tend to be more
forgiving when asking questions and will guess at what you are asking
regardless of whether they are statically or dynamically typed, so
Ruby (sort of strongly typed) and JavaScript (weakly typed) have no
problem with asking if an Integer is empty.

Wow, that reads like I am lecturing down to somebody - apologies, that
isn't my intent. Half of the problem is that like 'Functional
Programming' there isn't really an authoritative definition of
'strongly typed' or 'weakly typed' :-).

On 23 July 2016 at 14:15, 'Adrian A.' via Clojure
 wrote:
>
>
>> The point is that an 'Integer'
>> (abstraction) has no sense of 'emptiness' or 'fullness'.
>>
> IMHO that might be true for a statically typed language, but in the case of
> a dynamic language like Clojure it makes perfect sense, and most users
> expect
> this behavior.
>
> --
> 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: Frustrations so far

[Colin Yates]

As James said it is correct, but maybe not intuitive. Intuitively we
think an integer isn't empty, but actually it is a non-sensical
question - Integers can no more be empty than they can be full.

I noticed that Clojure's use of abstractions, and sticking to those
abstractions is far greater than in other languages (I used at least)
and getting on board with that really helps. Sure, you could ask _the
data structure holding the value of an int_ whether it is 'full' in
some sense, but that isn't the point. The point is that an 'Integer'
(abstraction) has no sense of 'emptiness' or 'fullness'.

On 22 July 2016 at 23:22, James Reeves  wrote:
> On 22 July 2016 at 16:42, Peter Romfeld  wrote:
>>>
>>>

 Im frustrated with `empty?` throwing exceptions for Long and Keyword
>>>
>>>
>>> What should happen? Asking whether an integer or keyword is "empty?"
>>> doesn't really make sense IMO, and if it doesn't make sense, it should throw
>>> an exception.
>>
>>
>> well its a fn?... "?" ! i would only expect a boolean out of it, of course
>> if you read doc and look implementation it makes sense what it does, i still
>> think that a function called "empty?" should not throw up, if its an Number
>> or Keyword its in my opinion not an empty value! (i understand that a Number
>> or Keyword is not sequential.. but then call it "not-seq?")
>
>
> I think your expectation is perhaps wrong in this case. Predicates should
> throw an exception on invalid inputs. If you're passing a number or keyword
> to `empty?` then there's an error in your code. Throwing an exception rather
> than failing silently is absolutely the right thing to do.
>
> The `empty?` function isn't particularly unusual in throwing exceptions.
> `(pos? "foo")` will throw an error, as will `(> "foo" 1)`. If you pass an
> input that doesn't make sense, then an exception should be thrown.
>
 security features in most frameworks are just smoke and mirrors,
 functions that dont actually do what they should do...
>>>
>>>
>>> Do you have an example?
>>
>>
>> I dont want to make negative advertisement,  but its about csrf, and
>> giving false sense of being taken care of for people who dont fully
>> understand it
>
>
> I maintain Ring-Anti-Forgery, so if it's anything to do with that, feel free
> to raise a concern. Maybe the documentation can be improved.
>
> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Good post on remote working

[Colin Yates]

Having worked from home for close to 6 years now I would add:
 - get an exercise regime. Seriously. The c25K program is great for
those would like to become runners.
 - regularly go to the office, without fail. Once a month at least.
 - in that office get everybody around the whiteboard.
 - determine chains of responsibility - is it an 'ask permission' or
'ask forgiveness' environment
 - never settle emotive disagreements over text, Skype or email. Face
to face first, phone call second
 - ALWAYS remember to turn off your camera when Skyping in your
pyjamas, particularly if you don't wear them. Yep, enough said.
 - be prepared for the blues and have a strategy to challenge them
 - isolation breeds paranoia and cliques will form around those you can see

Working from home is the best thing, until it isn't, and then it is
the worst thing. As ever, avoiding the pitfalls is much better than
curing them. It can be the most amazing and productive experience, but
it does require discipline :-).

On 17 July 2016 at 23:22, Alan Thompson  wrote:
> http://jakemccrary.com/blog/2016/06/14/tips-for-working-from-home/
>
> Having worked remotely most of the past two years, I think this blog post is
> a good summary and has some important points.
>
> Cheers,
> Alan
>
> --
> 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 Spec, performance and workflows

[Colin Yates]

Just dipping in to say the pragmatism and maturity around here is
hugely attractive compared to other tech communities. +1.

In terms of reducing the impact of a change, I have found ruthlessly
separating out into separate libraries very beneficial here. lein's
'checkout' capability makes it not much more effort than single
monolithic codebase. I am not talking about deployment models, I am
talking about source-code modules.

On 15 July 2016 at 15:50, Rich Hickey  wrote:
> Thanks for your feedback. I've been anticipating this discussion, and my 
> response here is directed to everyone, not just your problem.
>
> Using specs and instrument+generative testing is much different than the 
> example-based testing that has happened thus far, and should deliver 
> substantially greater benefits. But the (test-time) performance profile of 
> such an approach is similarly different, and will require a different 
> approach as well.
>
> Let's deal with the simplest issue - the raw perf of spec validation today. 
> spec has not yet been perf-tuned, and it's quite frustrating to see e.g. 
> shoot-out tables comparing perf vs other libs. If people want to see code 
> being developed (and not just dropped in their laps) then they have to be 
> patient and understand the 'make it right, then make it fast' approach that 
> is being followed. I see no reason spec's validation perf should end up being 
> much different than any other validation perf. But it is not there yet.
>
> That being said, even after we perf-tune spec, comparing running a test suite 
> with instrumented code (and yes, that is a good idea) with the same test 
> suite without (which as people will find, has been missing bugs) is apples vs 
> oranges.
>
> Add in switching to (or adding) generative testing, which is definitely 
> always going to be much more computationally intensive than example based 
> tests (just by the numbers, each generative test is ~100 tests), there is no 
> way that test-everything-every-time is going to be sustainable.
>
> Should we not use generative testing because we can't run every test each 
> time we save a file?
>
> We have to look at the true nature of the problem. E.g., each time you save a 
> file, do you run the test suites of every library upon which you depend? Of 
> course not. Why not? *Because you know they haven't changed*. Did you just 
> add a comment to a file - then why are you testing anything? Unfortunately, 
> our testing tools don't have a fraction of the brains of decades-old 'make' 
> when it comes to understanding change and dependency. Instead we have testing 
> tools oriented around files and mutable-state programming where, yeah, 
> potentially changing anything could break any and everything else, so let's 
> test everything any time anything has changed.
>
> This is just another instance of the general set of problems spec (and other 
> work) is targeting - we are suffering from using tools and development 
> approaches (e.g. building, testing, dependency management et al) whose 
> granularity is a mismatch from reality. Having fine-grained (function-level) 
> specs provides important opportunities to do better. While tools could (but 
> currently mostly don't) know when particular functions change (vs files), 
> specs can let us independently talk about whether the *interface* to a fn has 
> changed, vs a change to its implementation. Testing could be radically better 
> and more efficient if it leveraged these two things.
>
> I don't like to talk about undelivered things, but I'll just say that these 
> issues were well known and are not a byproduct of spec but a *target* of it 
> (and other work).
>
> Rich
>
> --
> 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 

Re: Avoiding repetition while still using 'recur'

[Colin Yates]

Skimming through but that `case` resolves to either false or a recur
so sure you can move that case to an helper fn which returns true or
false. If false then `return` else `recur`?

On 26 June 2016 at 13:43, Botond Balázs  wrote:
> Hi,
>
> Here is my solution to 4clojure problem #177:
>
>> Write a function that takes in a string and returns truthy if all square [
>> ] round ( ) and curly { } brackets are properly paired and legally nested,
>> or returns falsey otherwise.
>
>
> (defn valid-parens?
>   [s]
>   (loop [[ch & chs] s stack []]
> (if (nil? ch)
>   (empty? stack)
>   (case ch
> (\( \[ \{) (recur chs (conj stack ch))
> \) (if (= (peek stack) \()
>  (recur chs (pop stack))
>  false)
> \] (if (= (peek stack) \[)
>  (recur chs (pop stack))
>  false)
> \} (if (= (peek stack) \{)
>  (recur chs (pop stack))
>  false)
> (recur chs stack)
>
> This works but I don't like the repetition in the case branches. But the
> repeated code contains a recur call so I can't simply refactor it into a
> helper function. How can I achieves something like the following, but
> without consuming the stack?
>
> (defn valid-parens?
>   ([s]
>(valid-parens? s []))
>   ([[ch & chs] stack]
>(if (nil? ch)
>  (empty? stack)
>  (letfn [(match? [p]
>(if (= (peek stack) p)
>  (valid-parens? chs (pop stack))
>  false))]
>(case ch
>  (\( \[ \{) (valid-parens? chs (conj stack ch))
>  \) (match? \()
>  \] (match? \[)
>  \} (match? \{)
>  (valid-parens? chs stack))
>
> Thanks!
> Botond
>
> --
> 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: Joy of Clojure : Backward running lisp ??

[Colin Yates]

Gary - that was great to read. Thanks ;-)

On 23 June 2016 at 08:18, Gary Verhaegen  wrote:
> In functional programming, you work with functions. Functions have a
> well-defined list of inputs and a single output. So you can say of the
> function cons, for example, that it takes as input a value and a list,
> and yields as output a new list with the value prepended to the given
> list; for example (cons 1 '(3 4)) would yield the value '(1 3 4).
>
> In logic (sometimes called relational) programming, you work with
> relations. A relation defines some link between multiple values. The
> equivalent example to the above, usually denoted "conso" in the
> Clojure world (and something like cons° in miniKanren, I think) would
> be a relation of three values: (conso a b c). The more mathematical
> interpretation would be "conso is true for any three values a, b, c
> such that c is a list of at least one element, a is the first element
> of c and b is a list of all elements of c except the first, in the
> same order". In practical terms, a logic engine like miniKanren will
> allow you to supply real values for some of the arguments and let the
> others be free, and will return example values for which the relation
> holds.
>
> For example, (conso 1 '(3 4) c) would return something that says "c
> must be '(3 4)". In this case, by analogy to the functional version,
> we say we are running the relation "forward", i.e. in the same
> direction as the function. But you can also ask a logic engine for
> "(conso a b '(1 3 4))", and it will reply with something like "a
> should be 1, b should be '(3 4)", and, again, by analogy with the
> functional equivalent, we would say you are running the "function"
> backwards. In terms of relational programming, in either case you're
> just applying the relation, but most people who hear about relational
> programming are more familiar with functions (or procedures) and will
> relate to the notion that the "natural", i.e. "forward" way of running
> conso is to supply the first two arguments and expect the engine to
> supply values for the third, rather than the other way around.
>
> Note that you could also ask a logic engine for "(conso 1 b '(1 3
> 4))", and it should respond with "b should be '(3 4)", which is
> running it middleward, I guess. It's harder to relate to functions
> when you have more than one "input", as logic programming would let
> you specify any subset of them. Relations can also fail, such as if
> you ask for "(conso 1 b '(3 4 5))"; in that case the logic engine,
> depending on the robustness of its own implementation and the
> definition of conso, would either enter an infinite loop trying to
> find a value for which this holds or just respond with "there is no
> value for b that makes this relation hold".
>
> conso is a simple example in that it is bijective. If you instead
> consider a concat function, such that (concat l1 l2), where l1 and l2
> are lists, would yield a new list l3 with first all of the elements of
> l1 then all of the elements of l2, then you can get a more interesting
> equivalent relation ("concato"?).
>
> Let's imagine you define (concato l1 l2 l3) to be true if l3 = (concat
> l1 l2) (you cannot just state it like that to the logic engine). Then,
> if you ask your logic engine about the relation (concato a b '(1 2
> 3)), it would respond with "Here are some possible values for a and b:
> a = '(), b = '(1 2 3); a = '(1), b = '(2 3); a = '(1 2), b = '(3); a =
> '(1 2 3), b = '()".
>
> What Byrd and Friedman have been working on for some time now is the
> (research) question of "can we write a relation that defines a Lisp
> interpreter?", where a Lisp interpreter is thought of as the function
> eval, essentially. So if (eval '(+ 1 2)) would yield 3, can you define
> a relation evalo, within the constraints of their specific logic
> engine ({mini,alpha}Kanren), that mimics that behaviour when run
> "forward" (i.e. given the first argument as a value and the second one
> as a free-floating logic variable) and also works "backwards" (i.e.
> given the first argument as a free-floating variable and the second
> one as a value).
>
> So they would define (evalo a b) such that it is satisfied iff (eval
> a) yields b (though again you cannot tell it that simply to your logic
> engine, hence the research part); this means that for example (evalo
> '(+ 1 2) 3) would be satisfied, (evalo '(+ 1 2) 4) would not be
> satisfied, (evalo '(+ 1 2) a) would return something like "this can be
> satisfied if a = 3" (forward), and (evalo a 3) (i.e. "backward with
> respect to the equivalent function) would return something along the
> lines of "There are a bunch of programs that can evaluate to 3. Here
> are a few of them: '(+ 0 3), '(+ 1 2), '(+ 2 1), '(- 4 1), '((fn []
> 3)), ..."
>
> Their last question is a bit tricky: what program, when evaluated,
> yields itself? This is the notion of a quine, and quines are pretty
> hard to generate 

Re: Clojars will be partially down for maintenance this weekend

[Colin Yates]

+1 - one of the unsung heroes.

On 18 June 2016 at 20:50, Andrey Antukh  wrote:
> Completely agree! Many thanks for your work!
>
> On Sat, Jun 18, 2016 at 10:49 PM, Howard Lewis Ship 
> wrote:
>>
>> It unfortunately goes unsaid, so I'll say it: thanks for working hard on
>> Clojars, and for doing a great job on communicating important status, such
>> as this downtime, to a community that is so reliant on your efforts.
>>
>> On Sun, Jun 12, 2016 at 6:07 PM, Toby Crawley  wrote:
>>>
>>> Clojars is back up; we ran in to an issue with the update, so had to
>>> roll it back. Once we fix the issue, we'll schedule another
>>> maintenance window.
>>>
>>> Please file an issue[1] if you experience any problems.
>>>
>>> - Toby
>>>
>>> [1]: https://github.com/clojars/clojars-web/issues
>>>
>>> On Fri, Jun 10, 2016 at 4:01 PM, Toby Crawley  wrote:
>>> > At 2016-06-13 00:00:00 UTC[1], we'll be taking down the Clojars web
>>> > interface to do database maintenance and deploy some
>>> > features/fixes. The biggest change in this deploy will be the
>>> > introduction of sending a copy of deployed artifacts to Rackspace
>>> > CloudFiles to allow us to serve the repository from a more robust
>>> > location in the near future.
>>> >
>>> > We've scheduled an hour for the work, but it should take less. During
>>> > that time, the web interface, search api, and ability to deploy will
>>> > be unavailable, but the repository will still be readable, so projects
>>> > will still be able to build.
>>> >
>>> > To see the status of the work, watch our status page[2] or follow
>>> > @clojars on twitter[3].
>>> >
>>> > [1]: for your local time, see
>>> > https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160613T00
>>> > [2]: http://status.clojars.org
>>> > [3]: https://twitter.com/clojars
>>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Senior Mobile Developer at Walmart Labs
>>
>> Creator of Apache Tapestry
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
>> --
>> 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.
>
>
>
>
> --
> Andrey Antukh - Андрей Антух - 
> http://www.niwi.nz
> https://github.com/niwinz
>
> --
> 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 

Re: When/how are top-level side effects in a namespace executed?

[Colin Yates]

Others will have more idea, but my observation is that it is evaluated
once, so a namespace which is required by multiple namespaces will only
be evaluated once. Should you explicitly re-evaluate it then it will of
course be evaluated again.

You might be interested in reading Stuart Sierra's 'reloaded workflow'
and using the resultant Component library which has some input on this.

The other machinery you might want to look at is defonce, which does
exactly what it says :-).

To give you peace of mind you could experiment with:

(ns a)
(def m (atom 0))
(swap! m inc)

(ns b
 (:requires [a]))

(ns c
 (:requires [a]))

And then load 'a' and 'b'. My expectation is that a/m will be 1

As I say, this is from observation rather than inspecting the underlying
machinery.

HTH.

lvh writes:

> Hi,
>
>
> Suppose I have a namespace that has some ns-level side effect, e.g. `(def 
> atom {})`.
>
> 1. When is that executed? How often? (I think, from observation, that the 
> answer is “when it is first required”, and “exactly once”; but it’s important 
> for the correctness of my program that this is the case.)
> 2. Is there a mutex preventing multiple threads from attempting that at the 
> same time? If so, is that an accident, or a language guarantee?
>
> I don’t know if it matters, but in this case the side effect will be a method 
> call on a jnr-ffi binding, so internally it will go off and synchronously 
> initialize a C library. It’s fine if it gets called multiple times, but only 
> if it has been executed by exactly 1 thread first. (It sets some state to 
> signify that it’s initialized; if you call it when it’s already initialized, 
> it just exits. It is _not_ re-entrant.)
>
> If these guarantees don’t hold, is there a convenient/canonical way to 
> execute that side-effect synchronously? I’d like to prevent users of my 
> library to have to remember to call an init fn in their main- if I can.
>
>
> thanks
> lvh

-- 
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: clj-time/do-at not workin as expected

[Colin Yates]

Have you considered using async channels?
JvJ writes:

> Chime seems great, but I'm looking for something cross-platform (java/js).

-- 
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: lein project cross-reference tools

[Colin Yates]

Have you tried the 'find usages' functionality of
https://github.com/clojure-emacs/clj-refactor.el? Also - you might
want to download IntelliJ and give cursive a try - cursive is
fantastic for this sort of stuff

... and yes, I too feel a bit of despair that my suggestions is 'try
this other tool, if that doesn't work, try this entire editor, if that
doesn't work then' :-)

On 19 April 2016 at 19:45, Dave Tenny  wrote:
> Still looking for basic slime-like who-calls in cider.  Is it there and I'm
> just missing it?
>
> On Tue, Apr 19, 2016 at 9:57 AM, Dave Tenny  wrote:
>>
>> Tags aside, a transtive closure who-calls report for a definition would
>> still be appreciated.
>>
>> On Tue, Apr 19, 2016 at 9:53 AM, Dave Tenny  wrote:
>>>
>>> Hmm, okay, trying etags, certainly plenty of google hits there as opposed
>>> to googling "cross reference".  FYI, in terms of emacs compatibility, I
>>> generally use CIDER if anybody has suggestoins for how to search without a
>>> live repl or with a live repl but across projects or uberjars.
>>>
>>> On Tue, Apr 19, 2016 at 9:33 AM, Dave Tenny  wrote:

 Oh, if crossclj DOES do what I'm asking, please let me know, I found the
 pages I visited a bit confusing as to how I might analyze my (private)
 projects.

 On Tue, Apr 19, 2016 at 9:30 AM, Dave Tenny 
 wrote:
>
> I'm tired of doing 'find-grep' type operations (including that command
> in emacs).
>
> Are there any decent tools for producing cross reference reports and
> emacs who-calls data in some useful form?
>
> A search on the topic mostly points to 'crossclj', which doesn't seem
> to be what I want (I don't need to see who uses what from, say, clojars).
>
> I have a big project which, in conjunction with 'lein modules' has many
> subprojects.  I can't really load a REPL on all of them in emacs.  I'm 
> happy
> with source code analysis and the assumption that I don't need to know who
> is calling functions by obscured dynamic lisp means.
>
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ejNMVjyjp-Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


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

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

Re: Return from a function

[Colin Yates]

Hi Varun - the best advice I think I could give you is to spend a
whole bunch of time on https://clojuredocs.org and https://www.conj.io
(any others?) familiarising yourself with the core API. There is also
the official http://clojure.org/api/api but I find the example on
clojuredocs invaluable.

For me, my first few months was spent writing a whole bunch of
unidiomatic and ugly code badly replicating what was already in the
core libs. In fact, there was a bit of a bad smell of writing lots of
Clojure code as the core lib provides a _lot_ more than you might
think (I came from Java).

Also, you might want to invest in either core.typed or prismatic
schema for validating shapes of data. I think Brian Marick of Midje
fame has a similar answer but I can't recall the name.

Oh, and this community is great - keep asking questions and someone
will answer :-) - are you on slack?

On 15 April 2016 at 03:42, Varun Kamra  wrote:
> Oh, I didn't even know we could loop using dotimes. Thanks for the
> explanation and for the code as well.
>
>
> On Thursday, April 14, 2016 at 6:58:57 PM UTC-7, Bobby Eickhoff wrote:
>>
>> The result of the last expression evaluated is always returned.  Hence,
>> the shape of the function is what determines the points of return and the
>> returned values.  For example,  if you're entire function is defined as one
>> (if ...) statement, there are two possible points of return, each of the
>> branches.
>>
>> But I think you're probably asking if you can return early from a
>> function, like in Java or Javascript.  No, there's no return "statement" in
>> Clojure.  You just have to structure your functions a certain way.
>>
>> Here's an alternate version of your pyramid function which uses (recur
>> ...).  This is equivalent to calling pyramid recursively, but the compiler
>> is able to optimize this recursive call away.  In other words, it will never
>> overflow the stack.
>>
>> (defn pyramid [n]
>>   (when (pos? n)
>> (dotimes [_ n]
>>   (print "* "))
>> (println)
>> (recur (dec n
>>
>>
>>
>>
>> On Thursday, April 14, 2016 at 9:23:58 PM UTC-4, Varun Kamra wrote:
>>>
>>> On Thursday, April 14, 2016 at 5:58:33 PM UTC-7, Varun Kamra wrote:
>>> > Hey guys I am new to clojure. I was just experimenting by printing a
>>> > pyramid of stars 5 rows and 5 column. Here's the code:
>>> >
>>> > (defn pyramid [j i]
>>> > (if (and (= i 0) (neg?
>>> > (println "There's your pyramid"))
>>> > (if (= j 0)
>>> > (do (println)
>>> > (pyramid (- i 1) (- i 1)))
>>> > (do (print "* ")
>>> > (pyramid (- j 1) i
>>> >
>>> > It's working fine till it prints the pyramid, but after printing it, it
>>> > continues printing a lot of stars and eventually fail with stack 
>>> > overflow. I
>>> > am guessing that a if I put a negative check I can prevent it but I wanted
>>> > to know if there's a way to return from the recursive call instead.
>>>
>>> I understood now, it was going in the else condition of the if so here'so
>>> the modified code
>>>
>>> (defn pyramid [j i]
>>> (if (= i 0)
>>> (println "There's your pyramid"))
>>> (if (= j 0)
>>> (do (println)
>>> (pyramid (- i 1) (- i 1
>>> (if (not (neg? j))
>>> (do (print "* ")
>>> (pyramid (- j 1) i
>>>
>>> But my question still stands if ther's a way to return from function.
>
> --
> 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: [ANN] clojure.java.jdbc 0.5.6 -- important deprecations!

[Colin Yates]

That's great Sean - I look forward to 'lein ancient'ing tomorrow :-).

On 10 April 2016 at 18:42, Sean Corfield  wrote:
> What?
> org.clojure/java.jdbc “0.5.6”
> Clojure contrib wrapper for JDBC database operations
>
> Where?
> https://github.com/clojure/java.jdbc#change-log
>
> TL;DR:
> Variadic calls to most functions have been deprecated in favor of 
> fixed argument calls in order to make the functions more composable in use. 
> This affects any calls that provided options, as well as any `insert!` that 
> inserted multiple rows!
>
> Why?
> In the previous versions (0.5.0 and earlier), options to most 
> functions were specified as inline unrolled keyword/value arguments:
>
> (jdbc/query db [“select * from foo where id = ?” pk]
>  :row-fn :name :result-set-fn first :identifiers identity)
>
> Whilst this style of argument is convenient from the REPL, it becomes 
> increasingly awkward as you start composing functions – you start having to 
> use `apply` and `mapcat identity` and so on.
>
> Version 0.5.5 introduced a single options map argument into (nearly) 
> all functions that previously took unrolled keyword/value arguments. It is 
> the optional, last argument in all cases.
>
> (jdbc/query db [“select * from foo where id = ?” pk]
>  {:row-fn :name :result-set-fn first :identifiers 
> identity})
>
> Version 0.5.6 extends this to `create-table-ddl` and `insert!`. It 
> also introduces `insert-multi!` and deprecates the multi-row capability of 
> `insert!` -- the variadic call:
>
> ;; deprecated
> (jdbc/insert! db {:row “1” :data “first”} {:row “2” :data “second”})
>   (jdbc/insert! db [:row :data] [“3” “third”] [“4” “fourth”])
> ;; use this instead
> (jdbc/insert-multi! db [{:row “1” :data “first”}
>   {:row “2” :data “second”}])
>   (jdbc/insert-multi! db [:row :data]
>  [[“3” “third”]
>   [“4” “fourth”]])
>
>Version 0.5.6 continues to support the unrolled arguments but 
> considers them deprecated – and using them will cause a DEPRECATED message to 
> be printed to stdout (this was already true for `db-transaction` which was 
> deprecated in favor of `with-db-transaction` back in version 0.3.0).
>
> Plans?
> Version 0.6.0 will remove all deprecated functionality (including the 
> old API which continued in java.jdbc.deprecated for several versions).
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>
>
>
>
> --
> 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: [ANN] [book] Mastering Clojure published!

[Colin Yates]

Congratulations! - I know how much effort goes into this sort of
thing. I look forward to reading a copy at some point.

On 3 April 2016 at 05:46, Akhil Wali  wrote:
> I'm pleased to announce that Mastering Clojure has been published.
> This book is a fast paced exploration of the more advanced features of the
> Clojure language.
> It also demonstrates a handful of interesting libraries, such as core.async,
> pulsar, core.logic and cats.
>
> https://www.packtpub.com/application-development/mastering-clojure
> https://github.com/PacktPublishing/Mastering-Clojure
> http://www.amazon.com/Mastering-Clojure-Akhil-Wali/dp/1785889745/
>
> It's been almost a year since I've started working on this book.
> A big thanks to everyone involved!
>
> --
> 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: [ANN] Elements of Clojure

[Colin Yates]

Really enjoyed this Zach - well done.

I have _longed_ to write a book using Clojure as a vehicle but dealing
addressing "how to build great code" and you beat me to it. Luckily, a
gazillion books in this space would still not be sufficient so the
door for my work isn't closed :-).

(and a _huge_ +1 for preferring 'Indirection' over 'Abstraction')


On 17 March 2016 at 17:47, Zach Tellman  wrote:
> I'm writing a book about Clojure, aimed at people who already know the core
> concepts, and want to use them more effectively.  The first chapter,
> "Names", is complete and can be read for free.  Details can be found at
> http://elementsofclojure.com/.
>
> I'm happy to answer any questions here, or on the book's mailing list at
> https://groups.google.com/forum/#!forum/elements-of-clojure.
>
> --
> 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 project template containing clj, cljs cljc files

[Colin Yates]

Not sure about now (as it has been a while since I used it but yes, I
always find `lein ancient` a good first step :-).

On 6 March 2016 at 09:32, Robert Levy <r.p.l...@gmail.com> wrote:
> Reagent-template may have improved recently, but the last time I checked,
> about 5-6 months ago, I found it to be seriously misleading and outdated in
> a number of ways in its opinions on the state of the art for clojurescript
> tooling.  The template I found to be the best was the figwheel template.
>
> On Sun, Mar 6, 2016 at 1:14 AM, Colin Yates <colin.ya...@gmail.com> wrote:
>>
>> Hi Sunil, I always use
>> https://github.com/reagent-project/reagent-template. Not sure it
>> creates cljc out of the box but all you need to do is create a new
>> directory for your .cljc files and add that to the project
>> source-path.
>>
>> On 6 March 2016 at 05:25, Sunil S Nandihalli <sunil.nandiha...@gmail.com>
>> wrote:
>> > Hi everybody,
>> >  I am trying to port an old project which uses cljx plugin and reagent
>> > to
>> > use cljc and reader-conditionals. I was wondering if somebody can share
>> > a
>> > simple template which has clj, cljs and cljc files in it?
>> >
>> > Thanks and regards,
>> > Sunil.
>> >
>> > --
>> > 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.

-- 
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 project template containing clj, cljs cljc files

[Colin Yates]

Quite right - they don't need to live under their own directory. Other
than for libraries however, I do find the /clj, /cljc, /cljs structure
quite pleasing and clean.

On 6 March 2016 at 09:17, Torsten Uhlmann  wrote:
> Hi,
>
> I'm using a Chestnut based template in my project and it was quiet easy to
> add cljc support. I never used cljx bevor so I didn't know how hard or easy
> it would be.
>
> I read that cljc files do not have to live in their own source path but can
> hang around the other files. For my setup I choose to put them into a
> separate folder anyway. To add that I added it to the global :source-paths
> in my project.clj:
>
> :source-paths ["src/clj" "src/cljs" "src/cljc" "dev"]
>
> Then I added it to the :source-path of cljsbuild and uberjar. Here's the
> uberjar definition as an example, which also contains one cljsbuild conf:
>
> :uberjar {:source-paths ^:replace ["src/clj" "src/cljc"]
>   :hooks [leiningen.cljsbuild leiningen.sass
> minify-assets.plugin/hooks]
>   :env {:production true}
>   :aot :all
>   :omit-source true
>   :cljsbuild {:jar true
>   :builds {:app
> {:source-paths ^:replace ["src/cljs"
> "src/cljc"]
>  :compiler {
> :optimizations :advanced
> :pretty-print false}})
>
>
> Hope that helps,
> Torsten.
>
> Sunil S Nandihalli  schrieb am So., 6. März 2016
> um 06:25 Uhr:
>>
>> Hi everybody,
>>  I am trying to port an old project which uses cljx plugin and reagent to
>> use cljc and reader-conditionals. I was wondering if somebody can share a
>> simple template which has clj, cljs and cljc files in it?
>>
>> Thanks and regards,
>> Sunil.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: a project template containing clj, cljs cljc files

[Colin Yates]

Hi Sunil, I always use
https://github.com/reagent-project/reagent-template. Not sure it
creates cljc out of the box but all you need to do is create a new
directory for your .cljc files and add that to the project
source-path.

On 6 March 2016 at 05:25, Sunil S Nandihalli  wrote:
> Hi everybody,
>  I am trying to port an old project which uses cljx plugin and reagent to
> use cljc and reader-conditionals. I was wondering if somebody can share a
> simple template which has clj, cljs and cljc files in it?
>
> Thanks and regards,
> Sunil.
>
> --
> 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: [ANN] Doubling down on Onyx

[Colin Yates]

Congrats Michael - Onyx is a thing of beauty :-).

On 24 February 2016 at 16:22, Michael Drogalis  wrote:
> Hi everyone,
>
> I'm happy to announce that, starting next week, I'll be supporting the Onyx
> Platform full time.
> I want to thank the incredible Clojure community that's helped to make Onyx
> a
> successful open source project. Read on in the blog post for specifics, but
> I wanted to drop
> a message here to say how excited I am to push Clojure forward as a
> distributed systems/data analysis
> front runner.
>
> -- Michael
>
> --
> 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: [ANN] clj-refactor.el and refactor-nrepl 2.0.0 is released

[Colin Yates]

This is great - thanks to all.

On 6 February 2016 at 23:29, woz  wrote:
> The stable release for clj-refactor.el is out together with its nrepl
> middleware backend refactor-nrepl.
>
> clj-refactor.el is an Emacs package for clojure and clojure script
> refactorings while refactor-nrepl is an editor agnostic nrepl middleware
> backend supporting refactoring features in your editor of choice. For a
> state of art demo what you can achieve with clj-refactor and Emacs see
> Magnar's parens of the dead series.
>
> The main areas of improvement for this release are
>
> supporting refactorings for cljc and clojurescript files
> boot support
> find usages (and related features) supporting macros.
> improve discoverability of features via hydra menus and the project wiki.
>
> Apart from these there are a huge number of changes, improvements and
> bugfixes, see full changelog for clj-refactor and refactor-nrepl.
>
> This release is also compatible with the latest cider stable release.
> Unfortunately tho we had to drop support for clojure 1.6 and older.
>
> As for almost all releases Lars Andersen invested a lot of time and energy
> in commits and also in support, also the original creator of clj-refactor
> Magnar Sveen helped create function from example to grow brains for this
> release. Thanks for both of them and all the contributors! Also thanks for
> the maintainers and contributors of the packages we build on, like cider,
> tools.nrepl, tools.analyzer, tools.namespace and others!
>
> As always any contribution and/or feedback is welcome. We are available on
> gitter and usually hang out on clojurian slack #cider channel too.
>
> Enjoy!
>
> --
> Benedek Fazekas
>
> --
> 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: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Colin Yates]

I think the message is 'data doesn't have to be code' not 'code should
be expressed in data' which is significantly different. XML went wrong
because people tried to write code in XML.

Nobody (I think) is saying explicitly that we should write code, logic
etc. as data only that there is no need to wrap data in code.

Of course, Clojure's/Lisps homoiconicity means the _expression_ of
code is the same _expression_ as data so code can be treated as data.

In concrete terms, sure, XML (and YAML etc.) all tried to capture
logic which failed, that isn't what is being recommended in Clojure.

(if (some-pred? a) (do-this a) (do-that a))
is code that can be treated as data. Where it would go horribly wrong
is if you started trying to impose a DSL on top of this:
{:predicate #(some-pred? a) :predicate-match #(do-this a)
:predicate-fail #(do-that a)}
which is analogous (I think) to where XML etc. went down the rabbit hole.

On 2 February 2016 at 10:05, Mikera  wrote:
> I share the same unease. I haven't quite fully been able to articulate all
> the reasons, but here are the things that concern me most:
>
> 1) Completing the API for data access with the representation
>
> This is my biggest issue. Good practice IMHO is to keep APIs abstracted from
> underlying implementation details. There are many cases where you may want
> to change the underlying data representation without changing the API
> (adding indexing functionality, changing a "stored" value to a "calculated"
> value, caching of repeated values etc.) It is *really* annoying when you
> want to change the internal representation but have the problem of breaking
> all the callers who have hard-coded assumptions about the structure.
>
> 2) Refactoring challenges
>
> It's pretty easy to refactor Java code with modern IDEs - changing method
> names, updating all references etc. Doing this in Clojure when everything is
> represented in nested data structures is a tricky task, because you
> typically don't have the ability to catch all uses of a particular part of a
> data structure. I've lost count of the number of times I have had
> hard-to-track bugs because of changed keywords etc.
>
> This is less of an issue in small projects, but a much bigger issue once you
> have a large project that passed complex values between subsystems.
>
> Furthermore, given that Clojure is a dynamically typed language, you
> typically have more tests to compensate for the lack of type safety being
> enforced by the compiler. Refactoring costs become even greater when you
> need to refactor a large number of tests as well.
>
> 3) Performance
>
> If you express everything in nested data structures, you end up paying
> significant performance overheads
> a) Lack of fast type-based dispatch (you can use defrecord / protocols, but
> then you are going the way of typed records anyway... so it isn't really
> pure data)
> b) Validation at runtime of deeply nested structures is expensive. You often
> have to walk the entire tree to ensure compliance with a specific schema
> c) Inherent overheads of boxing numbers. Less of a big deal for business
> domain objects, but problematic for the data scientists among us.
> d) If your data structure represents "operations" you effectively need to
> write an "interpreter" to execute these. I'd rather have fast compiled code
> :-)
> e) The JVM is very good at optimising method calls / object access access
> when it knows the types. With everything as "Object"... less so. You end up
> with lots of casts and instance checks.
>
> Don't get me wrong, I think that immutable data as values are a great thing
> overall. But I would urge caution about an ideological crusade to "data all
> the things".
>
>
> On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>>
>> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
>> Distributed Computing for Clojure”, I'm distracted by a nagging worry that
>> we —as a community— are somehow falling into the same trap as the those
>> advocating XML in the early 2000s. That said, it's a very vague unease,
>> because I don’t know much about why the industry seems to have rejected XML
>> as “bad”; by the time I started programming professionally there was already
>> a consensus that XML sucked, and that libraries/frameworks that relied
>> heavily on XML configuration files were to be regarded with suspicion and/or
>> distaste.
>>
>> So, am I incorrect in seeing a similarity between the “data > code”
>> mentality and the rise of XML? Or, assuming there is a legitimate parallel,
>> is it perhaps unnecessary to be alarmed? Does the tendency to use edn
>> instead of XML sidestep everything that went wrong in the 2000s? Or is it
>> the case that the widespread backlash against XML threw a baby out with the
>> bathwater, forgetting the advantages of data over code?
>>
>> Cheers,
>> Josh
>
> --
> You received this message because you are subscribed to the Google
> Groups 

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

[Colin Yates]

I see the same issues/feel the same pain, but I attribute it much more
to dynamic typing than data. Changing the API is always going to be
expensive but without typing we pretty much to do it without tool
support.

Even in Java and the magic of IDEs there is still pain - changing the
return type of a method from one type to another is still painful -
sure, the IDE will help with the impact analysis but you still have to
work it through.

I think the problem is more exposed as there isn't any indirection
between the thing you want and the getting of the thing you want but
yeah, changing API is hard. Nothing to stop your API being (defn get-a
[m]) if you want that indirection, but that isn't idiomatic.

Performance I can't comment about other than to say for the scale of
projects I am involved with I haven't seen the performance as the
bottleneck.

On 2 February 2016 at 10:05, Mikera  wrote:
> I share the same unease. I haven't quite fully been able to articulate all
> the reasons, but here are the things that concern me most:
>
> 1) Completing the API for data access with the representation
>
> This is my biggest issue. Good practice IMHO is to keep APIs abstracted from
> underlying implementation details. There are many cases where you may want
> to change the underlying data representation without changing the API
> (adding indexing functionality, changing a "stored" value to a "calculated"
> value, caching of repeated values etc.) It is *really* annoying when you
> want to change the internal representation but have the problem of breaking
> all the callers who have hard-coded assumptions about the structure.
>
> 2) Refactoring challenges
>
> It's pretty easy to refactor Java code with modern IDEs - changing method
> names, updating all references etc. Doing this in Clojure when everything is
> represented in nested data structures is a tricky task, because you
> typically don't have the ability to catch all uses of a particular part of a
> data structure. I've lost count of the number of times I have had
> hard-to-track bugs because of changed keywords etc.
>
> This is less of an issue in small projects, but a much bigger issue once you
> have a large project that passed complex values between subsystems.
>
> Furthermore, given that Clojure is a dynamically typed language, you
> typically have more tests to compensate for the lack of type safety being
> enforced by the compiler. Refactoring costs become even greater when you
> need to refactor a large number of tests as well.
>
> 3) Performance
>
> If you express everything in nested data structures, you end up paying
> significant performance overheads
> a) Lack of fast type-based dispatch (you can use defrecord / protocols, but
> then you are going the way of typed records anyway... so it isn't really
> pure data)
> b) Validation at runtime of deeply nested structures is expensive. You often
> have to walk the entire tree to ensure compliance with a specific schema
> c) Inherent overheads of boxing numbers. Less of a big deal for business
> domain objects, but problematic for the data scientists among us.
> d) If your data structure represents "operations" you effectively need to
> write an "interpreter" to execute these. I'd rather have fast compiled code
> :-)
> e) The JVM is very good at optimising method calls / object access access
> when it knows the types. With everything as "Object"... less so. You end up
> with lots of casts and instance checks.
>
> Don't get me wrong, I think that immutable data as values are a great thing
> overall. But I would urge caution about an ideological crusade to "data all
> the things".
>
>
> On Tuesday, 2 February 2016 06:02:23 UTC+8, Josh Tilles wrote:
>>
>> As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx:
>> Distributed Computing for Clojure”, I'm distracted by a nagging worry that
>> we —as a community— are somehow falling into the same trap as the those
>> advocating XML in the early 2000s. That said, it's a very vague unease,
>> because I don’t know much about why the industry seems to have rejected XML
>> as “bad”; by the time I started programming professionally there was already
>> a consensus that XML sucked, and that libraries/frameworks that relied
>> heavily on XML configuration files were to be regarded with suspicion and/or
>> distaste.
>>
>> So, am I incorrect in seeing a similarity between the “data > code”
>> mentality and the rise of XML? Or, assuming there is a legitimate parallel,
>> is it perhaps unnecessary to be alarmed? Does the tendency to use edn
>> instead of XML sidestep everything that went wrong in the 2000s? Or is it
>> the case that the widespread backlash against XML threw a baby out with the
>> bathwater, forgetting the advantages of data over code?
>>
>> Cheers,
>> Josh
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 

Re: Migrating from Java/Spring to Clojure

[Colin Yates]

+1. I also challenge the starting condition that most code will be data
access - that was my assumption (when I migrated from Spring/Hibernate).
It doesn't take much rigour to ensure every side effecting fn
is _only_ concerned with the side effect leaving lots of
non-side-effecting code.

Also, do remember that clojure.jdbc works on plain Clojure maps so you
get half-way there simply by returning the rows to persist.

My advice would be to do the 'Clojure' thing and isolate every
side-effecting code (idiomatically post-fixed with the '!') and see how
it goes.

Although Mikera might have unintentionally put you off it, I would
highly recommend Prismatic Schema from day one :-).

Mikera writes:

> On Monday, 1 February 2016 05:19:17 UTC+8, John Krasnay wrote:
>>
>> Hi all,
>>
>> I'm migrating an application from Java/Spring to Clojure and I'm searching 
>> for a good, functional approach. The app exposes a REST interface using 
>> compojure-api and primarily interacts with a relational database and sends 
>> email.
>>
>> I think most people end up passing their database connection (and other 
>> stateful resources as required) around to non-pure functions that do the 
>> side-effectful work, while trying to push as much business logic into pure 
>> functions possible. My problem with this approach is that most of my app's 
>> functionality is in database interactions, so most of my functionality ends 
>> up being non-pure and difficult to test. For example, to unit test my 
>> functions it seems I'd have to mock my database connection.
>>
>> Instead of this, I'm considering an approach where my functions instead 
>> return a data structure containing a description of the side-effects to be 
>> performed (e.g. "insert these rows into this table", "send this email", 
>> ...), and having a single non-pure function that does all the 
>> side-effectful work described by the structure.
>>
>> From what I've read, it seems is sort of how Haskell does IO in a pure 
>> functional manner, using their IO monad.
>>
>> Has anyone tried this sort of approach? Are there any libraries that might 
>> help? Any pitfalls I might be setting myself up for?
>>
>
> I'm sure that you could get this approach to work, but it sets off some 
> alarm bells in my head.
>
> Problems you may face:
>
> a) You are effectively developing a programming language, where your 
> state-affecting code is represented in data. Clojure already does that 
> why reinvent the wheel? I'm reminded of Grrenspun's tenth rule of 
> programming: "Any sufficiently complicated C or Fortran program contains an 
> ad hoc, informally-specified, bug-ridden, slow implementation of half of 
> Common Lisp."
>
> b) Representing operations in code seems neat, but it gets tricky when you 
> have dependencies between them. What if one operation requires conditional 
> execution that depends on the result of a previous operation? You'll need 
> branching and control flow to handle this in a general way, which is 
> non-trivial. What if one set of side effects writes to places that are 
> subsequently "read" by later operations? You'll need to mock or model a 
> database engine if you want to test / simulate this directly.
>
> c) Clojure is an dynamically typed language (sadly, one of it's few 
> flaws) . The lack of compiler support for type verification makes it 
> harder to keep track of exactly the type of data passing through your 
> deeply composed functions and data structures. Trying to represent graphs 
> of operations as data as well is only likely to make things worse. Yes 
> there are tools such as Schema, but they have their own cost in terms of 
> runtime performance (if you use them for validation) and runtime 
> complexity. It's possible to get right, but I would predict quite a lot of 
> pain along the way.
>
> I'd strongly suggest trying this the more conventional Clojure way first 
> (e.g. using Stuart Sierra's component approach). This can get pretty close 
> to being a nice functional style, and is very easy to test (you just need 
> to mock one or two components and you are usually good). You may ultimately 
> find some areas why you want to implement a DSL, but trying to write the 
> whole application in this fashion from the beginning seems to me like a bit 
> of a high risk strategy. 

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

Re: [ANN] New clojure.org!

[Colin Yates]

It’s probably just me but I always think tech companies that don’t do SSL 
reflects badly on them, like they couldn’t be bothered :-). Can’t really 
justify that prejudice, but anyways, glad this is working now.

(There is also 
http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446).

> On 26 Jan 2016, at 03:52, Alex Miller  wrote:
> 
> You can now access https://clojure.org, thanks for the push.
> 
> On Thursday, January 14, 2016 at 2:25:42 PM UTC-6, Alex Miller wrote:
> Noted, I will bump it up the priority list.
> 
> On Thursday, January 14, 2016 at 1:49:55 PM UTC-6, Laurens Van Houtven wrote:
> Hi,
> 
>> On Jan 14, 2016, at 12:34 PM, Alex Miller > > wrote:
>> 
>> The clojure.org  has never, and does not now, support 
>> https. It is an entirely static site, so it is not high on my priority list 
>> to work on.
> 
> Sure; but it does respond to HTTPS requests with a bogus cert, instead of 
> simply not supporting HTTPS at all.
> 
> Since it’s HTTP, an attacker on a local network can fairly trivially (by 
> which I mean: using off the shelf tools) make that “download Clojure” link 
> point to whatever they want, which is my main concern. 
> 
> I don’t know if this is an option for you, but CloudFlare will give you a 
> fairly hassle-free (and money-free) TLS termination option.
> 
> 
> lvh
> 
> 
> -- 
> 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: [ANN] Clojure 1.8.0 is now available

[Colin Yates]

Congrats to all contributors and testers - looking forward to trying it out.
> On 19 Jan 2016, at 19:54, Alex Miller  wrote:
> 
> Some of the new features for 1.8 are:
> More string functions in clojure.string 
>  
> (portable to ClojureScript): index-of, last-index-of, starts-with?, 
> ends-with?, includes?
> Compiler direct linking 
>  - improves 
> performance and startup time
> Socket server 
>  and 
> socket server REPL - adds the ability to allow remote Clojure REPL connections
> For more information, see the complete list 
>  of all changes 
> since Clojure 1.7 for more details.
> 
> Thanks to all of those who contributed to Clojure 1.8 (first time 
> contributors in bold):
> Alexander Yakushev
> Alex Miller
> Alex Redington
> Alf Kristian Stoyle
> Ambrose Bonnaire-Sergeant
> Andrew Rosa
> Andy Fingerhut
> Andy Sheldon
> Aspasia Beneti
> Blake West
> Bozhidar Batsov
> Daniel Compton
> Erik Assum
> Gary Fredericks
> Ghadi Shayban
> Gordon Syme
> Howard Lewis Ship
> Jean Niklas L'orange
> Jeremy Heiler
> Jonas Enlund
> Jozef Wagner
> Karsten Schmidt
> Kevin Downey
> Mark Simpson
> Michael Blume
> Nahuel Greco
> Nicola Mometto
> Nikita Prokopov
> Nola Stowe
> Ragnar Dahlén
> Ralf Schmitt
> Rich Hickey
> Russ Olsen
> Shogo Ohto
> Steve Miner
> Stuart Halloway
> Timothy Baldridge
> Tsutomu Yano
> Yanxiang Lou
> 
> -- 
> 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: [ANN] New clojure.org!

[Colin Yates]

+1 this is really great.

> On 14 Jan 2016, at 16:07, Stephen Gilardi  wrote:
> 
> +1 great fresh look and process!
> 
>> On Jan 14, 2016, at 11:01 AM, Marc O'Morain  wrote:
>> 
>> Very nice! Good job all.
> 
> -- 
> 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: Naming convention for atoms, refs, etc.?

[Colin Yates]

I know it is dangerous to make sweeping statements, but any solution to “a lot 
of code obscures meaning therefore do X” is often solving the wrong thing - the 
real problem is "a lot of code that obscures meaning” :-).

I hope that doesn’t come across as condescending as I fear...

> On 10 Dec 2015, at 06:02, Mars0i  wrote:
> 
> Another use case, fwiw:
> 
> (def my-atom
>   (let [...
>  
>  ...]
> (atom ...)))
> 
> A special naming convention for (e.g.) atoms makes it clear that what's below 
> the many lines of let bindings (and maybe comment lines, too) is going to 
> produce an atom; you don't have to read down and find the one line that 
> contains '(atom'.
> 
> -- 
> 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: Guidance on modelling listeners

[Colin Yates]

Thanks Jason,

I don’t particularly want dynamic registration; when the ‘world’ is 
instantiated it can now about the observers.

I could do this but it is missing the ‘filter out uninteresting events’ bit. I 
want each observer to declare its interest.

Your ‘middleware pattern’ however is something I would use to do the delegation 
(i.e. the actual glue that pushes to each interested observer) as the world 
itself shouldn’t really care.

Thanks for the thoughts - keep them coming!

> On 7 Dec 2015, at 17:15, Jason Felice <jason.m.fel...@gmail.com> wrote:
> 
> It looks like you want dynamic registration of event handlers, which is not 
> something I've done.  If you *didn't* want that, then this the middleware 
> pattern:
> 
> (defn null-processor
>   [world event]
>   world)
> 
> (defn some-other-middleware
>   [handler]
>   (fn [world event]
>  ...
>  (handler world event)
>  ...
>  ) => world'
> 
> (def processor
>   (-> root-middleware
> some-other-middleware
> ...))
> 
> Each processor can respond to some subset of events and ignore the rest.  In 
> this case I folded "basket" into world.
> 
> I've thought a bit about making data-driven middleware and how to register or 
> deregister, but not come up with a decent solution – mostly because ordering 
> is often important.
> 
> 
> On Mon, Dec 7, 2015 at 6:01 AM, Colin Yates <colin.ya...@gmail.com 
> <mailto:colin.ya...@gmail.com>> wrote:
> Hi all,
> 
> (apologies for the wall of text but I think the context might be useful)
> 
> I am using event sourcing so the world, at any given point in time is simply 
> a `reduce` over those events. Throughout the application different things are 
> interested in different events. 
> 
> A design that is emerging is the notion of a 'world' which knows how to 
> consume the various events and allows other parts of the system to respond to 
> certain states having happened. All of this is in-memory and could be client 
> or server side (yay for .cljc and ClojureScript).
> 
> In concrete terms imagine I have am modelling shopping baskets (again, all in 
> memory). I might be interested in knowing:
>  - whenever a certain item is added to a basket
>  - whenever a basket is cancelled
>  - whenever a complete basket is ordered
> 
> I could of course just filter the event log and pick out those events but I 
> typically want the entire entity _as it was when that event happened_, so the 
> event itself isn't sufficient.
> 
> My question is how best to model the 'I am interested in pre-x and post-y'. 
> In general, it is interesting to know the event, the aggregate root (shopping 
> basket) that event is associated with and the world (both the aggregate root 
> and the world as they were at the time of the event).
> 
> I could have an EventObserver: (defprotocol EventObserver  (observe [this 
> event entity world]) which the world notifies. One part of the system will 
> have one set of EventObservers, another will have a different set of 
> EventObservers. Also, some parts need to know _before_ the event and others 
> _after_ the event.
> 
> I don't want each Observer to have to specify every single event so a 
> protocol defining a pre/post method for each event wouldn't work because 
> (AFAIK) you can't have a default implementation of a protocol and you can't 
> have a partial implementation of a protocol. 
> 
> Where I am at is thinking that the world understands a map of EventObservers, 
> with one key for each pre/post event:
> 
> {:pre-event-one EventObserver :post-event-one EventObserver
>  :pre-event-two EventObserver :post-event-two EventObserver}
> 
> etc.
> 
> and each Observer can register their own map of EventObservers. I can 
> optimise the code by either having the world handle nil EventObserver or 
> having a default fully-populated map of EventObservers which Observers can 
> simple assoc their own handlers onto. 
> 
> Building the world is then trivially (usual disclaimer - hacky 
> stream-of-consciousness code):
> 
> (defn- locate-entity [world entity] ...)
> (defn- update-entity! [world entity] ...)
> 
> (defn- process-event [{:keys [observers world] :as result} event]
>   (let [pre-handler-kw (keyword (str 'pre-' (name (:event-type event
>  post-handler-kw (keyword (str 'post-' (name (:event-type event)))
>  pre-entity (locate-entity world event)
>  new-world (update-entity world entity)
>  post-entity (locate-entity new-world event]
> (do all (for [o observers
>   :let [pre-event-observer (pre-handler-kw o) 
> post-event-observer (post-handler-kw o)]]
>  (when pre-

Re: Naming convention for atoms, refs, etc.?

[Colin Yates]

+1.

I haven’t done an extensive study, but I am sure all of my atoms’s stand out 
from other fns/vars because the name makes it obvious. For example, 
‘shopping-cart’ can _only_ sensibly be state which can only be an atom. 

Having said that, if I had mixed refs and atoms then I might consider splitting 
those, but in general I find it obvious and intuitive when looking through past 
code which are atoms and which are fns/vars.

Might just be me though :-). 

> On 7 Dec 2015, at 08:26, Daniel Kersten  wrote:
> 
> I personally don't like this.
> 
> An atom won't suddenly change value without your knowledge because to get its 
> value, you must use @ or deref (which should be a big warning that, yes, this 
> value might change between calls to deref).
> 
> Adding sigils, in my opinion, adds to the noise and makes it harder to read. 
> I personally find sigils to be a noisy mistake in other languages (perl, php 
> etc) and in my opinion you can get more benefit through a suitable naming 
> convention such as a -state prefix, eg: foo-state
> 
> I think, mainly my dislike for sigils is on variables and not so much on 
> functions as I'm ok with foo? being a predicate and foo! being unsafe in STM. 
> I think that's because they tell you useful meta information about what the 
> function does, but to use a variable, I already have to know what data it's 
> representing in order to call the correct functions on it and annotating it 
> with sigils doesn't help much (unless perhaps you go full blown Hungarian 
> notation, but even that isn't rich enough to adequately describe the nested 
> data structures we use in Clojure - good descriptive variable names are much 
> better at conveying content and purpose).
> 
> I guess it may largely just be personal taste, although I would also take the 
> wider community into account: there's a lot of code out there not using this 
> convention - will that become confusing if you rely on symbols to tell you 
> that a variable is an atom?
> On Mon 7 Dec 2015 at 00:27 Mars0i  > wrote:
> On Sunday, December 6, 2015 at 5:52:02 PM UTC-6, Glen Mailer wrote:
> I saw some sample code that prefixed the atom name with a ! recently, seemed 
> to look sensible to me.
> (swap! !state conj :whatever)
> 
> And so on.
> 
> 
> This idea is conceptually elegant, since the marker, !, is the same as the 
> related function suffix.  
> 
> I worry that having two bangs with a space between them, as in the swap! 
> example above, is a little bit visually confusing.   Also, I wonder whether 
> placing @ next two another non-alphanumeric character is visually confusing 
> or messy.  
> 
> As an experiment, I just started using & as a suffix for variables whose 
> values are atoms.:
> (def state& (atom 1))
> (swap! state& inc)
> @state&
> 
> Using only a suffix character means that you don't have a punctuation 
> character next to @, which I prefer.  
> 
> (I wouldn't want to use ! as the suffix for variables that are not functions, 
> though.  (swap! state! inc) potentially very confusing.  It's not that 
> someone reading it couldn't figure it out, but if I saw that, I'd have to 
> think for a second, and then keep remembering that state! is not a function.)
> 
> It occurred to me that I've seen both & and $ used in some languages to 
> suggest pointer dereferencing, so there's some vague harmony to using one of 
> them as indicators as markers of statefulness.  "Ampersand" sounds vaguely 
> like "atom".  If one wanted to have separate marker characters for atoms, 
> refs, and agents, maybe & is a good choice for atoms.  Not sure it's 
> necessary to have different conventions for these three distinct uses, though.
> 
> -- 
> 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 

Re: Naming convention for atoms, refs, etc.?

[Colin Yates]

Sure - but if I saw a reference (no pun intended) to ‘shopping-cart’ I would 
expect that to be stateful. Fns which take something and return something else 
I tend to name `something->something-else`. In other words, I am unlikely to 
have a var whose name is a lower-case noun that isn’t state. 

It is interesting to me, now I think about it that I have seen a few 
syntactical style guides but no semantic style guides for Clojure. This 
question suggests we need one….


> On 7 Dec 2015, at 09:41, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> 
> On the contrary, I find that when I have something in my app like a 
> shopping-cart, there are usually two flavors of functions.  On the one hand, 
> there will be helper functions that take an immutable shopping-cart and 
> return a new immutable shopping-cart.  But on the other hand, there will also 
> be a few functions that manipulate the actual stateful atom/ref containing 
> the immutable shopping-cart.
> 
> I can see how some sort of convention might be handy to distinguish, at a 
> glance, whether a function takes the immutable or stateful version of 
> shopping-cart by some symbol in the name of the input.
> 
> 
> On Mon, Dec 7, 2015 at 12:37 AM, Colin Yates <colin.ya...@gmail.com 
> <mailto:colin.ya...@gmail.com>> wrote:
> +1.
> 
> I haven’t done an extensive study, but I am sure all of my atoms’s stand out 
> from other fns/vars because the name makes it obvious. For example, 
> ‘shopping-cart’ can _only_ sensibly be state which can only be an atom. 
> 
> Having said that, if I had mixed refs and atoms then I might consider 
> splitting those, but in general I find it obvious and intuitive when looking 
> through past code which are atoms and which are fns/vars.
> 
> Might just be me though :-). 
> 
>> On 7 Dec 2015, at 08:26, Daniel Kersten <dkers...@gmail.com 
>> <mailto:dkers...@gmail.com>> wrote:
>> 
>> I personally don't like this.
>> 
>> An atom won't suddenly change value without your knowledge because to get 
>> its value, you must use @ or deref (which should be a big warning that, yes, 
>> this value might change between calls to deref).
>> 
>> Adding sigils, in my opinion, adds to the noise and makes it harder to read. 
>> I personally find sigils to be a noisy mistake in other languages (perl, php 
>> etc) and in my opinion you can get more benefit through a suitable naming 
>> convention such as a -state prefix, eg: foo-state
>> 
>> I think, mainly my dislike for sigils is on variables and not so much on 
>> functions as I'm ok with foo? being a predicate and foo! being unsafe in 
>> STM. I think that's because they tell you useful meta information about what 
>> the function does, but to use a variable, I already have to know what data 
>> it's representing in order to call the correct functions on it and 
>> annotating it with sigils doesn't help much (unless perhaps you go full 
>> blown Hungarian notation, but even that isn't rich enough to adequately 
>> describe the nested data structures we use in Clojure - good descriptive 
>> variable names are much better at conveying content and purpose).
>> 
>> I guess it may largely just be personal taste, although I would also take 
>> the wider community into account: there's a lot of code out there not using 
>> this convention - will that become confusing if you rely on symbols to tell 
>> you that a variable is an atom?
>> On Mon 7 Dec 2015 at 00:27 Mars0i <marsh...@logical.net 
>> <mailto:marsh...@logical.net>> wrote:
>> On Sunday, December 6, 2015 at 5:52:02 PM UTC-6, Glen Mailer wrote:
>> I saw some sample code that prefixed the atom name with a ! recently, seemed 
>> to look sensible to me.
>> (swap! !state conj :whatever)
>> 
>> And so on.
>> 
>> 
>> This idea is conceptually elegant, since the marker, !, is the same as the 
>> related function suffix.  
>> 
>> I worry that having two bangs with a space between them, as in the swap! 
>> example above, is a little bit visually confusing.   Also, I wonder whether 
>> placing @ next two another non-alphanumeric character is visually confusing 
>> or messy.  
>> 
>> As an experiment, I just started using & as a suffix for variables whose 
>> values are atoms.:
>> (def state& (atom 1))
>> (swap! state& inc)
>> @state&
>> 
>> Using only a suffix character means that you don't have a punctuation 
>> character next to @, which I prefer.  
>> 
>> (I wouldn't want to use ! as the suffix for variables that are not 
>> functions, though.  (swap! state! inc