Re: [Snowdrift-dev] /p/snowdrift

[Peter Harpending]

On Wed, May 18, 2016 at 11:58:54AM -0700, Bryan Richter wrote:
> On Wed, May 18, 2016 at 12:39:32PM -0600, Peter Harpending wrote:
> > On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote:
> > > I don't understand exactly why it's a corner case. Under the current 
> > > system,
> > > wouldn't /p/snowdrift/ eventually be coded the exact same way as any other
> > > project, so new projects would be prevented from using `snowdrift` as a 
> > > slug
> > > in the same way that they'd be prevented from taking the slug of any other
> > > existing project?
> > 
> > N.B. I'm using the coqdoc convention of putting code in [square braces].
> > 
> > No. As it's implemented now,[SnowdriftProject] is in its own data type, 
> > defined
> > in config/models.
> 
> No it isn't. :)
> 
> There is now no SnowdriftProject type, nor should there ever be.
> 
> Stephen is right; this is not an issue yet. The "/p/snowdrift" route
> will go away, replaced by "/p/#ProjectSlug", and the snowdrift project
> will be the obvious owner of the ProjectSlug that corresponds to the
> route "/p/snowdrift".

Damn, I forgot to ask this in my other email: what are you envisioning as the
type for Project. I'm thinking something like this:

Project
slug ProjectSlug
owner UserId
UniqueProject slug

If that looks agreeable, can I go ahead and implement it? How are you
envisioning always creating a project named Snowdrift? Some sort of migration
hackery? Perhaps something like the old devDB.sql?

-- 
Peter Harpending <pe...@harpending.org>


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] /p/snowdrift

[Peter Harpending]

On Wed, May 18, 2016 at 02:23:01PM -0400, Stephen Michel wrote:
> I don't understand exactly why it's a corner case. Under the current system,
> wouldn't /p/snowdrift/ eventually be coded the exact same way as any other
> project, so new projects would be prevented from using `snowdrift` as a slug
> in the same way that they'd be prevented from taking the slug of any other
> existing project?

N.B. I'm using the coqdoc convention of putting code in [square braces].

No. As it's implemented now,[SnowdriftProject] is in its own data type, defined
in config/models. In real terms, this means that there's a separate table in the
database called [snowdrift_project]. The [snowdrift_project] table only has one
row, which is inserted manually somewhere in the current source tree. [Project]
will eventually be a separate data type in config/models (and therefore have its
own table in the database).

[Project] will have a uniqueness constraint on the slug, much like how [User]
has a uniqueness constraint on the email. This uniqueness constraint is enforced
at the database level. Yesod and its database library (Persistent) only take
care of formatting database commands, and protecting against some security
threats, such as SQL injection.

The key thing here is that [Project]'s uniqueness constraint won't extend to
[SnowdriftProject]. They will likely not even have the same data structure.  For
instance, [SnowdriftProject] doesn't need to have the concept of a "slug",
because there's no dynamic routing to be done.

Therefore, were we to insert any additional constraints, they would need to be
either

1. Enforced at the database level, and therefore expressed through Persistent,
   or (maybe) a migration.  This is difficult at best, and probably not
   possible.
2. Enforced at the Haskell level. This would mean defining a separate type, 
called
   [ProjectSlug], which would be a wrapper aroung [Text]. We'd then have to add
   code in the constructor of [ProjectSlug] specifying that the [Text] in the
   slug couldn't be equal to "snowdrift". Haskell doesn't really have the
   concept of a "constructor", so we'd have to use some type hackery,
   introducing even more performance overhead and code complexity.
   
All of this would be avoided if we just changed the route.

-- 
Peter Harpending <pe...@harpending.org>


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] /p/snowdrift

[Peter Harpending]

This is mostly directed at Bryan, but I thought it was appropriate for the
entire ML to comment.

I don't like using /p/snowdrift as the route to SnowdriftProjectR, because it
introduces an unnecessary corner case. It means that when we eventually want to
have /p/#Text, we have to use a smart newtype, and add a bunch of extra code
that makes sure that nobody makes a project with "snowdrift" as its slug.

Solutions:

1. Move /p/snowdrift elsewhere, like /snowdrift
2. Use /project/#Text rather than /p/#Text in the future.
3. Deal with the extra code bloat.

I vote for option 1, because it's by far the cleanest. It would be really weird
to have /p/snowdrift, but no /p/AnyOtherProject. If there's a special case, it
should be at a top-level route, like the other special cases, e.g. /welcome,
/dashboard, /search, etc.

-- 
Peter Harpending <pe...@harpending.org>


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] US-155, fetching git revisions

[Peter Harpending]

Hi, all,

I'm wondering what peopl had in mind regarding a solution to US-155
<https://tree.taiga.io/project/snowdrift/us/155?kanban-status=729903>. 

