Re: if nil is true

2017-01-31 Thread Sayth Renshaw 


On Tuesday, 31 January 2017 10:25:31 UTC+11, Leon Grapenthin wrote:
>
> Hi Sayth, welcome to Clojure.
>
> Read like this:
>
> (nil? nil) 
> ;-> true
> Is nil nil? True. 
>
> (true? nil) 
> ;-> false
> Is nil true? False.
>
> Kind regards,
>  Leon.
>
>
Thanks Leon. Yeah it does make sense it just didn't catch me right on first 
blush.

Sayth 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group 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] Gorilla REPL v0.4.0

2017-01-31 Thread John Szakmeister 
It looks like the v0.4.0 and v0.3.6 tags point to the same thing in
the gorilla-repl repo, so the v0.4.0 tag isn't picking up the new
commits.

-John

On Mon, Jan 30, 2017 at 1:58 PM, Jony Hudson  wrote:
> Hi All,
>
>  it's a pleasure to announce a new release of Gorilla REPL :-) For those
> that haven't seen it before, Gorilla REPL is a browser-based notebook
> environment for Clojure that lets you make interactive documents with
> tables, graphs etc.
>
> The most important thing to note about this release is that I didn't do any
> of the work! Ben Bailey has been taking an active role in moving Gorilla
> forward, which is really great as I don't have a lot of time to devote to it
> at the moment. Congrats to Ben for the great work on this release.
>
> This release brings in some features that Ben has developed for use in a
> class he and Lee Spector teach. They allow Gorilla to be used to edit plain
> Clojure files as well as rich Gorilla worksheets. This allows them to use
> Gorilla as the sole environment for working in Clojure, which I'm told makes
> the set-up for the class much easier!
>
> As always you can find everything you need to know at
> http://gorilla-repl.org .
>
>
> Jony
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.

[ANN] Vase: data-driven microservices

2017-01-31 Thread Paul deGrandis 
I'm very pleased to announce the availability of Vase 
 - a library for writing 
declarative, data-driven microservices.
With Vase, HTTP services can be created within minutes, complete with 
database integration and data validation.

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

Full details can be found in the blog post .

Stable versions are currently deployed to the Clojars repository.


Leiningen  dependency information:

 [com.cognitect/vase  "0.9.0"]




Maven  dependency information:


  com.cognitect
  vase
  0.9.0


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


To help you get going, see the "Todo" sample application 
.
- - - - - - 

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

Cheers,
Paul

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

Re: structuring parallel code

2017-01-31 Thread Dragan Djuric 
1) When you work with numerics, you have to take into account that 
numerical operations are typically order(s) of magnitude faster and consume 
much less resources per element than any of those concurrency mechanisms.
2) It is important whether the problem you're working on parallelizable in 
itself. Some algorithms are embarrassingly parallelizable, some are 
inherently sequential. The first step is to find out where your algorithm 
falls in this spectrum, and whether there is a more parallelizable 
algorithm, or any clever trick that could help with your problem.
3) Most of the mechanisms you mention are intended to work with heavier 
objects, not primitive numbers one-by-one. If you want to work with 
millions of numbers in parallel, you either separate them in batches, as 
Alex suggested, or have to go with optimized CPU solutions or GPUs.

On Tuesday, January 31, 2017 at 4:44:06 AM UTC+1, Brian Craft wrote:
>
> I think java locks may be the only good answer. I can't usefully divide 
> the vector, because the distribution of updates is uniform along the length 
> of it.
>
> Perhaps there's a solution with queues, with multiple threads generating 
> potential placements, and a single thread updating the vector and 
> re-queuing any conflicting placements.
>
> On Monday, January 30, 2017 at 7:11:03 PM UTC-8, Alex Miller wrote:
>>
>> One technique is to batch locks at a coarser granularity. You've explored 
>> both ends of the spectrum - 1 lock and N locks. You can also divide the 
>> overall vector into any group of refs between 1 and N.
>>
>> If refs are too heavy, there are several other locking mechanisms on the 
>> JVM. You could try Clojure atoms or Java locks. Atoms can only be used to 
>> protect a single value so you would need a protocol for locking acquisition 
>> to deal with that. For something like that, you'd probably end up using a 
>> mutable data structure like a Java array.
>>
>>

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

Datomic cardinality/many uniqueness

2017-01-31 Thread Dmitry Lipovoi 
Hey everyone,

Im trying to express following requirements in datomic schema: person may
have many emails, but no two persons should share the same email.

What comes to mind at first:

{:db/ident   :person/email
 :db/valueType   :db.type/string
 :db/cardinality :db.cardinality/many
 :db/unique  :db.unique/identity ; or :db.unique/value, not sure what
is better
 }

But documentation [1] states that "only :db.cardinality/one attributes can
be unique". Still this schema is accepted by datomic, and AFAICT works as I
expect.

Could someone clarify why unique is declared to be cardinality/one only?
And what approach better suits to my problem?

Thanks in advance.

[1] http://docs.datomic.com/identity.html#sec-4

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

Re: Datomic cardinality/many uniqueness

2017-01-31 Thread Alex Miller 
You might want to post this 
at https://groups.google.com/forum/#!topic/datomic instead...

On Tuesday, January 31, 2017 at 1:16:02 PM UTC-6, Dmitry Lipovoi wrote:
>
> Hey everyone,
>
> Im trying to express following requirements in datomic schema: person may 
> have many emails, but no two persons should share the same email.
>
> What comes to mind at first:
>
> {:db/ident   :person/email
>  :db/valueType   :db.type/string
>  :db/cardinality :db.cardinality/many
>  :db/unique  :db.unique/identity ; or :db.unique/value, not sure what 
> is better
>  }
>
> But documentation [1] states that "only :db.cardinality/one attributes can 
> be unique". Still this schema is accepted by datomic, and AFAICT works as I 
> expect.
>
> Could someone clarify why unique is declared to be cardinality/one only? 
> And what approach better suits to my problem?
>
> Thanks in advance.
>
> [1] http://docs.datomic.com/identity.html#sec-4
>
>

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