Finish new-install #5399

typedrat · 2018-06-26T21:57:22Z

Closes #4558.

Adds support for:

Local targets
Libraries

--

Please include the following checklist in your PR:

Patches conform to the coding conventions.
Any changes that could be relevant to users have been recorded in the changelog.
The documentation has been updated, if necessary.
If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

alexbiehl · 2018-06-26T22:11:49Z

cabal-install/Distribution/Client/CmdInstall.hs

+  let verbosity' = lessVerbose verbosity
+
+  -- First, we need to learn about what's available to be installed.
+  localBaseCtx <- establishProjectBaseContext verbosity' cliConfig


Does this create the dist-newstyle folder in $PWD? We should clean up after this in case we are not in a project context if it does.

Oh, no. That doesn't create a fake context, that's creating a real context in the current project... but that breaks out of project installs. Oops.

yeah, I know... I tried real hard to refactor that stuff once. But there is a chicken/egg problem with establishing the project context and file monitor caching in dist-newstyle...

typedrat · 2018-06-27T03:04:12Z

Okay, so this is now feature-complete in the loosest sense.

The following cases still need to be handled:

Tell the user when environment files aren't supported (and therefore libraries can't be installed)
Quit out early when it will be a no-op.
Make the local package requirements not included when they aren't relevant
Fix bugs
Document

typedrat · 2018-07-02T05:35:17Z

cabal-install/Distribution/Client/CmdInstall.hs

+
+    go :: UnitId -> [(ComponentTarget, [TargetSelector])] -> [GhcEnvironmentFileEntry]
+    go unitId targets
+      | any hasLib targets = [GhcEnvFilePackageId unitId]


❯ cat ~/.ghc/x86_64-darwin-8.4.2/environments/default package-id lnr-1.20.7-359f8114

That's what I get after I try to install linear. Why do I not get the vowels?

Are you on mac os?

https://github.com/typedrat/cabal/blob/638c78e790721566780dbf75a2e6f884ceafa970/cabal-install/Distribution/Client/PackageHash.hs#L164

Hmm, how would I get around that...

Not sure that removing the vowels guarantees any shortening of the name, or contributes big savings.
In any case, it is quite alienating to look into .cabal/store and see that the Grinch stole all the vowels.
I am feeling like I am trolled here, or there was some jester in the team developing the new cabal, and that jester is trying to make fun of the Haskell programmers.

I filed #7209.

fgaz · 2018-07-02T10:03:32Z

cabal-install/Distribution/Client/CmdInstall/EnvironmentParser.hs