> Looking at code diffs, Alice uses a simple tool to fetch the SHA of the live
> production site

I assume this is the sha1 hash of the git commit (i.e. git rev-list HEAD -1),
not a hash of the source tarball or something like that. I wrote a little script
that will fetch this for the site that is currently on <https://snowdrift.coop>
(see <https://git.snowdrift.coop/sd/snowdrift/merge_requests/8>). As it stands,
there is no equivalent of /dev/build in the master branch.

So, I'm wondering what y'all want to do so that we can have a tool for the new
site. I threw together a merge request
<https://git.snowdrift.coop/sd/snowdrift/merge_requests/7>, which includes a
/git route. /git shows the git commit for the running site using yesod-gitrev.
These's a screenshot of the result in that merge request. It's ugly, but it
would work.

-- 
Peter Harpending <pe...@harpending.org>


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Make Snowdrift project wiki search redirect to the gitit wiki

[Peter Harpending]

On Tue, May 17, 2016 at 09:12:30PM +0300, fr33domlo...@riseup.net wrote:
> From: fr33domlover <fr33domlo...@rel4tion.org>
> 
> ---
>  website/Snowdrift.cabal | 1 +
>  website/config/routes   | 1 +
>  website/src/Handler.hs  | 4 
>  3 files changed, 6 insertions(+)
> 
> diff --git a/website/Snowdrift.cabal b/website/Snowdrift.cabal
> index 5cf461c..0994000 100644
> --- a/website/Snowdrift.cabal
> +++ b/website/Snowdrift.cabal
> @@ -61,6 +61,7 @@ library
>  MultiParamTypeClasses
>  GeneralizedNewtypeDeriving
>  RecordWildCards
> +ViewPatterns
>  
>  -- build-depends {{{2
>  build-depends:
> diff --git a/website/config/routes b/website/config/routes
> index e2f9d0d..510423c 100644
> --- a/website/config/routes
> +++ b/website/config/routes
> @@ -20,3 +20,4 @@
>  /merchandise MerchandiseR GET
>  
>  /p/snowdrift SnowdriftProjectR GET
> +/p/snowdrift/w/#Text SnowdriftWikiSearchR GET
> diff --git a/website/src/Handler.hs b/website/src/Handler.hs
> index 9506a50..d1c3f1d 100644
> --- a/website/src/Handler.hs
> +++ b/website/src/Handler.hs
> @@ -72,3 +72,7 @@ getMerchandiseR = $(widget "page/merchandise" 
> "getMerchandiseR")
>  -- For MVP, there is one, hard-coded project: Snowdrift
>  getSnowdriftProjectR :: Handler Html
>  getSnowdriftProjectR = $(widget "page/snowdrift-project" "Snowdrift.coop 
> Project")
> +
> +getSnowdriftWikiSearchR :: Text -> Handler Html
> +getSnowdriftWikiSearchR slug =
> +redirect $ "https://wiki.snowdrift.coop/_search?patterns=; <> slug
> -- 
> 1.9.1

I don't have colorized diffs in my email client, so take my input with a grain
of salt.  That said, it looks fine, and this is a good feature to add. My only
question is: why do we need ViewPatterns? I'm not necessarily opposed to it, I'm
just curious.

-- 
Peter Harpending


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] taiga: can't edit or comment my own issue

[Peter Harpending]

On Sun, May 01, 2016 at 12:05:16PM +0200, Victor Grousset/tuxayo wrote:
> On 30/04/2016 16:07, Peter Harpending wrote:
> > Please do not send HTML mail to a mailing list.
> 
> Thanks, noted I'll try to remember.
> 
> 
> (Or, ideally, at all).
> 
> For command line email readers or are there others reasons?
> 

Mostly for terminal-based email readers, I think


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] taiga: can't edit or comment my own issue

[Peter Harpending]

On Sat, Apr 30, 2016 at 02:24:07PM +0200, Victor Grousset/tuxayo wrote:
> 
>   
> 
> 
>   
>   
> Hi,
> 
> I just opened
>  href="https://tree.taiga.io/project/snowdrift/issue/304;>https://tree.taiga.io/project/snowdrift/issue/304
> 
> However I wanted to updated the title and improve the formatting of
> the content but I can't.
> Nor comment to add more details and discuss the issue.
> 
> Is this to be expected?
> Should I have used Taiga in the first place to ask about updating
> the links in the repository?
> 
> 
> Cheers,
> -- 
> Victor Grousset/tuxayo
>   
> 

Please do not send HTML mail to a mailing list. (Or, ideally, at all).

Peter Harpending


signature.asc
Description: Digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] PSA: Latest version of stack breaks sdb

[Peter Harpending]

Hey, everyone,

The latest version of stack breaks sdb, so don't update stack until
<https://github.com/commercialhaskell/stack/issues/1957> is fixed.

Peter Harpending



pgp1t7WZ0yGVv.pgp
Description: PGP signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Mechanism implementation

[Peter Harpending]

On 03/14/2016 05:10 PM, Bryan Richter wrote:
> 1. I'm not sure the Eq instances of MechPatron and MechProject are
> sound. As defined, `==` is the moral equivalent of checking that the
> two values cannot both exist in the database at the same time
> (database uniqueness), but that's not quite the same thing as being
> the same value.

So, I think I redid this between when you wrote this review and
now. Now, the `Eq` instance makes sure the external keys are equivalent.

instance Eq MechPatron where
m1 == m2 = mechPatronExternalKey m1 == mechPatronExternalKey m2

instance Ord MechPatron where
compare = comparing mechPatronExternalKey

instance Eq MechProject where
m1 == m2 = mechProjectExternalKey m1 == mechProjectExternalKey m2

instance Ord MechProject where
compare = comparing mechProjectExternalKey

The reason I wanted to do this is so that `compare` would return `EQ`
iff `(==)` would return `True`. I can't remember why I wanted to sort
them? I think I wanted to put them in a `Set` (from the `containers`
package), and to do any nontrivial `Set` operations, the inner type must
be an instance of `Ord`.

`HashSet` or whatever from `unordered-containers` doesn't require the
inner type to have an `Ord` instance, however is does require a
`Hashable` instance, which might actually not be that bad. Sets in
mathematics do not require the concept of ordering, so `containers`
seems like an affront to basic mathematical decency. It's almost as bad
as there existing a `w : Word` such that `w + 1 = 0`.

Mathematical decency aside, I'll look in to this.

> 3. I don't think the concept of a suspended patron is necessary yet.
> I could be misremembering, but I'm pretty sure one is either a patron
> or one is not.

This is me attempting (poorly) to think ahead. The concept of a pledge
being suspended because of insufficient funds is necessary (or we could
just delete the pledges, but that seems sort of mean). Moreover, I can
imagine that Patrons would want to prioritize the projects, so if they
can only afford projects X, Y, and Z, they can exclude project W
temporarily if they want.

> 5.
>
>> he = it
>
> I get it, but it provides very little compared to the damage it
> could cause.

What damage is that? Other than quasi-feminist stuff? Would it be better
if I wrote `he = specify`?

> 6. The stuff I wrote for doing tests against a database was intended
> to be abstracted out into a standalone library. I'll still do that.
> I guess you had to rewrite it to be able to use HSpec, though, so
> *shrug*
>

FWIW, your tests are still there, in the `chreekat` directory. I sort of
ported them over to HSpec, and then figured out a rather novel way to
abuse the concept of property-based testing.

___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] GH-144 and the construction of the test suite

[Peter Harpending]

Hey, y'all!

I am Peter, pharpend in the channel. For a while, I've been spending
some spare time working on GH-144:
. I thought it
was a trivial issue that would take 20 minutes to fix, but it turns out
to be symptomatic of a much larger problem.

There are two sides to it:

1. Logged-in users can create a new user in /u/new.
2. Logged-in users can view /auth/login without trouble.

The fix to the first problem was pretty easy: put a clause in
UserCreateR to 400 if the user is already logged in, as seen here:
. See
 for
more details.

The second turned out to be an issue with yesod-auth, which the Yesod
people are now working on:
.

The problem: fixing the first half caused half the tests to fail, mostly
because they were structured poorly. Here, there's a seemingly innocuous
test that dictates that users should be able to create a new user:


However, that test is incorrect, and by GH-144 should fail. I couldn't
figure out a way to make it pass, so Bryan suggested I remove
it. However, it turns out that other tests depend on that first test
passing. Essentially, further tests log in as the users created during
that test.

This is bad, because each test should be independent: a test passing
should not depend on other tests passing.

So, we need to do one of three things:

1. Ignore GH-144 for the time being.
2. Figure out some hack so that the test in question passes.
3. Rewrite the test suite so that silly things like that don't happen.

I think (3) would be the best option, but it would require a lot of
dedicated effort. I know that rewriting the test suite is a fairly
high-priority item, and probably a necessity before we reach a full
release.

I would like everyone's thoughts on the matter before I go raining on
everyone's parade.

Peter



pgpWKxxzb2kRk.pgp
Description: PGP signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] GitLab CI

[Peter Harpending]

On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?

From reading the page, it sounds like *every* instance of GitLab will
have that, it's just a matter of whether or not it is enabled.

Peter Harpending


pgpuRQYADhrrY.pgp
Description: PGP signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev