• 62e87814 Guess at styling

I'm not sure if this is working, but am just going to push it live, check there, and then make adjustments as needed in a follow-up PR

• c012189d Fix "Not in scope: data constructor PayoutHistory" […]

• 38ad6516 I think this will fix the type error […]

• 698751c8 Fix "Not in scope: data constructor PayoutHistory" […]
• c4b50d54 I think this will fix the type error […]

• ecfe89fa Finally fix build for real […]

(after I finally fix the build, that is)

• 62e87814 Guess at styling
• 698751c8 Fix "Not in scope: data constructor PayoutHistory" […]
• c4b50d54 I think this will fix the type error […]
• ecfe89fa Finally fix build for real […]
• de72a8df Merge branch 'alpha-dashboard-tweaks' into 'master' […]

@chreekat I tried to pull out a helper function sum = foldr (+) 0, but had trouble with the types.

Letting ghc infer the types, it can't infer the proper generic

 • Couldn't match type ‘DonationUnits’ with ‘Cents’
 Expected type: [DonationUnits]
 Actual type: [Cents]
 • In the first argument of ‘sum’, namely ‘(map getCharge payouts)’
 In the expression: sum (map getCharge payouts)
 In an equation for ‘totalCharged’:
 totalCharged = sum (map getCharge payouts)

So I tried to type it as sum :: a => [a] -> a, but I'm not sure the right constraint to put on a, so I get this:

 • Expected a type, but ‘a’ has kind ‘Constraint’
 • In the type signature:
 sum :: a => [a] -> a
 In an equation for ‘getDashboardR’:
 getDashboardR
 = do { Entity uid _ <- requireAuth;
 (patron, project) <- runDB
 $ (,) <$> fetchPatron uid <*> fetchProject;
 payouts <- runDB $ fetchPatronPayouts uid;
 .... }
 where
 withMonthView (CrowdmatchDay d, amt) = (MonthView d, amt)
 getDonation :: PayoutInstance -> DonationUnits
 getDonation (_, _, donation, _) = donation
 getFee :: PayoutInstance -> Cents
 ....

…so I decided not to bother.

If I were more comfortable in the language, I'd probably define these inline as lambdas.

Closing this issue, to reopen or create a new one when it is clearer this is needed or if Penpot will serve adequately. The issue description is also outdated — the Trello board has been retired for some time and this item is not being tracked in any open OSUOSL support ticket.

I made updated edits that are both here and at the shared doc https://docs.snowdrift.coop/6JCdJNobQteXjtAYMpDTqg?both

I recognize the first issue, although I can't remember what causes it: In some cases, GHC won't fully generalize the type of function defined in a where clause, and I think it might have something to do with one of the many language extensions that Yesod relies on.

The solution is to give it an explicit type signature, which is what you tried.

But a => [a] -> a says "Given some constraint named a, turn a list of a into a single a". Things to the left of the fat arrow => must have kind Constraint, so it infers that before trying the rest of the type signature.

What would have worked is Num a => [a] -> a.

But what have worked even better would be to use the sum defined in the Prelude. https://hackage.haskell.org/package/base-4.19.0.0/docs/Prelude.html#v:sum :)

This is more readable.

What would truly be better is to upgrade PayoutInstance to a real sum type, instead of a type synonym of a 4-tuple.

• f0a0cd83 Don't rely on being in a git repo
• 6bb4b049 Add Dockerfile for local development
• 5cf13d33 Explain how to use the local build image

See README.

• c388c012 Explain how to use the local build image

• 7e601419 Explain how to use the local build image

It worked, but the workaround does not appear to do anything on my system; I get,

/bin/sh: line 0: ulimit: open files: cannot modify limit: Operation not permitted

That said, it also installed fast enough, so no issues here either.

I think I might have broken my docker install a while back when I was trying to run MusicBrainz locally and was setting up volumes at non-standard locations.. so I'm running into this error in step 15 (installing GHC), which I will need to spend some time tracking down.

Error processing tar file(exit status 1): write /home/smichel/.ghcup/ghc/8.0.2/lib/ghc-8.0.2/template-haskell-2.11.1.0/libHStemplate-haskell-2.11.1.0_p.a: no space left on device

I don't think this is an issue with the Dockerfile, but if you think it is (or have more ideas before I figure it out myself), let me know!

Not really directly related to your change but:

1. In case the path to the script contains any spaces it can end up with being a wrong path or “too many arguments for cd” kind of error. But it won’t work as intended.
2. If dirname fails (e.g. mistyped command dirnmae) projRoot will end up being your home directory (cd call with no arguments), the error will be masked. Depending on what the following script commands are a bunch of garbage artifacts can be created in your home dir as a side-effect.

If what you want is to set it to the project root relative to the script file this should be failproof:

SCRIPT_DIR=$(dirname -- "${BASH_SOURCE[0]}")
cd -- "$SCRIPT_DIR"

Haha I have no idea what's happening here. Maybe a difference in the kernel.

Yeah, sounds like a you problem unfortunately.

Thanks! projRoot is used in a few different places in the script, so I probably just want

projRoot=$(dirname -- "${BASH_SOURCE[0]}")

Oh yeah, that’s actually what I meant. There was a cd inside the subshell interpolation, not outside of it.