Re: :npm-deps and transitive dependencies

[Lucas Wiener]

I now realise that this question might belong to the ClojureScript group, 
so I'm posting it there as well. Feel free to remove this thread if you 
want.

Den måndag 15 januari 2018 kl. 09:01:55 UTC+1 skrev Lucas Wiener:
>
> Hi,
>
> I have the following clojurescript project dependency setup: X -> Y (X has 
> stated Y in :dependencies). Now, I would like Y to depend on a npm 
> javascript library Z. Following the guides, I added :npm-deps to one of the 
> builds specified in Y. When I build and run Y, everything works fine with 
> the new Z dependency. However, building/running project X now fails since 
> the dependency Z cannot be found. From what I currently know, there are two 
> approaches to get X running again:
>
> 1) Specify Z as an :npm-deps also in the project X builds. This is not 
> very elegant since the union of all dependencies now cascade to the top 
> level projects. Also, this approach would fail when transitive dependencies 
> need different versions of the same dependency.
> 2) Compile Y into a bundle. Then X would depend on the prebuilt bundle of 
> Y (which already includes Z). This is not perfect since it requires an 
> extra processing step in Y, making lein checkouts a bit more troublesome 
> etc. Also, my intuition tells me that this might affect code splitting, 
> compilation optimizations, dead code elimination, etc. in a negative way.
>
> Am I missing something?
>

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

[Thomas Heller]

You can create a deps.cljs in the root of your classpath for Y and declare 
:npm-deps there

;; src/deps.cljs
{:npm-deps {"the-thing" "version"}}

This way the compiler can pick up your npm dependency and install it.

On Monday, January 15, 2018 at 9:01:55 AM UTC+1, Lucas Wiener wrote:
>
> Hi,
>
> I have the following clojurescript project dependency setup: X -> Y (X has 
> stated Y in :dependencies). Now, I would like Y to depend on a npm 
> javascript library Z. Following the guides, I added :npm-deps to one of the 
> builds specified in Y. When I build and run Y, everything works fine with 
> the new Z dependency. However, building/running project X now fails since 
> the dependency Z cannot be found. From what I currently know, there are two 
> approaches to get X running again:
>
> 1) Specify Z as an :npm-deps also in the project X builds. This is not 
> very elegant since the union of all dependencies now cascade to the top 
> level projects. Also, this approach would fail when transitive dependencies 
> need different versions of the same dependency.
> 2) Compile Y into a bundle. Then X would depend on the prebuilt bundle of 
> Y (which already includes Z). This is not perfect since it requires an 
> extra processing step in Y, making lein checkouts a bit more troublesome 
> etc. Also, my intuition tells me that this might affect code splitting, 
> compilation optimizations, dead code elimination, etc. in a negative way.
>
> Am I missing something?
>

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

Question: how to spec optional keyword arguments ?

[Khalid Jebbari]

Hello,

Even after reading carefully the official spec guide and testing in the 
REPL, I'm not sure I'm `spec`'ing correctly a function that accepts 
optional keyword args.

Here's how I do it in a dumb example :

```
(require '[clojure.spec.alpha :as s])

(defn adder [a b & {:keys [c] :or {c 1}}]
   (+ a b c))

(s/def ::a integer?)
(s/def ::b integer?)
(s/def ::c integer?)

(s/fdef adder
  :args (s/cat :a integer? :b integer? (s/? (s/keys* :opt-un 
[::c])))
  :ret string?)
```

Is this correct ?

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

Question: how to spec optional keyword arguments ?

[Alex Miller]

You don’t need the final s/? but otherwise that’s right!

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

[Khalid Jebbari]

Thank you Alex.

It happens that I forgot to name the kwargs part in the s/cat call, so the 
working version should be :

(s/fdef adder
  :args (s/cat :a integer? :b integer? :kwargs (s/keys* :opt-un 
[::c]))
  :ret string?)

I'm asking because I've just discovered something about s/cat + s/or + 
s/keys* (after 1 day and a half of trials).

Before I added the keyword args spec, the specs of my function were like 
this (simplified) :

(s/fdef adder
:args (s/or :version1 (s/cat :a integer? :b integer?)
:version2 (s/cat :a number? :b number?)
:ret integer?))

This version is working just fine, with stest/check etc.

When I added keyword args spec yesterday, I added it like this :

(s/fdef adder
:args (s/cat :normal-args (s/or :version1 (s/cat :a integer? :b 
integer?)
:version2 (s/cat :a float? :b 
float?))
 :kwargs (s/keys* :opt-un [::c]))
:ret number?)

It produced some strange behavior. Under `stest/check`, the arguments 
passed to the function were in a messed up form. The smallest input found 
by stest/check is `:smallest [((1.0 1.0))]` which looks like a sequence 
inside a sequence. When I finally realized that I couldn't "un-factorize" 
the spec of the keyword args and the put it into each s/or branch, it 
worked :

(s/fdef adder
:args (s/or :version1 (s/cat :a integer? :b integer? :kwargs 
(s/keys* :opt-un [::c]))
:version2 (s/cat :a float? :b float? :kwargs (s/keys* 
:opt-un [::c])))
:ret number?)

I realize that nesting s/cat calls can produce nested sequences, but in my 
case it seemed natural at first to factorize the spec of the keyword args 
and express the specificity of the "normal args" separately. It's like 
check couldn't somehow "unroll" the nested s/cat...

My question is: does it make sense ? Should it work and it's a bug ? Is 
there no way to factorize like I tried (I would be fine with this really).

I hope I made my question clear, it took me quite some time to nail it and 
create a reproduction case.

On Tuesday, January 16, 2018 at 1:36:47 PM UTC+1, Alex Miller wrote:
>
> You don’t need the final s/? but otherwise that’s right!

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

[Alex Miller]

There is a known bug with conforming trailing ? parts inside a regex spec - 
sounds like you might be seeing that. 

https://dev.clojure.org/jira/browse/CLJ-2105
 

On Tuesday, January 16, 2018 at 8:07:19 AM UTC-6, Khalid Jebbari wrote:
>
> Thank you Alex.
>
> It happens that I forgot to name the kwargs part in the s/cat call, so the 
> working version should be :
>
> (s/fdef adder
>   :args (s/cat :a integer? :b integer? :kwargs (s/keys* :opt-un 
> [::c]))
>   :ret string?)
>
> I'm asking because I've just discovered something about s/cat + s/or + 
> s/keys* (after 1 day and a half of trials).
>
> Before I added the keyword args spec, the specs of my function were like 
> this (simplified) :
>
> (s/fdef adder
> :args (s/or :version1 (s/cat :a integer? :b integer?)
> :version2 (s/cat :a number? :b number?)
> :ret integer?))
>
> This version is working just fine, with stest/check etc.
>
> When I added keyword args spec yesterday, I added it like this :
>
> (s/fdef adder
> :args (s/cat :normal-args (s/or :version1 (s/cat :a integer? :b 
> integer?)
> :version2 (s/cat :a float? :b 
> float?))
>  :kwargs (s/keys* :opt-un [::c]))
> :ret number?)
>
> It produced some strange behavior. Under `stest/check`, the arguments 
> passed to the function were in a messed up form. The smallest input found 
> by stest/check is `:smallest [((1.0 1.0))]` which looks like a sequence 
> inside a sequence. When I finally realized that I couldn't "un-factorize" 
> the spec of the keyword args and the put it into each s/or branch, it 
> worked :
>
> (s/fdef adder
> :args (s/or :version1 (s/cat :a integer? :b integer? :kwargs 
> (s/keys* :opt-un [::c]))
> :version2 (s/cat :a float? :b float? :kwargs (s/keys* 
> :opt-un [::c])))
> :ret number?)
>
> I realize that nesting s/cat calls can produce nested sequences, but in my 
> case it seemed natural at first to factorize the spec of the keyword args 
> and express the specificity of the "normal args" separately. It's like 
> check couldn't somehow "unroll" the nested s/cat...
>
> My question is: does it make sense ? Should it work and it's a bug ? Is 
> there no way to factorize like I tried (I would be fine with this really).
>
> I hope I made my question clear, it took me quite some time to nail it and 
> create a reproduction case.
>
> On Tuesday, January 16, 2018 at 1:36:47 PM UTC+1, Alex Miller wrote:
>>
>> You don’t need the final s/? but otherwise that’s right!
>
>

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

