Re: [ClojureScript] Boot running on Windows (was: [ANN] modern-cljs - 17th tutorial - REPLing with Enlive

[Mimmo Cosenza]

> And, yes, I am a bit of a masochist for having an Emacs / Leiningen / Clojure 
> environment on Windows XP :)
Lol :-)
Happy new year!
Mimmo
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> 
> 
> From: Sean Corfield 
> Date: Sunday, December 27, 2015 at 12:02 PM
> To: , Clojure Mailing List 
> 
> Subject: Re: [ClojureScript] Re: [ANN] modern-cljs - 17th tutorial - REPLing 
> with Enlive
> 
> Sven Richter wrote on Friday, December 25, 2015 at 1:08 PM:
> Maybe they changed something within the file access code in W10.
> 
> This appears to be the case, yes. The issue on Windows 7 (and earlier — and 
> maybe still on Windows 8?) is one that has caused countless problems for JVM 
> based tooling that I’ve mentioned over the years: holding onto file locks too 
> long and not allowing open files to be deleted.
> 
> Still I want to argue that a lot of business runs on Windows, especially 
> development environments.
> 
> I would say it’s more likely that the sort of businesses that would run 
> Clojure are also more likely to be using Mac or Linux for development work, 
> but I certainly understand your point. I’ve only worked at a couple of 
> companies over my entire 30+ year career that have used Windows for 
> development, and one of those was a very conservative insurance-related 
> business (the only company I’ve ever worked at where the product I was 
> building actually had to run on a desktop computer). The other was Macromedia 
> where the default laptop was Windows but you could opt for a Mac if you 
> wanted (I started with a Toshiba but it quickly fell apart so I opted for a 
> MacBook Pro to replace it) — we targeted *nix servers for everything my team 
> built.
> 
> One of my big complaints about Boot when it first appeared was that Windows 
> was very much a second-class citizen for that project, but now — on Windows 
> 10 at least — Boot is very smooth to install and use on Windows. For a long 
> time, Leiningen also treated Windows as a bit of a second-class citizen (the 
> packaged installer made it much better, since you no longer need a 
> third-party curl/wget installed just to use the Leiningen .bat script).
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.

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

[William la Forge]

I've been looking at lenses and while it looks pretty simple and very 
useful, I had a hard time getting it. So I came up with my own take on 
lenses. https://github.com/laforge49/dewdrop#readme

So perhaps I still do not understand lenses and what I've done is wrong. Or 
perhaps having been through the exercise I'm now getting it and what I've 
done is no simpler than what everyone else has done. Or perhaps I've just 
described things with fewer technical terms.

So I'd appreciate it if you would review this very short document and tell 
me what I don't understand. Or that I've actually done something worthwhile 
with lenses???

Thanks!
Bill

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

[Andrey Antukh]

Hi!

I have read the readme and I don't found a big evidence of something wrong
so, nice work!
Furthermore, do you know about https://github.com/funcool/cats ? It has a
lens and traversable implementation for clj/cljs. You can read the related
documentation here: http://funcool.github.io/cats/latest/#lens .

You can found that lenses, using cats approach, are working just like
transducers (function composition), you do not need any special function
for combine lenses, just use comp. One of the readme examples (from your
repository) that combines two lenses, in cats can be written in this way:

