Re: [ANN] Leiningen 2.7.0

[Mike Rodriguez]

I'm excited about this :managed-dependencies feature along with it's 
combined usage with lein-parent.  I think this is a feature I really needed 
from Leiningen for quite some time now.


On Wednesday, August 24, 2016 at 7:03:52 PM UTC-5, Jean Niklas L'orange 
wrote:
>
> Greetings, fellow Clojurians!
>
> I am happy to announce Leiningen 2.7.0! This release contains mostly
> bugfixes, but two major new improvements were added. There is now a
> PowerShell version of `lein.bat`, and `:managed-dependencies` has been
> added to Leiningen.
>
> Both improvements should be considered to be in beta, but please try
> them out and report bugs you find in the GitHub issue tracker. The
> rationale for `:managed-dependencies` can be found at [1].
>
> To replace `lein.bat` with the PowerShell equivalent, download
> `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
> you end up with an error related to `Invoke-WebRequest`, then it may
> be a result of an old version of PowerShell, which seems to be
> resolved by installing the Windows Management Framework 4.0 [4].
>
> The full list of significant user changes:
>
> * Add PowerShell script for Windows users. (Brian Lalonde)
> * Run `:prep-tasks` before `lein test`, so generated test namespaces
>   will be tested. (Martin Reck)
> * Better error message when attempting to do `lein run` without
>   `project.clj`. (Eduardo Seabra Silva)
> * Add support for `:managed-dependencies`. (Chris Price)
> * Provide the current clojars certificate. (Toby Crawley)
> * Add `*eval-print-dup*` to evaluate forms passed to
>   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
> * Update bash completions. (Zack Dever)
> * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
> * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
> * Catch and handle fixture errors during `lein test`. (Alex Hall)
> * Fix a bug where spaces in directory names on Windows caused crashes.
>   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
> * Fix a bug where `lein search` would take forever downloading
>   clojars.org. (Paul Dorman)
> * Retain user defined private repositories when building jars,
>   uberjars and deploy. (Rick Moynihan)
> * Honor whitelist settings when `lein javac` is called via `lein jar`.
>   (Chris Price)
> * `lein vsc push` for git will now only push branch-related tags.
>   (Łukasz Klich)
>
> Those who have manually installed Leiningen can run `lein upgrade` to
> pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
> previous version if you run into any issues. Keep in mind that the
> PowerShell script was introduced in this release, hence there are no
> downgrade candidates for it right now.
>
> We have had lots of contributors help out making this release happen,
> and I'd especially like to thank Chris Price (cprice404) and Florian
> Anderiasch (winks) for their help with this release.
>
> [1]: 
> https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
> [2]: 
> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd
> [3]: 
> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1
> [4]: 
> http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx
>
> -- Jean Niklas
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Lym - written by clojurescript and react native is on apple store

[Gary Schiltz]

Thanks for making this free! Any chance you are going to release the source?

On Sunday, August 28, 2016 at 3:28:57 AM UTC-5, Tienson Qin wrote:
>
> Hi everyone, happy to announce Lym  is on apple store 
> now! 
> It's group chat app for learning different cultures, languages, also 
> support 1-on-1 video chat.
>
> Libraries used:
> [[org.clojure/clojure "1.8.0"]
>  [org.clojure/clojurescript "1.9.36"]
>  [org.clojure/core.async "0.2.385"]
>  [com.taoensso/sente "1.10.0-SNAPSHOT"]
>  [com.taoensso/encore  "2.64.1"]
>  [org.clojure/tools.reader "0.10.0"]
>  [com.taoensso/timbre  "4.6.0"]
>  [reagent "0.6.0-SNAPSHOT" :exclusions [cljsjs/react 
> cljsjs/react-dom cljsjs/react-dom-server]]
>  [re-frame "0.7.0"]
>  [prismatic/schema "1.0.4"]
>  [com.andrewmcveigh/cljs-time "0.4.0"]]
>
> Thanks for the community, especially David Nolen, Mike Fikes, and 
> decker405.
>

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

[ANN] data.xml 0.1.0-beta2

[Ryan Senior]

data.xml is a Clojure contrib library that parses and emits XML.

Github: https://github.com/clojure/data.xml
Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md

Information on updating the dependency is here
.

0.1.0-beta2 fixes some bugs found in the new namespaces feature of
0.1.0-beta1 and adds support for doctypes.

Thanks to Herwig Hochleitner and Christian Egli for their contributions!

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

Re: Protocols for persistence - not sure about a few cases

[Shantanu Kumar]

Considering the regular use-cases with records:

Create - requires record without any auto-generated identifiers
Retrieve - requires primary identifier or lookup parameters
Update - requires record with primary identifier and updated fields
Delete - requires primary identifier or lookup parameters

Retrieve and Delete and quite similar, except that `Retrieve` returns 
record(s). Create and Update are similar, except that `Update` requires 
only the updated fields. It is clear that one record type cannot expose all 
of the CRUD operations. Could it be possible that protocols/records are a 
wrong axis to think about this problem?

Can you share some details about the type of database and the access use 
cases you are considering?


Shantanu

On Sunday, 28 August 2016 19:59:46 UTC+5:30, Jonathon McKitrick wrote:
>
> I'm beginning a foray into protocols after coming from the Common Lisp 
> world of multimethods. I'm using them initially to implement a consistent 
> load/save API over the DB layer.
>
> It's pretty simple to have a Saveable protocol to save one object, because 
> the first argument is a Record of the type I am saving.
>
> But since protocols dispatch on the first argument, how do you define a 
> Loadable protocol that loads an object or handles a collection of objects?
>
> For example, if I want to load an object by idx, the first argument is not 
> a Record, but an integer, or perhaps an arbitrary field to used in a query.
>
>
>

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

Protocols for persistence - not sure about a few cases

[Jonathon McKitrick]

I'm beginning a foray into protocols after coming from the Common Lisp 
world of multimethods. I'm using them initially to implement a consistent 
load/save API over the DB layer.

It's pretty simple to have a Saveable protocol to save one object, because 
the first argument is a Record of the type I am saving.

But since protocols dispatch on the first argument, how do you define a 
Loadable protocol that loads an object or handles a collection of objects?

For example, if I want to load an object by idx, the first argument is not 
a Record, but an integer, or perhaps an arbitrary field to used in a query.


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

Re: Should the specs defined in clojure.core.specs be used by in other projects?

[Daniel Marjenburgh]

Great!. Thank yo.

On Sunday, 28 August 2016 14:24:37 UTC+2, Alex Miller wrote:
>
> Yes, you can and should leverage the clojure.core.specs.
>
> They may change indiscriminately during alphas but we will start to lock 
> those down more when we move towards final release.
>

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

Should the specs defined in clojure.core.specs be used by in other projects?

[Alex Miller]

Yes, you can and should leverage the clojure.core.specs.

They may change indiscriminately during alphas but we will start to lock those 
down more when we move towards final release.

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

Should the specs defined in clojure.core.specs be used by in other projects?

[Daniel Marjenburgh]

There are a bunch of useful specs in clojure.core.specs that I would like 
to re-use for spec'ing my own functions and macros. (E.g. 
:clojure.core.specs/binding-form)
Are these meant to be used outside of clojure.core? Or will I be inviting 
trouble later down the road when the specs potentially change?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Lym - written by clojurescript and react native is on apple store

[Tienson Qin]

Briefly websocket + webrtc.
For websocket, I'm using sente,
react-native-webrtc for webrtc.

On Sun, Aug 28, 2016 at 5:18 PM 'Adrian A.' via Clojure <
clojure@googlegroups.com> wrote:

> > also support 1-on-1 video chat
> Could you please detail how was this feature implemented?
>
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/UIxmTkhWyp8/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.

Re: Parsing namespaced XML with clojure.data.xml

[Herwig Hochleitner]

2016-08-25 1:53 GMT+02:00 Matching Socks :

> Namespaced XML is inherently value-comparable and unambiguous.  It would
> be shame to give up on that, and disperse the burden throughout every layer
> of library and consumer.
>

That's a very good point. Disregarding concerns for edn syntax for a
moment, the best solution would seem to standardize on qnames, since those
are the jvm-wide canonical mapping. With reader tags, they are almost there
in terms of read/writability, but not quite as convenient as
::alias/keywords

When designing the namespacing support, I discarded the idea to cram uris
into keywords, because of the impedance mismatch. I thank you for bringing
it up again, though, because I overlooked a very important failure case,
when trying to preserve value semantics:

Say, a library chooses not to use keyword mapping for a given xmlns and
instead matches on qname instances, but then somebody within the system
establishes an alias for that xmlns. Said library will then silently get
keywordized data, that it won't recognize anymore. Unfortunately, I don't
know how to catch that with an explicit error either.

So yes, I am open to experimenting with encoding uris into keywords.

Pretty-printing need not be a concern of the XML parsing library.  Everyone
> seems to be interested nowadays in easing the usage of namespaced
> keywords.  Perhaps printing could be improved (globally) to use the
> caller's keyword namespace aliases.
>

Yes, it doesn't feel right to let an easily adaptable concern like
pretty-printing dictate value semantics.

By all means, use an encoding more legible than Base64.  URLEncoder could
> be an example in the way it uses %.  Pick an escape character that's legal
> in Clojure namespace names, but unusual in the best-known namespace URIs.
> Apostrophe?
>

Yes, or maybe map to unicode lookalikes and escape those, should they ever
occur in a ns-uri.
e.g.

/ -> ⧄
: -> ╎

Though, those are not alphanumeric characters, so probably illegal in
keywords.

Any thoughts so far?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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: Lym - written by clojurescript and react native is on apple store

['Adrian A.' via Clojure]

> also support 1-on-1 video chat
Could you please detail how was this feature implemented?

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.

Lym - written by clojurescript and react native is on apple store

[Tienson Qin]

Hi everyone, happy to announce Lym  is on apple store 
now! 
It's group chat app for learning different cultures, languages, also 
support 1-on-1 video chat.

Libraries used:
[[org.clojure/clojure "1.8.0"]
 [org.clojure/clojurescript "1.9.36"]
 [org.clojure/core.async "0.2.385"]
 [com.taoensso/sente "1.10.0-SNAPSHOT"]
 [com.taoensso/encore  "2.64.1"]
 [org.clojure/tools.reader "0.10.0"]
 [com.taoensso/timbre  "4.6.0"]
 [reagent "0.6.0-SNAPSHOT" :exclusions [cljsjs/react 
cljsjs/react-dom cljsjs/react-dom-server]]
 [re-frame "0.7.0"]
 [prismatic/schema "1.0.4"]
 [com.andrewmcveigh/cljs-time "0.4.0"]]

Thanks for the community, especially David Nolen, Mike Fikes, and decker405.

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