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:42Z

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:31Z

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-06T20:27:13Z

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-06T20:31:47Z

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-06T20:44:46Z

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-06T20:48:04Z

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-06T20:51:04Z

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-06T20:54:21Z

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-06T21:06:36Z

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-06T21:11:18Z

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-06T21:24:16Z

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-06T21:29:00Z

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 Finish new-install #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 June 26, 2018 21:57

alexbiehl reviewed Jun 26, 2018

View reviewed changes

typedrat force-pushed the new-install branch from f09768b to 96196b8 Compare June 26, 2018 23:05

typedrat commented Jul 2, 2018

View reviewed changes

fgaz reviewed Jul 2, 2018

View reviewed changes

typedrat force-pushed the new-install branch from 0fbd56c to 066dec7 Compare July 3, 2018 13:08

tom-bop reviewed Jul 6, 2018

View reviewed 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 reviewed changes

Allow resolveTargets to know about Hackage packages

bbbb833

typedrat added 2 commits July 10, 2018 12:21

Add --env-cwd

4bff0e4

Change environment flag to mirror GHC

e0ee808

Fix code clean-up error

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 tasks

typedrat mentioned this pull request Jul 12, 2018

Add future-proof aliases for new- commands #5429

Merged

3 tasks

Update documentation with accurate usage

ec97ec0

[ci skip]

typedrat force-pushed the new-install branch from 1e1188f to 56939d8 Compare July 12, 2018 21:53

typedrat added 2 commits July 12, 2018 14:58

Fix verbosity-parsing bug.

1fc266e

Make packageToSdist restore $OLDPWD

7d961eb

typedrat force-pushed the new-install branch from 56939d8 to 7d961eb Compare July 12, 2018 21:59

Fix ProjectPlanning so not all SpecificSourcePackages are local

6b06e6a

typedrat merged commit 83120cd into haskell:master 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

fgaz mentioned this pull request Oct 9, 2021

local options do not work with install on local packages (was: Run okay with profiling enabled, but installed exe has NO profiling enabled) #7297

Closed

Finish new-install #5399

Finish new-install #5399

Conversation

typedrat commented Jun 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

typedrat commented Jun 27, 2018 • edited Loading

typedrat Jul 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexbiehl commented Jul 3, 2018

23Skidoo commented Jul 3, 2018

Choose a reason for hiding this comment

typedrat commented Jul 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

typedrat commented Jul 7, 2018

quasicomputational commented Jul 7, 2018

quasicomputational left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

typedrat commented Jul 7, 2018

typedrat commented Jul 7, 2018

quasicomputational commented Jul 7, 2018

typedrat commented Jul 7, 2018

quasicomputational commented Jul 7, 2018

typedrat commented Jul 7, 2018

typedrat commented Jul 7, 2018 • edited Loading

quasicomputational commented Jul 7, 2018

typedrat commented Jul 10, 2018

tom-bop commented Jul 10, 2018

typedrat commented Jul 10, 2018

gbaz commented Jul 11, 2018

fgaz commented Jul 11, 2018

andreabedini commented Jul 11, 2018 • edited Loading

ekmett commented Jul 11, 2018

typedrat commented Jul 11, 2018

ekmett commented Jul 11, 2018

typedrat commented Jul 12, 2018

hvr commented Jul 12, 2018

ekmett commented Jul 13, 2018

hvr commented Jul 13, 2018 • edited Loading

tom-bop commented Jul 13, 2018

typedrat commented Jun 26, 2018 •

edited

Loading

typedrat commented Jun 27, 2018 •

edited

Loading

typedrat Jul 2, 2018 •

edited

Loading

typedrat commented Jul 7, 2018 •

edited

Loading

andreabedini commented Jul 11, 2018 •

edited

Loading

hvr commented Jul 13, 2018 •

edited

Loading