(require '[cats.labs.lens :as l])
(def xy-lens (comp (l/key :x) (l/key :y))
;; Or just use (l/in [:x :y])

(l/focus xy-lens {:x {:y 1}})
;; => 1
(l/over xy-lens inc {:x {:y 1}})
;; => {:x {:y 2}}

Happy new year!
Andrey

On Fri, Jan 1, 2016 at 2:54 PM, William la Forge 
wrote:

> I've been looking at lenses and while it looks pretty simple and very
> useful, I had a hard time getting it. So I came up with my own take on
> lenses. https://github.com/laforge49/dewdrop#readme
>
> So perhaps I still do not understand lenses and what I've done is wrong.
> Or perhaps having been through the exercise I'm now getting it and what
> I've done is no simpler than what everyone else has done. Or perhaps I've
> just described things with fewer technical terms.
>
> So I'd appreciate it if you would review this very short document and tell
> me what I don't understand. Or that I've actually done something worthwhile
> with lenses???
>
> Thanks!
> Bill
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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.

Re: Project structure when using reader conditionals

[Dru Sellers]

I've attempted to catalog my craziness here,
https://blog.eventgonegood.com/2015/12/26/project-structure/

On Thu, Dec 31, 2015 at 2:49 PM, Alan Moore 
wrote:

> +1
>
> On Dec 31, 2015, at 12:20 PM, Frank Castellucci 
> wrote:
>
> Clean... very nice.
>
> On Wednesday, December 30, 2015 at 8:54:24 AM UTC-5, James Reeves wrote:
>>
>> My directory structure looks like:
>>
>> src/foo/client/bar.cljs
>> src/foo/common/bar.cljc
>> src/foo/server/bar.clj
>>
>> So I divide code by purpose, but they're all in the same source directory.
>>
>> - James
>>
>> On 30 December 2015 at 00:56, Alan Moore  wrote:
>>
>>> Yes it would be handy for small projects but IMO larger applications
>>> should be broken up into client and server code. Some might argue for
>>> breaking up client and server into separate projects altogether but that
>>> begs the question about what to do with the .cljc files that are shared
>>> (e.g. put them in shared library(ies)?) Again, this probably depends on
>>> codebase size, granularity of your deployment and other considerations
>>> beyond just the compiler.
>>>
>>> For now I'm sticking with keeping the .cljc files in the src/clj tree.
>>> I'd like to hear what others are doing as well.
>>>
>>> Did you ask this on the clojurians slack channel? It seems a lot of the
>>> more chatty/Q&A traffic for this list has gone over there.
>>>
>>> Alan
>>>
>>>
>>> On Friday, December 25, 2015 at 1:00:58 PM UTC-8, Dru Sellers wrote:

 Is it fair to say that the accepted pattern now (with reader
 conditionals) is to have a single src/ directory and then letting the file
 extension (cljs,clj,cljc) do the heavy lifting rather than having a
 directory for each?

 that would be handy if so.

 -d


 On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote:
>
> When porting a library to reader conditionals, I found that I only
> needed one source directory for all my cljc and .clj files. Cljsbuild just
> picks up the ones it needs and leaves the .clj ones.
>
> So in some cases it may not be necessary to have a clj/, cljs/, and
> cljc/ folder, although in applications this structure might make more
> sense.
> On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen <
> skinn...@gmail.com> wrote:
>
>> No, it doesn't. I update with `lein ancient update :all` and
>> committed without checking if it worked. It's fixed locally :)
>>
>>
>> fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende:
>>
>>> Thanks Robin, that was helpful. I notice that you are using garden
>>> 1.2.6 - that throws a CNF for garden.core and the garden page recommends
>>> not using it - does it work for you?
>>>
>> On 29 May 2015, at 10:49, Robin Heggelund Hansen 
>>> wrote:
>>>
>>> Take a look at my project.clj file.
>>>
>>>
>>> https://github.com/Skinney/oslo-programmene/blob/development/project.clj
>>>
>>> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende:

 In the vein of "there are no stupid questions" :), how does one
 structure a combined clj and cljs project that uses reader 
 conditionals? At
 the moment I am using cljx and have:
  - src/clj for clojure files
  - src/cljs for clojurescript files
  - src/cljx for cljx
  - target/cljx/clj for clojure files compiled (transpiled?) from
 cljx
  - target/cljx/cljs for clojurescript files compiled (transpiled?)
 from clix

 On the source path in cljsbuild for example I have src/cljs and
 /target/cljx/cljs

 To remove cljx and use reader conditionals is it sufficient to:
  - replace src/cljx with src/cljc
  - remove target/cljx from cljsbuild source path
  - add src/cljc to cljsbuild source path
  - add src/cljc to leiningen source path

 Thanks!

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

Re: [ANN] dewdrop 0.1.0 -- lenses made simple(r?)

[Laws]

William, thank you for this. At a cultural level, I feel like the Clojure 
community is often torn between being popular, on the one hand, versus 
answering critics from the Haskell community, on the other hand. The 
strength of Clojure is exactly that it takes inscrutable academic ideas and 
makes them easy (unlike another JVM language with Functional pretensions 
which takes inscrutable academic ideas and makes 
them idiosyncratic academic ideas). 

About this:

"Or perhaps I've just described things with fewer technical terms."

I think that is an important task. Some of the leading members of the 
Clojure community sometimes switch to a mode where they are clearly 
thinking "Now I will answer all the criticism that I will surely get from 
the Haskell crowd" and then they use a ton of academic language, which 
basically asserts "See? We can be just as inscrutable as you Haskell guys!" 
 

But that is not what makes Clojure great. What makes Clojure great is the 
ability to take good ideas (some of them with an academic vintage) and make 
them easy to use. 



 




On Friday, January 1, 2016 at 7:54:54 AM UTC-5, William la Forge wrote:
>
> I've been looking at lenses and while it looks pretty simple and very 
> useful, I had a hard time getting it. So I came up with my own take on 
> lenses. https://github.com/laforge49/dewdrop#readme
>
> So perhaps I still do not understand lenses and what I've done is wrong. 
> Or perhaps having been through the exercise I'm now getting it and what 
> I've done is no simpler than what everyone else has done. Or perhaps I've 
> just described things with fewer technical terms.
>
> So I'd appreciate it if you would review this very short document and tell 
> me what I don't understand. Or that I've actually done something worthwhile 
> with lenses???
>
> Thanks!
> Bill
>

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

Any examples of using core.async offer!

[Laws]

I am looking for examples of some of the newer stuff in core.async. Has 
anyone used offer! in real code? If yes, why and how? Can you post an 
example of the code? 

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

clojars down?

[Bobby Eickhoff]

Is anyone else having trouble connecting to clojars.org?  Firefox can't 
connect: "The connection has timed out".  Neither can lein:

INFO: I/O exception (java.net.NoRouteToHostException) caught when 
processing request to {s}->https://clojars.org:443: No route to host

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

[Mimmo Cosenza]

it’s down here too. 

http://status.linode.com/ 

mimmo

> On 01 Jan 2016, at 19:49, Bobby Eickhoff  wrote:
> 
> Is anyone else having trouble connecting to clojars.org?  Firefox can't 
> connect: "The connection has timed out".  Neither can lein:
> 
> INFO: I/O exception (java.net.NoRouteToHostException) caught when processing 
> request to {s}->https://clojars.org:443: No route to host
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: clojars down?

[Angel Java Lopez]

It's down here... chrome, page not available, from Buenos Aires, Argentina

On Fri, Jan 1, 2016 at 3:51 PM, Mimmo Cosenza 
wrote:

> it’s down here too.
>
> http://status.linode.com/
>
> mimmo
>
> On 01 Jan 2016, at 19:49, Bobby Eickhoff  wrote:
>
> Is anyone else having trouble connecting to clojars.org?  Firefox can't
> connect: "The connection has timed out".  Neither can lein:
>
> INFO: I/O exception (java.net.NoRouteToHostException) caught when
> processing request to {s}->https://clojars.org:443: No route to host
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group 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: clojars down?

[Nicolás Berger]

Clojars is down because of the ongoing DDoS attacks on linode. Please check
http://status.linode.com/ for status on that
El 1 ene. 2016 15:53, "Angel Java Lopez"  escribió:

> It's down here... chrome, page not available, from Buenos Aires, Argentina
>
> On Fri, Jan 1, 2016 at 3:51 PM, Mimmo Cosenza 
> wrote:
>
>> it’s down here too.
>>
>> http://status.linode.com/
>>
>> mimmo
>>
>> On 01 Jan 2016, at 19:49, Bobby Eickhoff  wrote:
>>
>> Is anyone else having trouble connecting to clojars.org?  Firefox can't
>> connect: "The connection has timed out".  Neither can lein:
>>
>> INFO: I/O exception (java.net.NoRouteToHostException) caught when
>> processing request to {s}->https://clojars.org:443: No route to host
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group 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: [ANN] dewdrop 0.1.0 -- lenses made simple(r?)

[William la Forge]

Andrey,

This is where I have a problem. Ii could have implemented dewdrop lenses as 
functions that could be composed. But the code would be harder to 
understand and possibly be slower. I just do not see the point.

Implementing dewdrop lenses as records makes it dirt simple for anyone to 
create more kinds of lenses. And the ladd function to create a new record 
with the composed getter and setter functions is pretty clean as well.

Isn't it more important to have code you can analyze easily, and which even 
a novice clojurist like myself can embrace and enhance a whole lot more 
important than being able to say that we can use comp to compose these 
lenses???

I see good engineering as leveraging computer science so the programming 
grunts can make effective use of it. Programming is real grunt work, after 
all. No matter how much you dress it up, we all needs must get our hands 
dirty and put our backs into it.

Bill

On Friday, January 1, 2016 at 9:09:08 AM UTC-5, Andrey Antukh wrote:
>
> Hi!
>
> I have read the readme and I don't found a big evidence of something wrong 
> so, nice work! 
> Furthermore, do you know about https://github.com/funcool/cats ? It has a 
> lens and traversable implementation for clj/cljs. You can read the related 
> documentation here: http://funcool.github.io/cats/latest/#lens . 
>
> You can found that lenses, using cats approach, are working just like 
> transducers (function composition), you do not need any special function 
> for combine lenses, just use comp. One of the readme examples (from your 
> repository) that combines two lenses, in cats can be written in this way:
>
> (require '[cats.labs.lens :as l])
> (def xy-lens (comp (l/key :x) (l/key :y))
> ;; Or just use (l/in [:x :y])
>
> (l/focus xy-lens {:x {:y 1}})
> ;; => 1
> (l/over xy-lens inc {:x {:y 1}})
> ;; => {:x {:y 2}}
>
> Happy new year!
> Andrey
>
> On Fri, Jan 1, 2016 at 2:54 PM, William la Forge  > wrote:
>
>> I've been looking at lenses and while it looks pretty simple and very 
>> useful, I had a hard time getting it. So I came up with my own take on 
>> lenses. https://github.com/laforge49/dewdrop#readme
>>
>> So perhaps I still do not understand lenses and what I've done is wrong. 
>> Or perhaps having been through the exercise I'm now getting it and what 
>> I've done is no simpler than what everyone else has done. Or perhaps I've 
>> just described things with fewer technical terms.
>>
>> So I'd appreciate it if you would review this very short document and 
>> tell me what I don't understand. Or that I've actually done something 
>> worthwhile with lenses???
>>
>> Thanks!
>> Bill
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> 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.

Re: [ANN] dewdrop 0.1.0 -- lenses made simple(r?)

[Andrey Antukh]

On Fri, Jan 1, 2016 at 9:53 PM, William la Forge 
wrote:

> Andrey,
>
> This is where I have a problem. Ii could have implemented dewdrop lenses
> as functions that could be composed. But the code would be harder to
> understand and possibly be slower. I just do not see the point.
>

I agree with your main argument, but I don't know how using records makes
thinks more easy understandable in this concrete case and how using
functions over records will make code slower. Transducers has a performance
improvements over classical transformation compositions, and in this case,
the cats lenses leverage the same technique.


>
> Implementing dewdrop lenses as records makes it dirt simple for anyone to
> create more kinds of lenses. And the ladd function to create a new record
> with the composed getter and setter functions is pretty clean as well.
>

Yes but it implies more api to know, that is not bad but if you limit the
set of new api that one should learn/use, will contribute to more familiar
and easy api. Adding new api also implies more time to understand it and
remember when it should be used.


>
> Isn't it more important to have code you can analyze easily, and which
> even a novice clojurist like myself can embrace and enhance a whole lot
> more important than being able to say that we can use comp to compose these
> lenses???
>

Yes, I agree with you, the code readability is very very important. But
this concrete case I don't found big differences in code readability:

;; dewdrop
(defn key-lens [k]
  (lens.
(fn [d] (get d k))
(fn [d v] (assoc d k v

;; cats
(defn key
  [k]
  (lens
   (fn [s] (get s k))
   (fn [s f] (update s k f

The code is mostly the same...


> I see good engineering as leveraging computer science so the programming
> grunts can make effective use of it. Programming is real grunt work, after
> all. No matter how much you dress it up, we all needs must get our hands
> dirty and put our backs into it.
>

My two cents.
Andrey

>
> Bill
>
> On Friday, January 1, 2016 at 9:09:08 AM UTC-5, Andrey Antukh wrote:
>>
>> Hi!
>>
>> I have read the readme and I don't found a big evidence of something
>> wrong so, nice work!
>> Furthermore, do you know about https://github.com/funcool/cats ? It has
>> a lens and traversable implementation for clj/cljs. You can read the
>> related documentation here: http://funcool.github.io/cats/latest/#lens .
>>
>> You can found that lenses, using cats approach, are working just like
>> transducers (function composition), you do not need any special function
>> for combine lenses, just use comp. One of the readme examples (from your
>> repository) that combines two lenses, in cats can be written in this way:
>>
>> (require '[cats.labs.lens :as l])
>> (def xy-lens (comp (l/key :x) (l/key :y))
>> ;; Or just use (l/in [:x :y])
>>
>> (l/focus xy-lens {:x {:y 1}})
>> ;; => 1
>> (l/over xy-lens inc {:x {:y 1}})
>> ;; => {:x {:y 2}}
>>
>> Happy new year!
>> Andrey
>>
>> On Fri, Jan 1, 2016 at 2:54 PM, William la Forge 
>> wrote:
>>
>>> I've been looking at lenses and while it looks pretty simple and very
>>> useful, I had a hard time getting it. So I came up with my own take on
>>> lenses. https://github.com/laforge49/dewdrop#readme
>>>
>>> So perhaps I still do not understand lenses and what I've done is wrong.
>>> Or perhaps having been through the exercise I'm now getting it and what
>>> I've done is no simpler than what everyone else has done. Or perhaps I've
>>> just described things with fewer technical terms.
>>>
>>> So I'd appreciate it if you would review this very short document and
>>> tell me what I don't understand. Or that I've actually done something
>>> worthwhile with lenses???
>>>
>>> Thanks!
>>> Bill
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> 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/

Re: [ANN] dewdrop 0.1.0 -- lenses made simple(r?)

[William la Forge]

Hi again Andrey!

Not to drag this out, but you seem to have missed my main point, which also 
means that I failed to make it. :-)

Understanding how comp works and seeing the function, lens, for defining a 
cat's lens, it is not at all obvious how a cat's lens works. On the other 
hand, the dewdrop lens constructor simply creates a record. And a quick 
review of the code for dewdrop's ladd shows clearly how dewdrop lenses are 
composed. Dewdrop then allows a developer to leverage ones own intuition. 
So a developer may quickly pick up on how to use cat, but must trust that 
any bugs lie in that developer's own code. Or perhaps take time to learn 
how a cat lens works at 3 AM when the servers are crashing. Not likely, 
I'll grant you. But I prefer not to have to trust in magic when I have a 
choice. Too often such magic has a domain that is a bit different than what 
I was expecting. Not understanding how something works, I usually lack a 
similar understanding as to when I should or should not use it.

Keep in mind also that clojure has a lot more than just functions, and 
composition applies to a lot more things than just functions as well. 
Indeed, my favorite technique is compositions of bags of properties serving 
in place of objects. So learning how to call a method to compose two 
records is hardly a stretch and well worth the price for being able to 
understand what is going on internally.

On Friday, January 1, 2016 at 3:35:29 PM UTC-5, Andrey Antukh wrote:
>
>
>
> On Fri, Jan 1, 2016 at 9:53 PM, William la Forge  > wrote:
>
>> Andrey,
>>
>> This is where I have a problem. Ii could have implemented dewdrop lenses 
>> as functions that could be composed. But the code would be harder to 
>> understand and possibly be slower. I just do not see the point.
>>
>
> I agree with your main argument, but I don't know how using records makes 
> thinks more easy understandable in this concrete case and how using 
> functions over records will make code slower. Transducers has a performance 
> improvements over classical transformation compositions, and in this case, 
> the cats lenses leverage the same technique.
>  
>
>>
>> Implementing dewdrop lenses as records makes it dirt simple for anyone to 
>> create more kinds of lenses. And the ladd function to create a new record 
>> with the composed getter and setter functions is pretty clean as well.
>>
>
> Yes but it implies more api to know, that is not bad but if you limit the 
> set of new api that one should learn/use, will contribute to more familiar 
> and easy api. Adding new api also implies more time to understand it and 
> remember when it should be used.
>  
>
>>
>> Isn't it more important to have code you can analyze easily, and which 
>> even a novice clojurist like myself can embrace and enhance a whole lot 
>> more important than being able to say that we can use comp to compose these 
>> lenses???
>>
>
> Yes, I agree with you, the code readability is very very important. But 
> this concrete case I don't found big differences in code readability:
>
> ;; dewdrop
> (defn key-lens [k]
>   (lens.
> (fn [d] (get d k))
> (fn [d v] (assoc d k v
>
> ;; cats
> (defn key
>   [k]
>   (lens 
>(fn [s] (get s k))
>(fn [s f] (update s k f
>
> The code is mostly the same...
>
>
>> I see good engineering as leveraging computer science so the programming 
>> grunts can make effective use of it. Programming is real grunt work, after 
>> all. No matter how much you dress it up, we all needs must get our hands 
>> dirty and put our backs into it.
>>
>
> My two cents.
> Andrey 
>
>>
>> Bill
>>
>> On Friday, January 1, 2016 at 9:09:08 AM UTC-5, Andrey Antukh wrote:
>>>
>>> Hi!
>>>
>>> I have read the readme and I don't found a big evidence of something 
>>> wrong so, nice work! 
>>> Furthermore, do you know about https://github.com/funcool/cats ? It has 
>>> a lens and traversable implementation for clj/cljs. You can read the 
>>> related documentation here: http://funcool.github.io/cats/latest/#lens 
>>> . 
>>>
>>> You can found that lenses, using cats approach, are working just like 
>>> transducers (function composition), you do not need any special function 
>>> for combine lenses, just use comp. One of the readme examples (from 
>>> your repository) that combines two lenses, in cats can be written in this 
>>> way:
>>>
>>> (require '[cats.labs.lens :as l])
>>> (def xy-lens (comp (l/key :x) (l/key :y))
>>> ;; Or just use (l/in [:x :y])
>>>
>>> (l/focus xy-lens {:x {:y 1}})
>>> ;; => 1
>>> (l/over xy-lens inc {:x {:y 1}})
>>> ;; => {:x {:y 2}}
>>>
>>> Happy new year!
>>> Andrey
>>>
>>> On Fri, Jan 1, 2016 at 2:54 PM, William la Forge  
>>> wrote:
>>>
 I've been looking at lenses and while it looks pretty simple and very 
 useful, I had a hard time getting it. So I came up with my own take on 
 lenses. https://github.com/laforge49/dewdrop#readme

 So perhaps I still do not understand lenses and what I've done is 
 wron

Re: Project structure when using reader conditionals

[Matthew Boston]

I've done it multiple ways:

src/app/foo.clj
src-cljs/app/bar.cljs
src-cljc/app/baz.cljc

AND

src/clj/app/foo.clj
src/cljs/app/bar.cljs
src/cljc/app/baz.cljc

I prefer the latter, probably for ease of navigation in the command line 
and in emacs. But I totally agree that having them all together 
(src/app/...) would be nice. But I prefer to split up my "client", 
"server", and "shared" code. But now, you have me questioning if our notion 
of file paths and directories really are useful when structuring code. I 
recall an early argument for Light Table being against the notion of files 
and directories for structuring code.

On Friday, May 29, 2015 at 3:17:25 AM UTC-6, Colin Yates wrote:
>
> In the vein of "there are no stupid questions" :), how does one structure 
> a combined clj and cljs project that uses reader conditionals? At the 
> moment I am using cljx and have:
>  - src/clj for clojure files
>  - src/cljs for clojurescript files
>  - src/cljx for cljx 
>  - target/cljx/clj for clojure files compiled (transpiled?) from cljx
>  - target/cljx/cljs for clojurescript files compiled (transpiled?) from 
> clix
>
> On the source path in cljsbuild for example I have src/cljs and 
> /target/cljx/cljs
>
> To remove cljx and use reader conditionals is it sufficient to:
>  - replace src/cljx with src/cljc 
>  - remove target/cljx from cljsbuild source path
>  - add src/cljc to cljsbuild source path
>  - add src/cljc to leiningen source path
>
> 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.

Re: clojars down?

[Brad Koch]

Anyone know if there are any mirrors available that we can use in the time 
being?

Our production deploys are broken right now because lein won't be able to 
fetch the dependencies during build.  We can't tolerate the risk of not 
being able to make new deployments for an extended period of time, and a 
mirror we could point to would be the easiest way to get builds working 
again for now.

On Friday, January 1, 2016 at 2:00:40 PM UTC-5, Nicolás Berger wrote:
>
> Clojars is down because of the ongoing DDoS attacks on linode. Please 
> check http://status.linode.com/ for status on that
> El 1 ene. 2016 15:53, "Angel Java Lopez" > 
> escribió:
>
>> It's down here... chrome, page not available, from Buenos Aires, Argentina
>>
>> On Fri, Jan 1, 2016 at 3:51 PM, Mimmo Cosenza > > wrote:
>>
>>> it’s down here too. 
>>>
>>> http://status.linode.com/
>>>
>>> mimmo
>>>
>>> On 01 Jan 2016, at 19:49, Bobby Eickhoff >> > wrote:
>>>
>>> Is anyone else having trouble connecting to clojars.org?  Firefox can't 
>>> connect: "The connection has timed out".  Neither can lein:
>>>
>>> INFO: I/O exception (java.net.NoRouteToHostException) caught when 
>>> processing request to {s}->https://clojars.org:443: No route to host
>>>
>>>
>>> -- 
>>> 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 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 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.

Re: clojars down?

[Kyle Cordes]

On January 1, 2016 at 8:18:27 PM, Brad Koch (bradkoch2...@gmail.com) wrote:

Our production deploys are broken right now because lein won't be able to fetch 
the dependencies during build.  We can't tolerate the risk of not being able to 
make new deployments for an extended period of time, and a mirror we could 
point to would be the easiest way to get builds working again for now.


I don’t have a short term answer, but I think the usual recommendation for “I 
need reliable access to dependency repositories” is to run your own, which can 
proxy to upstreams when they are up. There are various server applications for 
this.  Archiva, Artifactory, Nexus, etc.

I wish the Clojars repository (the web site itself is not a big deal) was 
hosted on something extraordinarily robust for plain file serving, like S3.


-- 
Kyle Cordes
http://kylecordes.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.

Re: clojars down?

[Alex Miller]

I agree with Kyle - I've usually run a company proxy which gives you a lot of 
options (it's good to publish company forks of libs too).

I believe one of the items the Clojars maintainers are working on with their 
new funding is support for mirrors.

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

Reducing the pain of a clojars outage

[Toby Crawley]

Given the recent DDoS-triggered outages at linode (including the one
today that has been the worst yet, currently 10 hours at the time I'm
writing this), I've been giving some more thought to how we can make
future outages less painful for the community.

I have an open issue[1] (but no code yet) to move the repository off
of the server and on to a block store (s3, etc), with the goal there
to make repo reads (which is what we use clojars for 99.9% of the
time) independent of the status of the server. But I'm not sure that
really solves the problem we are seeing today. Currently, we have two
points of failure for repo reads:

(1) the server itself (hosted on linode)
(2) DNS for the clojars.org domain (also hosted on linode)

moving the repo off of the server to a block store still has two
points of failure:

(1) the block store (aws, rackspace, etc)
(2) DNS for the clojars.org domain, since we would CNAME the block
 store (hosted on linode)

Though the block store provider would probably be better distributed,
and have more resources to withstand a DDoS (but do any block store
providers have 100% uptime?).

The block store solution is complex - it introduces more moving parts
into clojars, and requires reworking the way we generate usage stats,
and how the api gets its data. It also requires reworking the way we
administer the repo (deletion requests, cleaning up failed/partial
deploys). And it may not solve the availability problem at all, since
we still have two points of failure.

I think a better solution may be to have multiple mirrors of the repo,
either run by concerned citizens or maintained by the clojars staff. I
know some folks in the community already run internal caching proxies
or rsynced mirrors (and are probably chuckling knowingly at those of
us affected by the outage), but those proxies don't really help those
in the community that don't have that internal infrastructure. And I
don't want to recommend that everyone set up a private mirror - that
seems like a lot of wasted effort.

Ideally, it would be nice if we had a turn-key tool for creating a
mirror of clojars. We currently provide a way to rsync the repo[2], so
the seed for a mirror could be small, and could then slurp down the
full repo (and could continue to do so on a schedule to remain up to
date). We could then publish a list of mirrors that the community
could turn to in times of need (or use all the time, if they are
closer geographically or just generally more responsive). Any deploys
would still need to hit the primary server, but deploys are are
dwarfed by reads.

There are a few issues with using mirrors:

(1) security - with artifacts in more places, there are more
opportunities to to introduce malicious versions. This could be
prevented if we had better tools for verifying that the artifacts
are signed by trusted keys, and we required that all artifacts be
signed, but that's not the case currently. But if we had a regular
process that crawled all of the mirrors and the canonical repo to
verify that the checksums every artifact are identical, this could
actually improve security, since we could detect if any checksum
had been changed (a malicious party would have to change the
checksum of a modified artifact, since maven/lein/boot all confirm
checksums by default).

(2) download stats - any downloads from a mirror wouldn't get
reflected in the stats for the artifact unless we had some way to
report those stats back to clojars.org. We currently generate the
stats by parsing the nginx access logs, mirrors could do the same
and report stats back to clojars.org if we care enough about
this. We don't get stats from the existing private mirrors, and
the stats aren't critical, so this may be a non-issue, and
definitely isn't something that has to be solved right away, if
ever.

The repo is just served as static files, so I think a mirror could
simply be:

(1) a webserver (preferably (required to be?) HTTPS)
(2) a cronjob that rsyncs every N minutes

And the cronjob would just need the rsync command in [2], so, to get
this started, we just need:

(1) linode to be up
(2) people willing to run mirrors

(I would say "(3) add a page to the wiki on how to use a mirror", but
that would destroy the symmetry of all the other 2-item lists in this
message)

And it would be nice to have the process in place to verify checksums
soon - that would actually be a boon if we had another linode
compromise[3].

Does anyone see any issues with this plan - I'm curious if there are
security implications (or anything else) that I haven't thought of?

Are you willing to run a mirror?

One issue that comes to mind is if we do decide to move the repo to a
block store, it actually makes mirroring more difficult unless we keep
a copy of the repo on disk on clojars.org as well. But I would like to
have mirrors in place as soon as possible, and worry about that later.

- Toby

[1]: ht

Re: clojars down?

[Toby Crawley]

We currently have a plan to move the repo out to a block store (s3 or
similar), and part of the fundraising campaign was to pay someone for
that implementation.

For a near term solution, I just started a new thread about running
public clojars mirrors.

- Toby

On Fri, Jan 1, 2016 at 10:10 PM, Alex Miller  wrote:
> I agree with Kyle - I've usually run a company proxy which gives you a lot of 
> options (it's good to publish company forks of libs too).
>
> I believe one of the items the Clojars maintainers are working on with their 
> new funding is support for mirrors.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: Reducing the pain of a clojars outage

[Toby Crawley]

One potential issue with the mirrors is java 6 and HTTPS - the mirrors
couldn't use 2048-bit dhparams[1] or SNI[2], since neither are
supported in java 6. Yes, we all should be on java 7 or 8 at this
point, but I believe Intellij still uses java 6 on MacOS, which would
mean Cursive couldn't download from the mirrors.

[1]: https://weakdh.org/sysadmin.html
[2]: https://en.wikipedia.org/wiki/Server_Name_Indication

On Fri, Jan 1, 2016 at 10:31 PM, Toby Crawley  wrote:
> Given the recent DDoS-triggered outages at linode (including the one
> today that has been the worst yet, currently 10 hours at the time I'm
> writing this), I've been giving some more thought to how we can make
> future outages less painful for the community.
>
> I have an open issue[1] (but no code yet) to move the repository off
> of the server and on to a block store (s3, etc), with the goal there
> to make repo reads (which is what we use clojars for 99.9% of the
> time) independent of the status of the server. But I'm not sure that
> really solves the problem we are seeing today. Currently, we have two
> points of failure for repo reads:
>
> (1) the server itself (hosted on linode)
> (2) DNS for the clojars.org domain (also hosted on linode)
>
> moving the repo off of the server to a block store still has two
> points of failure:
>
> (1) the block store (aws, rackspace, etc)
> (2) DNS for the clojars.org domain, since we would CNAME the block
>  store (hosted on linode)
>
> Though the block store provider would probably be better distributed,
> and have more resources to withstand a DDoS (but do any block store
> providers have 100% uptime?).
>
> The block store solution is complex - it introduces more moving parts
> into clojars, and requires reworking the way we generate usage stats,
> and how the api gets its data. It also requires reworking the way we
> administer the repo (deletion requests, cleaning up failed/partial
> deploys). And it may not solve the availability problem at all, since
> we still have two points of failure.
>
> I think a better solution may be to have multiple mirrors of the repo,
> either run by concerned citizens or maintained by the clojars staff. I
> know some folks in the community already run internal caching proxies
> or rsynced mirrors (and are probably chuckling knowingly at those of
> us affected by the outage), but those proxies don't really help those
> in the community that don't have that internal infrastructure. And I
> don't want to recommend that everyone set up a private mirror - that
> seems like a lot of wasted effort.
>
> Ideally, it would be nice if we had a turn-key tool for creating a
> mirror of clojars. We currently provide a way to rsync the repo[2], so
> the seed for a mirror could be small, and could then slurp down the
> full repo (and could continue to do so on a schedule to remain up to
> date). We could then publish a list of mirrors that the community
> could turn to in times of need (or use all the time, if they are
> closer geographically or just generally more responsive). Any deploys
> would still need to hit the primary server, but deploys are are
> dwarfed by reads.
>
> There are a few issues with using mirrors:
>
> (1) security - with artifacts in more places, there are more
> opportunities to to introduce malicious versions. This could be
> prevented if we had better tools for verifying that the artifacts
> are signed by trusted keys, and we required that all artifacts be
> signed, but that's not the case currently. But if we had a regular
> process that crawled all of the mirrors and the canonical repo to
> verify that the checksums every artifact are identical, this could
> actually improve security, since we could detect if any checksum
> had been changed (a malicious party would have to change the
> checksum of a modified artifact, since maven/lein/boot all confirm
> checksums by default).
>
> (2) download stats - any downloads from a mirror wouldn't get
> reflected in the stats for the artifact unless we had some way to
> report those stats back to clojars.org. We currently generate the
> stats by parsing the nginx access logs, mirrors could do the same
> and report stats back to clojars.org if we care enough about
> this. We don't get stats from the existing private mirrors, and
> the stats aren't critical, so this may be a non-issue, and
> definitely isn't something that has to be solved right away, if
> ever.
>
> The repo is just served as static files, so I think a mirror could
> simply be:
>
> (1) a webserver (preferably (required to be?) HTTPS)
> (2) a cronjob that rsyncs every N minutes
>
> And the cronjob would just need the rsync command in [2], so, to get
> this started, we just need:
>
> (1) linode to be up
> (2) people willing to run mirrors
>
> (I would say "(3) add a page to the wiki on how to use a mirror", but
> that would destroy the symmetry of all the other 2-item lists in

Re: Reducing the pain of a clojars outage

[Daniel Compton]

IntelliJ 15 (the new version), bundles JDK8 for Mac OS X so the concern about 
Java 6 will get less over time. 

It could be helpful to extend https://github.com/clojars/clojars-web/issues/432 
to support these third party mirrors so people just need to point an Ansible 
script at a server and it will be set up for them. 

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

[Ken Restivo]

For deploys, I use uberjars. They don't need any dependencies. It's also 
arguably more secure to have a jar that I know has everything in it, rather 
than trusting lein to fetch it from somewhere that might have been DNS spoofed, 
maliciously proxied, etc.

Of course, builds can be broken by clojars going down, but most everything I'd 
need at build time is in ~/.m2/repository anyway.

-ken
--

On Fri, Jan 01, 2016 at 07:10:36PM -0800, Alex Miller wrote:
> I agree with Kyle - I've usually run a company proxy which gives you a lot of 
> options (it's good to publish company forks of libs too).
> 
> I believe one of the items the Clojars maintainers are working on with their 
> new funding is support for mirrors.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group 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: Reducing the pain of a clojars outage

[Ken Restivo]

Any tooling would also have to upgrade to clj-http 2.0.0 and/or HttpClient 4.5, 
because before that SNI was broken even on Java 8:

https://issues.apache.org/jira/browse/HTTPCLIENT-1613?devStatusDetailDialog=repository

Supposedly fixed in 4.5 of HttpClient, which 2.0.0 of clj-http pulls in, but I 
haven't tested to confirm.

-ken
--
-
On Fri, Jan 01, 2016 at 10:49:13PM -0500, Toby Crawley wrote:
> One potential issue with the mirrors is java 6 and HTTPS - the mirrors
> couldn't use 2048-bit dhparams[1] or SNI[2], since neither are
> supported in java 6. Yes, we all should be on java 7 or 8 at this
> point, but I believe Intellij still uses java 6 on MacOS, which would
> mean Cursive couldn't download from the mirrors.
> 
> [1]: https://weakdh.org/sysadmin.html
> [2]: https://en.wikipedia.org/wiki/Server_Name_Indication
> 
> On Fri, Jan 1, 2016 at 10:31 PM, Toby Crawley  wrote:
> > Given the recent DDoS-triggered outages at linode (including the one
> > today that has been the worst yet, currently 10 hours at the time I'm
> > writing this), I've been giving some more thought to how we can make
> > future outages less painful for the community.
> >
> > I have an open issue[1] (but no code yet) to move the repository off
> > of the server and on to a block store (s3, etc), with the goal there
> > to make repo reads (which is what we use clojars for 99.9% of the
> > time) independent of the status of the server. But I'm not sure that
> > really solves the problem we are seeing today. Currently, we have two
> > points of failure for repo reads:
> >
> > (1) the server itself (hosted on linode)
> > (2) DNS for the clojars.org domain (also hosted on linode)
> >
> > moving the repo off of the server to a block store still has two
> > points of failure:
> >
> > (1) the block store (aws, rackspace, etc)
> > (2) DNS for the clojars.org domain, since we would CNAME the block
> >  store (hosted on linode)
> >
> > Though the block store provider would probably be better distributed,
> > and have more resources to withstand a DDoS (but do any block store
> > providers have 100% uptime?).
> >
> > The block store solution is complex - it introduces more moving parts
> > into clojars, and requires reworking the way we generate usage stats,
> > and how the api gets its data. It also requires reworking the way we
> > administer the repo (deletion requests, cleaning up failed/partial
> > deploys). And it may not solve the availability problem at all, since
> > we still have two points of failure.
> >
> > I think a better solution may be to have multiple mirrors of the repo,
> > either run by concerned citizens or maintained by the clojars staff. I
> > know some folks in the community already run internal caching proxies
> > or rsynced mirrors (and are probably chuckling knowingly at those of
> > us affected by the outage), but those proxies don't really help those
> > in the community that don't have that internal infrastructure. And I
> > don't want to recommend that everyone set up a private mirror - that
> > seems like a lot of wasted effort.
> >
> > Ideally, it would be nice if we had a turn-key tool for creating a
> > mirror of clojars. We currently provide a way to rsync the repo[2], so
> > the seed for a mirror could be small, and could then slurp down the
> > full repo (and could continue to do so on a schedule to remain up to
> > date). We could then publish a list of mirrors that the community
> > could turn to in times of need (or use all the time, if they are
> > closer geographically or just generally more responsive). Any deploys
> > would still need to hit the primary server, but deploys are are
> > dwarfed by reads.
> >
> > There are a few issues with using mirrors:
> >
> > (1) security - with artifacts in more places, there are more
> > opportunities to to introduce malicious versions. This could be
> > prevented if we had better tools for verifying that the artifacts
> > are signed by trusted keys, and we required that all artifacts be
> > signed, but that's not the case currently. But if we had a regular
> > process that crawled all of the mirrors and the canonical repo to
> > verify that the checksums every artifact are identical, this could
> > actually improve security, since we could detect if any checksum
> > had been changed (a malicious party would have to change the
> > checksum of a modified artifact, since maven/lein/boot all confirm
> > checksums by default).
> >
> > (2) download stats - any downloads from a mirror wouldn't get
> > reflected in the stats for the artifact unless we had some way to
> > report those stats back to clojars.org. We currently generate the
> > stats by parsing the nginx access logs, mirrors could do the same
> > and report stats back to clojars.org if we care enough about
> > this. We don't get stats from the existing private mirrors, and
> > the stats aren't critical, so this may be a non-issue, and

Re: Reducing the pain of a clojars outage

[Toby Crawley]

On Fri, Jan 1, 2016 at 11:50 PM, Daniel Compton
 wrote:
> IntelliJ 15 (the new version), bundles JDK8 for Mac OS X so the concern about 
> Java 6 will get less over time.

Ah, good to know.

>
> It could be helpful to extend 
> https://github.com/clojars/clojars-web/issues/432 to support these third 
> party mirrors so people just need to point an Ansible script at a server and 
> it will be set up for them.

Yes, definitely. I was thinking of the bare minimum to get a few
mirrors started.

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

[Michael Gardner]

> On Jan 1, 2016, at 21:31, Toby Crawley  wrote:
> 
> But if we had a regular
>process that crawled all of the mirrors and the canonical repo to
>verify that the checksums every artifact are identical, this could
>actually improve security, since we could detect if any checksum
>had been changed

I would caution against this approach. An attacker could easily target specific 
organizations, serving compromised artifacts only to particular IP ranges. A 
periodic verification process wouldn't detect this[1], and might lend a false 
sense of security that lulls people into putting off real security measures.

[1] Unless run by every organization that uses lein, and even then it still 
might not catch anything if the attackers are clever.

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