From 527e813bea1afb5f3146285c19741583b207b256 Mon Sep 17 00:00:00 2001 From: "evan@0e4cded17eab71af967a38b123fbc211cf215421" Date: Sat, 19 Mar 2016 14:51:51 +0000 Subject: From GH PR #13 --- doc/todo/OpenVPN___40__PR___35__13__41__.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/todo/OpenVPN___40__PR___35__13__41__.mdwn diff --git a/doc/todo/OpenVPN___40__PR___35__13__41__.mdwn b/doc/todo/OpenVPN___40__PR___35__13__41__.mdwn new file mode 100644 index 00000000..3847b31c --- /dev/null +++ b/doc/todo/OpenVPN___40__PR___35__13__41__.mdwn @@ -0,0 +1,20 @@ +> Is the ghc ppa needed past 12.04LTS? Past that version, they seem to +> have ghc 7.6.3 or newer, which is the current target version as it's the +> version in debian stable. If only specific ubuntu versions need the ghc +> ppa it would be best to avoid using it on newer ones. + +Oh! I hadn't realized 7.6.3 was the target, so I upgraded to 7.10.3 (which is what I've been using for things). I can definitely try a spin without it. I can't remember why I thought 7.6.3 was failing there but I'll definitely dig into it. + +> Even type aliases +> would be an improvement but probably newtypes or ADTs would improve on +> it. Also there may be some overlap with typees in Propellor.Property.Firewall + +Oh yes, definitely. I'll take a pass at that too, and dig into Firewall to see what's there. + +> Isn't Property HasInfo a shorter way to write that? I'm somewhat +> surprised you arrived at the partially applied type family there; ghc +> normally tells you the simplified type. + + CombinedType (Property NoInfo) (Property HasInfo) + +That's an excellent question. I think ultimately I tried a type hole to find out what I was missing, and that's what it came up with, but it also might be differences in ghc versions I stumbled into. I'll give it a try with 7.6.3. I'm using Trusty 14.04.4 for the project this is for. -- cgit v1.3-2-g0d8e From 6789411e43a451aeb2246d4b686a7b37097b95df Mon Sep 17 00:00:00 2001 From: "arnaud@30aba4d9f1742050874551d3ddc55ca8694809f8" Date: Sat, 19 Mar 2016 17:52:05 +0000 Subject: Added a comment: Spinning hosts in parallel --- .../comment_1_1976b145c519b575c1b0454611036055._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/automated_spins/comment_1_1976b145c519b575c1b0454611036055._comment diff --git a/doc/automated_spins/comment_1_1976b145c519b575c1b0454611036055._comment b/doc/automated_spins/comment_1_1976b145c519b575c1b0454611036055._comment new file mode 100644 index 00000000..24298db9 --- /dev/null +++ b/doc/automated_spins/comment_1_1976b145c519b575c1b0454611036055._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="arnaud@30aba4d9f1742050874551d3ddc55ca8694809f8" + nickname="arnaud" + subject="Spinning hosts in parallel" + date="2016-03-19T17:52:04Z" + content=""" +I just noticed the existence of this conductor property, which seems really interesting. I was trying to understand if and how it would be possible to spinning hosts in parallel. This could be done either as part of a conductor's run, e.g. by traversing the graph in parallel, or from command-line. It seems to me I could use directly `spin` or `spin'` functions to do that from forked threads or processes, with the master process doing the spin commit, but I may be overlooking some potential issues... +"""]] -- cgit v1.3-2-g0d8e