+{-# LANGUAGE GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE LambdaCase #-}
+{-# LANGUAGE RecordWildCards #-}
+module Distribution.Client.CmdInstall.EnvironmentParser 


Shouldn't this be in Distribution.Simple.GHC?

I wasn't sure if it was of general enough applicability, but it's easy enough to move it.

alexbiehl · 2018-07-03T09:55:19Z

Awww I fucked up the merge with the Github online editor! Sorry about that!

23Skidoo · 2018-07-03T10:18:19Z

Just rebase.

tom-bop · 2018-07-06T19:02:43Z

Cabal/Distribution/Simple/GHC.hs

@@ -53,10 +53,14 @@ module Distribution.Simple.GHC (
        isDynamic,
        getGlobalPackageDB,
        pkgRoot,
-        -- * Constructing GHC environment files
+        -- * Constructing and deconstsructing GHC environment files


s/deconstsructing/deconstructing/

typedrat · 2018-07-06T19:18:01Z

Should be done, at least done enough to get smacked around by other people. It works for me™ but I haven't had time/access to machines to test it on anything but macOS.

tom-bop · 2018-07-06T19:37:02Z

cabal-install/cabal-install.cabal

@@ -320,6 +320,7 @@ library
        zlib       >= 0.5.3    && < 0.7,
        hackage-security >= 0.5.2.2 && < 0.6,
        text       >= 1.2.3    && < 1.3,
+        parsec     >= 3.1.13.0 && < 3.2,


I see a note in this file: NOTE: when updating build-depends, don't forget to update version regexps in bootstrap.sh.

Also, is there a less-heavyweight library we could use, to decrease the size of the chicken-or-egg problem here? (Thx for this work, btw!)

Cabal the library already uses parsec anyway.

typedrat · 2018-07-07T07:48:00Z

7.4 is legitimately broken, but it's also outside of our support window.

quasicomputational · 2018-07-07T09:13:26Z

It's not working for me:

$ cabal new-run cabal -- -v2 new-install lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-02T15:20:16Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg

That GHC it's trying to use is 8.4.2.

quasicomputational

Haven't been able to actually try the command out yet, but here are some notes from looking at the source.

quasicomputational · 2018-07-07T09:20:27Z

Cabal/Distribution/Simple/GHC/EnvironmentParser.hs

+{-# LANGUAGE LambdaCase #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE RecordWildCards #-}
+module Distribution.Simple.GHC.EnvironmentParser 


GHC has code for parsing these files in DynFlags, but this code is better and we should have an eye on reusing it in GHC. Specifically, I think exporting parseEnvironmentFile along with GhcEnvironmentFileEntry and its constructors from a non-internal module ought to be enough (which we ought to do anyway, since it's mentioned in the types of this non-internal module).

Already exposed in Distribution.Simple.GHC. When we get this merged and available to GHC, I'd be happy to write a patch to use this instead. :)

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+          , sdistProjectFile = projectConfigProjectFile (projectConfigShared cliConfig)
+          }
+
+      sdistAction sdistFlags ["all"] globalFlags


This feels like the wrong level of interface granularity. The sdist code is going to have to go through the hoops of target parsing, output directory logic, and we're re-wrapping the verbosity in a flag. Can CmdSdist export a more convenient function for this?

It even has that, just about, and I'm not at all sure why I'm using the sdistAction.

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

@@ -130,27 +172,188 @@ installAction (configFlags, configExFlags, installFlags, haddockFlags)
    die' verbosity $ "--enable-benchmarks was specified, but benchmarks can't "
                  ++ "be enabled in a remote package"

-  -- We need a place to put a temporary dist directory
+  let


In GitHub's infinite wisdom I can't attach review comments to lines that aren't changed, but there's a comment above with some TODOs. Those are solved now, right?

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+          GhcEnvFileClearPackageDbStack
+        : fmap GhcEnvFilePackageDb packageDbs
+      entries = baseEntries ++ entriesForLibraryComponents (targetsMap buildCtx)
+    createDirectoryIfMissing True (takeDirectory envFile)


If we're bothering to avoid creating .environment files on old GHCs, shouldn't the above lines be under the when?

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

@@ -199,13 +402,37 @@ installAction (configFlags, configExFlags, installFlags, haddockFlags)
    traverse_ (symlinkBuiltPackage verbosity mkPkgBinDir symlinkBindir)
          $ Map.toList $ targetsMap buildCtx
    runProjectPostBuildPhase verbosity baseCtx buildCtx buildOutcomes
+
+    unless supportsPkgEnvFiles $
+      warn verbosity "The current compiler doesn't support safely installing libraries. (GHC 8.0+ only)"


Since this means that libraries aren't installed, I think it should say that rather than mentioning 'safely' here.

I'm intending it as "doesn't support doing it safely (so we're not doing it at all)". Could be clearer though.

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+      sdistAction sdistFlags ["all"] globalFlags
+
+      (specs, selectors) <- withInstallPlan verbosity' localBaseCtx $ \elaboratedPlan -> do
+        -- Split into known targets and hackage packages.


The code under here is really deeply nested. Can we consider lifting some of this out, or are there so many local variables involved that it's annoying?

There's heavy enough cross-involvement that the drop in complexity for lifting bits out is more than made up for by the increase from having to directly plumb everything. I wrote it split out originally but I was passing the same arguments over and over often enough I manually inlined it into that code there.

quasicomputational · 2018-07-07T09:20:27Z

Cabal/doc/nix-local-build.rst

-``cabal new-install [FLAGS] PACKAGES`` builds the specified nonlocal packages
-and symlinks their executables in ``symlink-bindir`` (usually ``~/.cabal/bin``).
+``cabal new-install [FLAGS] PACKAGES`` builds the specified packages, adds their
+libraries into the default environment and symlinks their executables in


Should probably link to the GHC manual describing package environments.

I think we also need to describe the practical effects of this. The GHC docs say this:

Note the implicit -hide-all-packages and the fact that it is -package-id ⟨unit-id⟩, not -package ⟨pkg⟩. This is because the environment specifies precisely which packages should be visible.

So if I don't have a default package environment before, then I cabal new-install something, and now every manual GHC invocation will have an implicit -hide-all-packages. I am not sure this is going to make users happy.

Well, that's only a real issue if you are using both install commands at once. I'm personally comfortable saying "don't do that, then", but that's just me.

IIUC this will also apply to, e.g., packages installed to the global store using the system package manager as well. I'd be okay with saying that v1-install and new-install don't play nicely together but I'm more hesitant about that interaction.

Hmm... We could just include all of the global packages.

My personal opinion is that the package manager's packages are for system dependencies not for building software locally.

Thinking further, exposing package manager packages is an emphatic Bad Choice, as far as I'm concerned. That greatly expands the burden in terms of creating a consistent install plan, and will likely end up with a lot of situations where you are stuck on old version because you need some random (and likely antique) version of text or something because that's what the package manager provides.

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+  envEntries <- if 
+    | compilerFlavor == GHC || compilerFlavor == GHCJS
+    , supportsPkgEnvFiles
+    , envFileExists -> readGhcEnvironmentFile envFile


If a failure to install libraries isn't fatal because GHC is old, then I think we should gracefully handle an extant-but-unparseable default package environment by warning about that and then installing the executables anyway.

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+    createDirectoryIfMissing True (takeDirectory envFile)
+    when supportsPkgEnvFiles $ do
+      let 
+        entries' = nub (envEntries ++ entries)


First, is this nub absolutely never going to go wrong and lead to a non-Cabal-generated package environment being destroyed, including, e.g., making it easy to roll back Cabal's changes?

Second, a user might install many thousands of packages. ordNub is O(n log n), so go for that instead.

This code generally considers that env as belonging to Cabal, but that isn't explicit. Either needs the code to change or the docs to call out that we own that file.

A mention in the docs that Cabal considers this file its property ought to suffice.

quasicomputational · 2018-07-07T09:20:27Z

cabal-install/Distribution/Client/CmdInstall.hs

+      configCompilerEx hcFlavor hcPath hcPkg progDb verbosity
+
+  let 
+    envFile = home </> ".ghc" </> ghcPlatformAndVersionString platform compilerVersion


If new-install grows a --target-environment flag that takes a file naming the environment to write to, rather than always being the default package environment, then I think testing this code gets a lot simpler.

typedrat · 2018-07-07T13:54:20Z

Should have fixed your issue, @quasicomputational.

typedrat · 2018-07-07T13:55:01Z

Why is there a parse error only on 7.10?

quasicomputational · 2018-07-07T13:57:51Z

Sadly not, still happening with 0b2817f (this PR's latest commit).

typedrat · 2018-07-07T14:00:43Z

For some reason, it doesn't have your compiler in the program db it passes to getInstalledPackages.

quasicomputational · 2018-07-07T14:10:21Z

No clue here, sorry. I can provide diagnostics if you've got any idea what might be helpful, or any new logging you put in to try and work out what's going on.

typedrat · 2018-07-07T14:21:23Z

I'll work on it more seriously after breakfast. 😝

typedrat · 2018-07-07T14:28:22Z

    print progDb

on line CmdInstall.hs:319 would be helpful.

quasicomputational · 2018-07-07T14:32:52Z

$ cabal new-run cabal -- new-install -v2 lib:Cabal
Resolving dependencies...
Up to date
Reading available packages of hackage.haskell.org...
Using most recent state specified from most recent cabal update
index-state(hackage.haskell.org) = 2018-07-07T12:53:49Z
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/Cabal-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-testsuite-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/cabal-install-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/solver-benchmarks-2.3.0.0.tar.gz
Wrote tarball sdist to
/home/sam2/src/cabal/dist-newstyle/sdist/pretty-show-1.6.16.tar.gz
Resolving dependencies...
[]
/home/sam2/.local/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in /home/sam2/.local/bin
found ghc-pkg in /home/sam2/.local/bin/ghc-pkg
/home/sam2/.local/bin/ghc-pkg --version
/home/sam2/.local/bin/ghc --supported-languages
/home/sam2/.local/bin/ghc --info
Distribution/Simple/GHC.hs:453:5-53: Irrefutable pattern failed for pattern Just ghcProg

typedrat · 2018-07-10T19:48:58Z

@tom-bop, it's the sum of existing libraries (new-install a followed by new-install b gives you most of the bundled libraries, a, and b)

tom-bop · 2018-07-10T20:21:17Z

@typedrat 👍 , but it won't for example have any of the package you "old-installed", right?

typedrat · 2018-07-10T20:21:38Z

@tom-bop, that's correct.

gbaz · 2018-07-11T01:28:16Z

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

This is a good question. Whether or not we do it, it would be good to bikeshed what the "right" name might be, for conceptual clarity if nothing else. I was thinking "provide"?

fgaz · 2018-07-11T10:45:43Z

Or env, like nix

andreabedini · 2018-07-11T14:00:50Z

I landed here wondering why cabal new-install brittany fails (see conversation linked above and #5427).

While I am sure I don't fully understand the discussion, there's one important point I haven't seen mentioned. So here's my drive-by comment.

even when 3.0 lands, there will still be heaps of references on the internet to cabal install. Please don't break those! Beginners learn from Google and Stack Overflow, not from GitHub issues (like me :P). I would guess (but I have no data) that most of the references to cabal install are used in the context of installing a executable.

I've been very tempted to introduce a different sub-command altogether for managing package environments, as the install name is a bit misleading at this point, as w/ a nix-style store, the term "installing" is not the proper mental model to have anymore IMO.

I'd say go for it then. cabal install can emit a warning mentioning the new command.

Thanks.

ekmett · 2018-07-11T19:35:19Z

If we're going to add v1-build, etc. we should add v2-build, etc. at the same time referencing the current new- behavior, so as to preemptively give people a forward-compat-friendly way to refer to the new build system. This would allow users who have lots of build scripts to skip one migration step, easing the transition, and ensuring that any similar changes in the future have a simple, clean, already-in-place migration plan.

typedrat · 2018-07-11T19:39:25Z

@ekmett, it's less trivial than it seems to add aliases, and I feel like the likelihood of a third new paradigm is low enough to not merit the work to add them for new- commands.

ekmett · 2018-07-11T19:47:47Z

Then I don't particularly look forward to enduring all the same complaints when we get around to a v3. ;)

typedrat · 2018-07-12T08:36:06Z

Y'know what, it's not as bad as I thought, but that'd be a different PR. :)

[ci skip]

hvr · 2018-07-12T21:57:03Z

@ekmett Well, my idea was rather to consider new- as such a v2- prefix, as that's what all the scripting out there has been using for 2-3 years (it's been in cabal-1.24, cabal-2.0 and cabal-2.2); introducing an additional v2- prefix alias now seems uneconomical to me. And in the hopefully unlikely event we ever need another UI generation, we'd just call it v3- (i.e. we do not call it new- as new- shall keep referring to the 2nd gen). IOW, the prefixes would be

v1-* refer to the 1st generation (supported since (yet unreleased) cabal-2.2.1.0)
new-* refer to the 2nd generation (supported since cabal-1.24)
v3-* for a future 3rd generation

ekmett · 2018-07-13T02:24:13Z

@hvr You have to admit that state of affairs seems messy and inconsistent, especially in the event we ever do ship a v3-, no matter how its usage evolves.

At some unknown future point we may or may not get around to a v3-, and it may or may not want to take the new- monicker as it rolls out.

But in any of those worlds, having v2- would give a way to get current new-build style behavior in a stable way that will last through any v3- attempt, no matter if it chooses to take over new- or not. And in avoids the pretty awful inconsistency of new- referring to rather old behavior and of having every version but v2- be consistently named.

What I'd ideally want is to be able to make one change to my build scripts to migrate to v2- behavior after the next cabal release, and not to have to stir again until long after some future v3- comes along and I decide to move. While your v1-, new-, v3- story delivers on that, it does so in a way that ensures that new- is forever tainted to mean the current behavior rather than considering that future maintainers of cabal might prefer for it to switch to rolling forward, and requires folks to eventually know that new- really means old-but-not-that-old-.

hvr · 2018-07-13T08:26:32Z

@ekmett yes, in hindsight, having used new-* at all was probably not ideal. We should have used v2- right-away; but now we're faced with the choice whether to have new-* become a dynamic prefix which will very likely break tons of scripting out there.

Also, if we decide to introduce v2-, we have a different kind of inconsistency in the event that a 3rd gen UI becomes available as tech-preview in a hypothethical future cabal-3.12 version.

for cabal-1.24 through cabal-3.10, new-* refers to the 2nd gen UI
for cabal-3.12 and later, new-* changes its meaning and refers to to the 3rd gen UI
starting with cabal-2.2.1 (NB: cabal-2.2.1 may never end up in a Haskell Platform release if GHC 8.4.4 is never released) v1- and v2- become available, and refer to the 1st and 2nd gen UI
starting cabal-3.12 and later, v3-* refers to to the 3rd gen UI

So the trade-off here is, either

With the scheme above which changes the meaning of new-*, you'd be forced to change all your new-build-based scripts that were written over the last 2-3 years to remain well-defined (NB: v2- didn't exist yet in cabal-1.24, cabal-2.0 and cabal-2.2; so such scripting would have to require cabal-2.2.1 or later just for the sake of using the v2- prefix). So you'd suffer breakage for the benefit of avoiding an admittedly unfortunate naming weirdness or
with the pragmatic scheme outlined in #5399 (comment), We stomach the naming weirdness, but in return we don't force all the scripting out there based on the new-* prefix to rename to v2-

In hindsight, we should have introduced v1- and v2- prefix synonyms (pointing to build and new-build respectively) back w/ cabal-1.24; but unfortunately we didn't. So now we're faced with a choice between two non-optimal tradeoffs. While I'm still leaning towards my suggestion, I'm not married to it.

tom-bop · 2018-07-13T14:35:04Z

Is there a cost to simply having a v2-* alias that points to (what's currently called) new-*?

That way we'd have

v1-*
v2-* <-- new-* is an alias to this but over the years that could be deprecated and the new-* alias could gradually be freed up for future use (or not!)
v3-*

typedrat added the cabal-install: nix-local-build label Jun 26, 2018

typedrat self-assigned this Jun 26, 2018

typedrat requested review from 23Skidoo and hvr Jun 26, 2018

alexbiehl reviewed Jun 26, 2018

View changes

typedrat force-pushed the typedrat:new-install branch from f09768b to 96196b8 Jun 26, 2018

typedrat added this to In Progress in Have new-build become build (GSOC2018) Jun 30, 2018

typedrat reviewed Jul 2, 2018

View changes

fgaz reviewed Jul 2, 2018

View changes

typedrat force-pushed the typedrat:new-install branch from 0fbd56c to 066dec7 Jul 3, 2018

tom-bop reviewed Jul 6, 2018

View changes

typedrat changed the title ~~[WIP] Finish new-install~~ Finish new-install Jul 6, 2018

typedrat added this to the 2.4 milestone Jul 7, 2018

quasicomputational reviewed Jul 7, 2018

View changes

Allow resolveTargets to know about Hackage packages

bbbb833

typedrat added 2 commits Jul 10, 2018

Add --env-cwd

Loading status checks…

4bff0e4

Change environment flag to mirror GHC

Loading status checks…

e0ee808

Fix code clean-up error

Loading status checks…

832a532

andreabedini mentioned this pull request Jul 11, 2018

cabal new-install brittany fails lspitzner/brittany#162

Closed

andreabedini mentioned this pull request Jul 11, 2018

Musical chairs to switch `new-` and `old-` #5358

Merged

4 of 4 tasks complete

typedrat mentioned this pull request Jul 12, 2018

Add future-proof aliases for new- commands #5429

Merged

3 of 3 tasks complete

Update documentation with accurate usage

ec97ec0

[ci skip]

typedrat force-pushed the typedrat:new-install branch from 1e1188f to 56939d8 Jul 12, 2018

typedrat added 2 commits Jul 12, 2018

Fix verbosity-parsing bug.

1fc266e

Make packageToSdist restore $OLDPWD

Loading status checks…

7d961eb

typedrat force-pushed the typedrat:new-install branch from 56939d8 to 7d961eb Jul 12, 2018

Fix ProjectPlanning so not all SpecificSourcePackages are local

Loading status checks…

6b06e6a

typedrat moved this from In Progress to Done in Have new-build become build (GSOC2018) Jul 13, 2018

andreasabel mentioned this pull request Dec 21, 2020

The Grinch stole all the vowels: Odd naming in .cabal/store (macOS) #7209

Open

haskell / cabal

Finish new-install #5399

Finish new-install #5399

Conversation

typedrat commented Jun 26, 2018 • edited

This comment has been minimized.

alexbiehl Jun 26, 2018 Member

This comment has been minimized.

typedrat Jun 26, 2018 Author Collaborator

This comment has been minimized.

alexbiehl Jun 26, 2018 Member

typedrat commented Jun 27, 2018 • edited

This comment has been minimized.

typedrat Jul 2, 2018 • edited Author Collaborator

This comment has been minimized.

fgaz Jul 2, 2018 Collaborator

This comment has been minimized.

typedrat Jul 2, 2018 Author Collaborator

This comment has been minimized.

andreasabel Dec 21, 2020

This comment has been minimized.

andreasabel Dec 21, 2020

This comment has been minimized.

fgaz Jul 2, 2018 Collaborator

This comment has been minimized.

typedrat Jul 2, 2018 Author Collaborator

alexbiehl commented Jul 3, 2018

23Skidoo commented Jul 3, 2018

This comment has been minimized.

tom-bop Jul 6, 2018

typedrat commented Jul 6, 2018

This comment has been minimized.

tom-bop Jul 6, 2018

This comment has been minimized.

tom-bop Jul 6, 2018

This comment has been minimized.

typedrat Jul 6, 2018 Author Collaborator

typedrat commented Jul 7, 2018

quasicomputational commented Jul 7, 2018

quasicomputational left a comment

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 9, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

quasicomputational Jul 7, 2018 Contributor

This comment has been minimized.

typedrat Jul 7, 2018 Author Collaborator

typedrat commented Jun 26, 2018 •

edited

alexbiehl Jun 26, 2018
Member

typedrat Jun 26, 2018
Author Collaborator

alexbiehl Jun 26, 2018
Member

typedrat commented Jun 27, 2018 •

edited

typedrat Jul 2, 2018 •

edited

Author Collaborator

fgaz Jul 2, 2018
Collaborator

typedrat Jul 2, 2018
Author Collaborator

fgaz Jul 2, 2018
Collaborator

typedrat Jul 2, 2018
Author Collaborator

typedrat Jul 6, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 9, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

typedrat Jul 7, 2018
Author Collaborator

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

quasicomputational Jul 7, 2018
Contributor

quasicomputational Jul 7, 2018
Contributor

typedrat Jul 7, 2018
Author Collaborator

typedrat commented Jul 7, 2018 •

edited

andreabedini commented Jul 11, 2018 •

edited

hvr commented Jul 13, 2018 •

edited