2nd Call for Participation: BOB 2018 (February 23, Berlin)

[Michael Sperber]

Note that BOB offers cross-registration discounts with :clojureD, which will
be on the very next day - also in Berlin!

==

   BOB 2018
  Conference
 “What happens if we simply use what’s best?”
  February 23, 2018, Berlin
   http://bobkonf.de/2018/
   Program:
http://bobkonf.de/2018/en/program.html
Registration:
 http://bobkonf.de/2018/en/registration.html
   


BOB is the conference for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today. Our
goal is for all participants of BOB to return home with new insights
that enable them to improve their own software development
experiences.

The program features 14 talks and 8 tutorials on current topics:

http://bobkonf.de/2018/en/program.html

The subject range of talks includes functional programming,
verticalization, formal methods, and data analytics.

The tutorials feature introductions to Haskell, Clojure, Livecoding,
terminal programming, Liquid Haskell, functional reactive programming,
and domain-driven design.

Leif Andersen will give the keynote talk.

Registration is open online:

http://bobkonf.de/2018/en/registration.html

NOTE: The early-bird rates expire on January 22, 2018!

BOB cooperates with the :clojured conference on the following
day. There is a registration discount available for participants of
both events.

http://www.clojured.de/

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

[lawrence . krubner]

Stuart Sierra wrote a bit about Functional Design Patters here:

https://www.infoq.com/presentations/Clojure-Design-Patterns

Michael Bevilacqua-Linn wrote "Functional Programming Patterns in Scala and 
Clojure":

https://www.amazon.com/Functional-Programming-Patterns-Scala-Clojure/dp/1937785475/

And I reiterated all the standard arguments about why Lisps don't typically 
have the classical Design Patterns here:

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end




On Wednesday, June 29, 2011 at 11:09:56 PM UTC-4, Sayth Renshaw wrote:
>
>
> Just wanted to put a shout out to Russ Olsen to see what would be 
> needed to get a Russ Olsen book on clojure to happen. I am reading 
> design principles in Ruby and its a great read, I feel I am learning 
> much moe than just Ruby which is why I am reading it. 
>
> I woould absolutely love to read how Russ would apply these design 
> principles to Clojure a more functional language. His books are all 5 
> star reads(amazon ratings) and would greatly enjoy being able to read 
> a Russ Olsen clojure book. 
>
> Is there any way we could help this to happen? Is anyone else 
> interested in such a book? 
>
> 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: Officially support Vert.x

[lawrence . krubner]

James Gatannah,

I apologize for hijacking this thread, but what did you mean here: 

> The one useful thing I could find that Vert.x provides out of the box 
> that clojure doesn't is the pub/sub messaging. That turned our 
> architecture into spaghetti, so I wouldn't call it a win.

Was there something specific about Vert.x that made pub/sub difficult, or 
did you find that pub/sub itself, as a pattern, undermined your 
architecture? I've used pub/sub among small sets of microservices (5 or 6 
services) and it worked well, though I'd be curious to hear from someone 
who tried to use it with hundreds of services. 




On Sunday, December 31, 2017 at 12:47:50 PM UTC-5, James Gatannah wrote:
>
> Disclaimer: I once spent 3-4 weeks studying Vert.x's design philosophy and 
> architecture. So I'm hardly an expert.
>
> On Saturday, December 30, 2017 at 9:31:47 AM UTC-6, Feuer Au wrote:
>>
>> Hmm
>> yes it is almost an absolute requirement since we have already invested a 
>> lot in Java, Kotlin, Javascript and other languages based on Vert.x
>>
>
> I think there's a very important open question here: *what* are you 
> actually using Vert.x for?
>  
>
>> and for Clojure & Haskell are pretty new candidates for us, we need to 
>> find a way to persuade our programmers to use these languages
>>
> and Vert.x is almost the only way to persuade our lovely programmers to 
>> give it a try
>>
>  
>
>> If we dont use Vert.x, those guys may resist to try a new language since 
>> they need to get used to many new softwares e.g. maven -> leiningen
>> some times people may not like changes^_^ 
>>
>
> It's been my experience that, if you have to persuade the programmers to 
> use clojure, they probably aren't going to approach it correctly.
>
> They'll try to write it the same way they'd write java. Then they'll 
> decide that it's awful because the startup time is too slow, the syntax is 
> too weird, and the immutable data structures add a lot of overhead for no 
> real benefit.
>
> Now, if you have someone on the team who's already realized that there are 
> a ton of benefits (like stability in production, much faster development 
> time, fewer bugs, less code to maintain, and general developer happiness 
> all come to mind), then allowing them to show the others the benefits is a 
> great option.
>
> But someone on the team really needs to already  understand that this *is* 
> a better way.
>
>>  
>
>> Now, building on what other people have already written:
>
> If you have a bunch of separate stand-alone microservices that are using 
> vert.x to communicate, there's no reason you couldn't write one in clojure. 
> Just call the Vert.x pieces the way you would any other Java library. I 
> don't know how much effort would be involved in getting it to play nicely 
> with the actual Vert.x ecosystem. It's been a while since I looked at this, 
> but I remember that one of the main selling points was the ability to spin 
> verticles up and down on demand.
>
> That sort of thing really isn't clojure's strength. It's really meant to 
> be part of a process that runs for months or years. You don't have to use 
> it that way, of course, and I bet plenty of others on this list are not. 
> But, if you need something that automatically scales up pretty much 
> instantly when demand increases, then clojure may not be your best bet.
>
> And, if you don't, then why are you using Vert.x?
>
> For me, trying to use Vert.x with clojure was incredibly frustrating. In a 
> lot of ways, it felt like they're trying to solve the same basic problems 
> in two totally different ways. 
>
> One of clojure's main selling points is sane multi-threading. Using that 
> involves fighting the Vert.x ecosystem, which is at least partially based 
> on the premise that multi-threading is sheer evil and should really be 
> avoided. I never really into this, because I barely scratched the surface, 
> and it seemed like a really nasty can of worms to unleash.
>
> As others have said, a huge chunk of what Vert.x provides is already baked 
> into clojure. But the different approaches really aren't compatible. So 
> you'll be fighting either the language or the library on some pretty 
> fundamental decisions.
>
> The one useful thing I could find that Vert.x provides out of the box that 
> clojure doesn't is the pub/sub messaging. That turned our architecture into 
> spaghetti, so I wouldn't call it a win.
>
> Then, yeah, there's the codegen thing which is the part you're really 
> asking about.
>
> Why would anyone use an external codegen tool for a lisp? You already have 
> [arguably] the best codegen tool the world has run across baked into the 
> language, in the form of macros.
>
> If I really had to use Vert.x (and I was working in a polyglot environment 
> where this was an option), I'd just write stand-alone clojure microservices 
> that used Vert.x as a communications library. Then I'd point out how much 
> time/energy is being wasted on the java/kotlin

RE: Russ olsen's Clojure Book

[Sean Corfield]

https://pragprog.com/book/roclojure/getting-clojure -- “This title will be 
available on or about 2018-08-10.”

I’m a bit surprised it wasn’t available under their Beta program…

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


From: clojure@googlegroups.com  on behalf of William 
Swaney 
Sent: Saturday, January 13, 2018 4:53:00 PM
To: Clojure
Subject: Re: Russ olsen's Clojure Book

Any idea when it'll be published? I don't see it at Pragmatic's site yet, nor 
at Amazon.

Bill

On Wednesday, June 29, 2011 at 8:09:56 PM UTC-7, Sayth Renshaw wrote:

Just wanted to put a shout out to Russ Olsen to see what would be
needed to get a Russ Olsen book on clojure to happen. I am reading
design principles in Ruby and its a great read, I feel I am learning
much moe than just Ruby which is why I am reading it.

I woould absolutely love to read how Russ would apply these design
principles to Clojure a more functional language. His books are all 5
star reads(amazon ratings) and would greatly enjoy being able to read
a Russ Olsen clojure book.

Is there any way we could help this to happen? Is anyone else
interested in such a book?

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.

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