Re: [Snowdrift-dev] errors trying to build from arch linux

2017-12-13 Thread Jason Harrer 
Schwt

All we need now is confirmation from someone on *bunts/Debian.

Bryan, you may want to test on MixOS as well.

On Dec 13, 2017 19:10, "Christian"  wrote:

> Hi Jason,
>
> It builds now!  No issues here anymore.
>   -Christian
>
> On Wed, 13 Dec 2017 10:44:59 -0600
> Jason Harrer  wrote:
>
> > Hello, all -
> >
> > I went ahead and made some changes to hopefully resolve all of the
> > issues on Arch/Parabola.  One of the joys of the bleeding edge
> > distros is that we find errors first.  :)
> >
> > You can find the changes on a WIP MR @
> > https://git.snowdrift.coop/sd/snowdrift/merge_requests/98
> >
> > I'd like to ask Christian to switch to the new branch and attempt to
> > build from scratch to see if there are any issues on Arch that I may
> > not have caught.  I'd also like to ask others on *buntu/Debian to
> > attempt to build the branch from scratch (including "./sdb.hs clean
> > && ./sdb.hs start") to ensure I didn't unintentionally break anything
> > for others.
> >
> > Once I know it's working on the various distros, I can make a slight
> > modification (see MR notes) and remove the WIP indicator.
> >
> > Thanks!
> >
> > On Tue, Dec 12, 2017 at 7:17 AM, Jason Harrer 
> > wrote:
> >
> > > I'm on Parabola and had the same issue as well.  I found a dirty
> > > hack that works for me, at least until I have time to play around
> > > and find a better solution.  At
> > > https://stackoverflow.com/questions/41365866/installing-
> > > zlib-using-stack-recompile-with-fpic they mention a hack in the ghc
> > > settings under the .stack/ directory within the project.  If you
> > > follow those steps to disable PIE, then it should compile.
> > >
> > > I will note that we are looking in moving away from Stack and moving
> > > closer to Nix, which is the package manager for NixOS but works on
> > > all distros.  By using such a package manager, we can hopefully
> > > create a system whereby the code will work on any distro without
> > > having to have special hacks on each one.  This is one of the
> > > reasons I haven't sought out a better solution, though it may not
> > > be a bad idea to figure this out for Stack so future folks don't
> > > have the same issue while we transition.
> > >
> > > Thanks for bringing this up!
> > >
> > > On Mon, Dec 11, 2017 at 9:23 PM, Christian 
> > > wrote:
> > >
> > >> So, I've tried following the instructions listed here:
> > >> https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md
> > >> but I'm getting hung up on both "./build.sh test" and the
> > >> troubleshooting command "./sdb.hs clean".  Both give errors with
> > >> the "clock" library.  I believe the relevant errors are the
> > >> following:
> > >>
> > >> Clock.hsc:44:0: warning: "hsc_alignment" redefined
> > >> In file included
> > >> from .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/bu
> > >> ild/System/Clock_hsc_make.c:1:0: /home/christian/.stack/program
> > >> s/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/
> template-hsc.h:88:0:
> > >> note: this is the location of the previous definition #define
> > >> hsc_alignment(t...) \
> > >> /usr/bin/ld: .stack-work/dist/x86_64-linux-
> tinfo6-nopie/Cabal-1.24.2.0/bu
> > >> ild/System/Clock_hsc_make.o:
> > >> relocation R_X86_64_32 against `.rodata' can not be used when
> > >> making a shared object; recompile with -fPIC /usr/bin/ld: final
> > >> link failed: Nonrepresentable section on output
> > >>
> > >> This is done via arch linux, with the recommended packages
> > >> installed.
> > >>
> > >> Let me know if any specific information could be helpful, and
> > >> sorry for the trouble.
> > >>   -Christian
> > >> ___
> > >> Dev mailing list
> > >> Dev@lists.snowdrift.coop
> > >> https://lists.snowdrift.coop/mailman/listinfo/dev
> > >>
> > >
> > >
> ___
> Dev mailing list
> Dev@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/dev
>
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] errors trying to build from arch linux

2017-12-13 Thread Christian 
Hi Jason,

It builds now!  No issues here anymore.
  -Christian

On Wed, 13 Dec 2017 10:44:59 -0600
Jason Harrer  wrote:

> Hello, all -
> 
> I went ahead and made some changes to hopefully resolve all of the
> issues on Arch/Parabola.  One of the joys of the bleeding edge
> distros is that we find errors first.  :)
> 
> You can find the changes on a WIP MR @
> https://git.snowdrift.coop/sd/snowdrift/merge_requests/98
> 
> I'd like to ask Christian to switch to the new branch and attempt to
> build from scratch to see if there are any issues on Arch that I may
> not have caught.  I'd also like to ask others on *buntu/Debian to
> attempt to build the branch from scratch (including "./sdb.hs clean
> && ./sdb.hs start") to ensure I didn't unintentionally break anything
> for others.
> 
> Once I know it's working on the various distros, I can make a slight
> modification (see MR notes) and remove the WIP indicator.
> 
> Thanks!
> 
> On Tue, Dec 12, 2017 at 7:17 AM, Jason Harrer 
> wrote:
> 
> > I'm on Parabola and had the same issue as well.  I found a dirty
> > hack that works for me, at least until I have time to play around
> > and find a better solution.  At
> > https://stackoverflow.com/questions/41365866/installing-
> > zlib-using-stack-recompile-with-fpic they mention a hack in the ghc
> > settings under the .stack/ directory within the project.  If you
> > follow those steps to disable PIE, then it should compile.
> >
> > I will note that we are looking in moving away from Stack and moving
> > closer to Nix, which is the package manager for NixOS but works on
> > all distros.  By using such a package manager, we can hopefully
> > create a system whereby the code will work on any distro without
> > having to have special hacks on each one.  This is one of the
> > reasons I haven't sought out a better solution, though it may not
> > be a bad idea to figure this out for Stack so future folks don't
> > have the same issue while we transition.
> >
> > Thanks for bringing this up!
> >
> > On Mon, Dec 11, 2017 at 9:23 PM, Christian 
> > wrote:
> >  
> >> So, I've tried following the instructions listed here:
> >> https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md
> >> but I'm getting hung up on both "./build.sh test" and the
> >> troubleshooting command "./sdb.hs clean".  Both give errors with
> >> the "clock" library.  I believe the relevant errors are the
> >> following:
> >>
> >> Clock.hsc:44:0: warning: "hsc_alignment" redefined
> >> In file included
> >> from .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/bu
> >> ild/System/Clock_hsc_make.c:1:0: /home/christian/.stack/program
> >> s/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/template-hsc.h:88:0:
> >> note: this is the location of the previous definition #define
> >> hsc_alignment(t...) \
> >> /usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/bu
> >> ild/System/Clock_hsc_make.o:
> >> relocation R_X86_64_32 against `.rodata' can not be used when
> >> making a shared object; recompile with -fPIC /usr/bin/ld: final
> >> link failed: Nonrepresentable section on output
> >>
> >> This is done via arch linux, with the recommended packages
> >> installed.
> >>
> >> Let me know if any specific information could be helpful, and
> >> sorry for the trouble.
> >>   -Christian
> >> ___
> >> Dev mailing list
> >> Dev@lists.snowdrift.coop
> >> https://lists.snowdrift.coop/mailman/listinfo/dev
> >>  
> >
> >  
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

2017-12-13 Thread Aaron Wolf 
On 12/13/2017 11:28 AM, Bryan Richter wrote:



Two comments:

> Buffers can't exist in a system that has no account balances. The
> volatility gets pushed to the question of "Does the patron have enough
> money in their actual bank account."
> 

I want it to go through a User Story / consent / design process, but
sometime we'll discuss this. There's no technical requirement of a
buffer, it's a UX and system-design question. It relates to whether
signing up for crowdmatching should actually serve to invite and match
further new patrons. It may be unnecessary or early optimization.
Anyway, it can be dropped from this topic now.

>> I'll stop here except to reiterate: what about doing budget calculations
>> at the time of pledging? I thought that would be effectively the only
>> thing needed. Then the crowdmatch and payment events would be at most
>> just extra checks to be triple-sure to respect budgets…
> 
> Yeah, doing them at pledge time is probably going to be required.
> 

That sounds like what David said too when I talked to him about this. He
had a moment last weekend to at least look at things and think about
Snowdrift code stuff. This could be a good place to hand off a little
coding task(s) to him if you can delineate clearly. He understands the
issues pretty well and may be able to help or at least discuss the
implementation…



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

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

2017-12-13 Thread Bryan Richter 
On 11/16/2017 12:29 AM, Aaron Wolf wrote:
> On 11/07/2017 04:34 AM, Bryan Richter wrote:
>>
>> Having multiple projects means it becomes more complicated to see if
>> someone has gone over their budget. We'll need to account for that.
>
> We discussed this a while back. I'm going to summarize again here some
> basic (maybe obvious) factors.
>
> 

As you said in the other email on this thread, I think the most
important adjustment to my plan is making sure that a pledge to
project A only affects other pledges to project A. I agree with that
requirement. I'll think through the implementation ramifications and
come up with a modified plan.

>> -  Tasks for enabling multiple projects
>> -  Dev tasks
>> -  Modify tests to assume multiple projects
>> -  Create new Project table (id, handle, donations_received)
>> -  Create new Pledge table,   user <*--*> project
>> -  Deprecate pledge_since
>
> Why deprecate pledge_since? Certainly we don't want to lose the
> information about how long someone has been a patron. Also, my idea (not
> sure it's strictly the best though) to check in order from oldest to
> newest pledge would seem to use some information like this.

I was unclear there. Definitely keeping that info. It's just going to
be part of the Pledge table instead of the Patron table.

> ### concerns
>
> If multiple patrons hit their budgets at the same time (say they pledge
> to the same set of projects), who gets dropped first?

It can't happen at the *same* time - each pledge is atomic. It might
be too fast for human comprehension, but the system will have a notion
of ordering, so it'll use that to drop them.

> If a patron with a dropped pledge decides to drop a different pledge in
> order to reinstate the dropped one, I guess any patrons who also support
> the same two projects would be budget-wise unaffected since they would
> just reduce their level for one and increase for the other.

It would only totally unaffect patrons who are also pledged to both
projects. If someone gets dropped from A and chooses to pledge to B
instead, patrons pledged to B (but not A) could get dropped. But there
is no reason to consider this a special scenario. It's two unrelated
pledge+drops, only tenuously connected because the drop-ee in one
scenario is the pledger in another.

> BUFFER: to keep things from being too volatile, we've had this concept
> for a long time that there should be some buffer remaining in a patron's
> budget in order to add a new pledge. Keep that in mind (and consider
> implementation plans).

Buffers can't exist in a system that has no account balances. The
volatility gets pushed to the question of "Does the patron have enough
money in their actual bank account."

> I'll stop here except to reiterate: what about doing budget calculations
> at the time of pledging? I thought that would be effectively the only
> thing needed. Then the crowdmatch and payment events would be at most
> just extra checks to be triple-sure to respect budgets…

Yeah, doing them at pledge time is probably going to be required.



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

Re: [Snowdrift-dev] errors trying to build from arch linux

2017-12-13 Thread Jason Harrer 
Hello, all -

I went ahead and made some changes to hopefully resolve all of the issues
on Arch/Parabola.  One of the joys of the bleeding edge distros is that we
find errors first.  :)

You can find the changes on a WIP MR @
https://git.snowdrift.coop/sd/snowdrift/merge_requests/98

I'd like to ask Christian to switch to the new branch and attempt to build
from scratch to see if there are any issues on Arch that I may not have
caught.  I'd also like to ask others on *buntu/Debian to attempt to build
the branch from scratch (including "./sdb.hs clean && ./sdb.hs start") to
ensure I didn't unintentionally break anything for others.

Once I know it's working on the various distros, I can make a slight
modification (see MR notes) and remove the WIP indicator.

Thanks!

On Tue, Dec 12, 2017 at 7:17 AM, Jason Harrer 
wrote:

> I'm on Parabola and had the same issue as well.  I found a dirty hack that
> works for me, at least until I have time to play around and find a better
> solution.  At https://stackoverflow.com/questions/41365866/installing-
> zlib-using-stack-recompile-with-fpic they mention a hack in the ghc
> settings under the .stack/ directory within the project.  If you follow
> those steps to disable PIE, then it should compile.
>
> I will note that we are looking in moving away from Stack and moving
> closer to Nix, which is the package manager for NixOS but works on all
> distros.  By using such a package manager, we can hopefully create a system
> whereby the code will work on any distro without having to have special
> hacks on each one.  This is one of the reasons I haven't sought out a
> better solution, though it may not be a bad idea to figure this out for
> Stack so future folks don't have the same issue while we transition.
>
> Thanks for bringing this up!
>
> On Mon, Dec 11, 2017 at 9:23 PM, Christian 
> wrote:
>
>> So, I've tried following the instructions listed here:
>> https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md
>> but I'm getting hung up on both "./build.sh test" and the
>> troubleshooting command "./sdb.hs clean".  Both give errors with the
>> "clock" library.  I believe the relevant errors are the following:
>>
>> Clock.hsc:44:0: warning: "hsc_alignment" redefined
>> In file included
>> from .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/bu
>> ild/System/Clock_hsc_make.c:1:0: /home/christian/.stack/program
>> s/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/template-hsc.h:88:0:
>> note: this is the location of the previous definition #define
>> hsc_alignment(t...) \
>> /usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/bu
>> ild/System/Clock_hsc_make.o:
>> relocation R_X86_64_32 against `.rodata' can not be used when making a
>> shared object; recompile with -fPIC /usr/bin/ld: final link failed:
>> Nonrepresentable section on output
>>
>> This is done via arch linux, with the recommended packages installed.
>>
>> Let me know if any specific information could be helpful, and sorry for
>> the trouble.
>>   -Christian
>> ___
>> Dev mailing list
>> Dev@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/dev
>>
>
>
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev