Re: [Snowdrift-dev] Attacked by Space Bug

2017-09-12 Thread Henri Jones
> *Quick aside: What does the dbenv subroutine do? I wanted to put in a comment 
> explaining its function, but it was not readily apparent to me.

dbenv() starts the postgres server and sets database related environment 
variables.

Did you see my comment here: 
https://git.snowdrift.coop/sd/snowdrift/issues/66#note_2110 ? I haven't tried 
to verify it yet, but that's where I think the problem is. It looks like those 
exports are not properly escaped (PGHOST and PGDATA are paths, if I remember 
correctly).___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Snowdrift-dev] Attacked by Space Bug

2017-09-12 Thread Victor/tuxayo
Hi :) ,

On 2017-09-12 19:47, jake wrote:
> My next step is to learn what version of GHC Stack uses to build Yesod.
> If it's less than 7.4, we may have an answer (see article). If not, we
> may have an adventure.
> 
> So, could someone please instruct me on how to obtain that version number?

According to stack.yaml [1] we use the lts-8.24 resolver.

According to https://www.stackage.org/lts-8.24 it contains ghc-8.0.2


Also after a build, searching .stack/ folder for "ghc-" returns:
$ find .stack-work -iname "*ghc-*"
.stack-work/install/x86_64-linux-nopie/lts-8.24/8.0.2/lib/x86_64-linux-ghc-8.0.2
.stack-work/install/x86_64-linux-nopie/lts-8.21/8.0.2/lib/x86_64-linux-ghc-8.0.2
# ← this is from when we where on lts-8.21


I have only a superficial understanding of this but it seems safe to say
that we use ghc-8.0.2


Cheers,

-- 
Victor/tuxayo

[1] https://git.snowdrift.coop/sd/snowdrift/blob/master/stack.yaml#L4
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


Re: [Snowdrift-dev] Attacked by Space Bug

2017-09-12 Thread jake
Sorry to break this news right as you're entertaining the idea of an alpha 
release, but Issue #66 is bigger than just a Bash script failing to quote 
things.

This article has a chance of being relevant, but only a chance.

My next step is to learn what version of GHC Stack uses to build Yesod. If it's 
less than 7.4, we may have an answer (see article). If not, we may have an 
adventure.



So, could someone please instruct me on how to obtain that version number?


I went through build.sh and applied quoting where there should be. I also added 
comments to explain what's going on.

The trickiest part about quoting build.sh was the "change directory" part, 
which I explain in the script as a comment.



*Quick aside: What does the dbenv subroutine do? I wanted to put in a comment 
explaining its function, but it was not readily apparent to me.



Anyhow, my copy of that build script is now thoroughly quoted, I mean 100%.



There is only one other Bash script in the project, keter.sh.

To be safe, on line 51 of keter.sh, I inserted escaped quotes around 
$install_path. This is so the stack executable receives its --local-bin-path 
argument in quotes, so that stack interprets the path as one argument.


So, what we're down to now is: a Stack bug, a Yesod bug, a GHC bug, or some 
combo thereof.

I'm talking about what build.sh launches just after the "cd" part.



In debugging, it may be useful to know that both halves of the 
incorrectly-parsed filepath string are used.

Some other shell that got spawned to /dev/fb/63 (at least on my machine) 
complains:

/dev/fd/63: line 1: export: `One/snowdrift/.postgres-work/sockets': not a valid 
identifier/dev/fd/63: line 2: export: `One/snowdrift/.postgres-work/data': not 
a valid identifier




Later down, devel.hs complains:

devel.hs: libpq: failed (could not connect to server: No such file or directory

Is the server running locally and accepting

connections on Unix domain socket 
"/run/media/jthomas/Backup/.s.PGSQL.5432"?

)




Recall that my path is "/run/media/jthomas/Backup One/snowdrift", with emphasis 
on the "Backup One" part.

The first complaint above picks up from the "One" part, whereas the second 
complaint goes all the way through the "Backup" part, skips the space and the 
"One", then appends a filename. 


I haven't done any git stuff for this project yet, so if you're dying to see 
all this right now, I've attached my modified build.sh.



Also, in case it interests anybody, I attached some explanatory Bash scripts. 
They go over $@ and argument quoting. They show how to make sure your apparent 
arguments really are the arguments.

If anyone joins this project and is new to Bash, these scripts may come in 
handy.



-Jake









 On Mon, 11 Sep 2017 04:40:23 -0700 Bryan Richter 
 wrote 




> On 09/11/2017 08:00 AM, Peter Harpending wrote: 

>> On Sep 10, 2017 11:27 PM, "jake" wrote: 

>> 

>> Hello, I'm Jake. I'm brand new here. In summary, I want "real 

>> world" Haskell experience. (Long version sent to 

>> commun...@snowdrift.coop ;.) 

>> 

>> I tried to build the test platform, but encountered a classic 

>> bug: the space bug. 

>> 

>> Easy to replicate: make a directory with a space in its name, 

>> such as "foo bar". In my case, it was "Backup One". Navigate 

>> (cd) your terminal to this place. Follow the build instructions 

>> in BUILD.md, starting with the "git clone..." line. 

>> 

>> Well, something in the build script does not handle that space. 

>> 

>> Using my example with "Backup One", it expects a Unix socket to 

>> be at: 

>> 

>> /run/media/jthomas/Backup/.s.PGSQL.5432 

>> 

>> Notice the "/Backup/" part should be "/Backup One/". 

>> 

>> Furthermore, navigating to jthomas reveals that there is no 

>> "Backup" directory. So that file really does not exist. 

>> (Sometimes these things make the directories that they think 

>> should exist. Not in this case.) 

>> 

>> 

>> Cheers, Jake 

> Welcome. I'm Peter. 

> 

> If you want to get involved, this would be a good bug for you to 

> fix. It's relatively simple, and you already understand the issue. 

> 

> This would be a low priority issue for us as most developers don't 

> put spaces in file names, so this is unlikely to cause serious 

> issues 

> 



Hi Jake, welcome! 



Congrats, you ran into a "real world" bug. :) I created an issue to 

track it: https://git.snowdrift.coop/sd/snowdrift/issues/66 . 



Like Peter says, it's probably a good place to make a fix. 

Unfortunately it's likely a Bash bug, not a Haskell bug. Probably 

some variable in build.sh needs quoting. 



Build bugs are actually always important, so if you don't have a chance 

to get to this, I'll do it this week some time. 



Thanks! 



-Bryan 



___

Dev mailing list

Dev@lists.snowdrift.coop

https://lists.snowdrift.coop/mailman/listinfo/dev








b

Re: [Snowdrift-dev] Attacked by Space Bug

2017-09-11 Thread jake
Thank you. I'm happy to help anyway I can. I'll look more into it today.



Jake











 On Mon, 11 Sep 2017 04:40:23 -0700 Bryan Richter 
 wrote 




> On 09/11/2017 08:00 AM, Peter Harpending wrote: 

>> On Sep 10, 2017 11:27 PM, "jake" wrote: 

>> 

>> Hello, I'm Jake. I'm brand new here. In summary, I want "real 

>> world" Haskell experience. (Long version sent to 

>> commun...@snowdrift.coop ;.) 

>> 

>> I tried to build the test platform, but encountered a classic 

>> bug: the space bug. 

>> 

>> Easy to replicate: make a directory with a space in its name, 

>> such as "foo bar". In my case, it was "Backup One". Navigate 

>> (cd) your terminal to this place. Follow the build instructions 

>> in BUILD.md, starting with the "git clone..." line. 

>> 

>> Well, something in the build script does not handle that space. 

>> 

>> Using my example with "Backup One", it expects a Unix socket to 

>> be at: 

>> 

>> /run/media/jthomas/Backup/.s.PGSQL.5432 

>> 

>> Notice the "/Backup/" part should be "/Backup One/". 

>> 

>> Furthermore, navigating to jthomas reveals that there is no 

>> "Backup" directory. So that file really does not exist. 

>> (Sometimes these things make the directories that they think 

>> should exist. Not in this case.) 

>> 

>> 

>> Cheers, Jake 

> Welcome. I'm Peter. 

> 

> If you want to get involved, this would be a good bug for you to 

> fix. It's relatively simple, and you already understand the issue. 

> 

> This would be a low priority issue for us as most developers don't 

> put spaces in file names, so this is unlikely to cause serious 

> issues 

> 

 

Hi Jake, welcome! 

 

Congrats, you ran into a "real world" bug. :) I created an issue to 

track it: https://git.snowdrift.coop/sd/snowdrift/issues/66 . 

 

Like Peter says, it's probably a good place to make a fix. 

Unfortunately it's likely a Bash bug, not a Haskell bug. Probably 

some variable in build.sh needs quoting. 

 

Build bugs are actually always important, so if you don't have a chance 

to get to this, I'll do it this week some time. 

 

Thanks! 

 

-Bryan 

 

___

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] Attacked by Space Bug

2017-09-11 Thread Bryan Richter
> On 09/11/2017 08:00 AM, Peter Harpending wrote:
>> On Sep 10, 2017 11:27 PM, "jake" wrote:
>> 
>> Hello, I'm Jake. I'm brand new here. In summary, I want "real
>> world" Haskell experience. (Long version sent to
>> commun...@snowdrift.coop .)
>> 
>> I tried to build the test platform, but encountered a classic
>> bug: the space bug.
>> 
>> Easy to replicate: make a directory with a space in its name,
>> such as "foo bar". In my case, it was "Backup One". Navigate
>> (cd) your terminal to this place. Follow the build instructions
>> in BUILD.md, starting with the "git clone..." line.
>> 
>> Well, something in the build script does not handle that space.
>> 
>> Using my example with "Backup One", it expects a Unix socket to
>> be at:
>> 
>> /run/media/jthomas/Backup/.s.PGSQL.5432 
>> 
>> Notice the "/Backup/" part should be "/Backup One/".
>> 
>> Furthermore, navigating to jthomas reveals that there is no
>> "Backup" directory. So that file really does not exist.
>> (Sometimes these things make the directories that they think
>> should exist. Not in this case.)
>> 
>> 
>> Cheers, Jake
> Welcome. I'm Peter. 
> 
> If you want to get involved, this would be a good bug for you to
> fix. It's relatively simple, and you already understand the issue.
> 
> This would be a low priority issue for us as most developers don't
> put spaces in file names, so this is unlikely to cause serious
> issues
> 

Hi Jake, welcome!

Congrats, you ran into a "real world" bug. :) I created an issue to
track it: https://git.snowdrift.coop/sd/snowdrift/issues/66 .

Like Peter says, it's probably a good place to make a fix.
Unfortunately it's likely a Bash bug, not a Haskell bug. Probably
some variable in build.sh needs quoting.

Build bugs are actually always important, so if you don't have a chance
to get to this, I'll do it this week some time.

Thanks!

-Bryan



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


Re: [Snowdrift-dev] Attacked by Space Bug

2017-09-10 Thread Peter Harpending
Welcome. I'm Peter.

If you want to get involved, this would be a good bug for you to fix. It's
relatively simple, and you already understand the issue.

This would be a low priority issue for us as most developers don't put
spaces in file names, so this is unlikely to cause serious issues.

On Sep 10, 2017 11:27 PM, "jake"  wrote:

> Hello, I'm Jake. I'm brand new here. In summary, I want "real world"
> Haskell experience. (Long version sent to commun...@snowdrift.coop.)
>
> I tried to build the test platform, but encountered a classic bug: the
> space bug.
>
> Easy to replicate: make a directory with a space in its name, such as "foo
> bar". In my case, it was "Backup One". Navigate (cd) your terminal to this
> place. Follow the build instructions in BUILD.md, starting with the "git
> clone..." line.
>
> Well, something in the build script does not handle that space.
>
> Using my example with "Backup One", it expects a Unix socket to be at:
>
> /run/media/jthomas/Backup/.s.PGSQL.5432
>
> Notice the "/Backup/" part should be "/Backup One/".
>
> Furthermore, navigating to jthomas reveals that there is no "Backup"
> directory. So that file really does not exist. (Sometimes these things make
> the directories that they think should exist. Not in this case.)
>
>
> Cheers,
> Jake
>
> ___
> 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


[Snowdrift-dev] Attacked by Space Bug

2017-09-10 Thread jake
Hello, I'm Jake. I'm brand new here. In summary, I want "real world" Haskell 
experience. (Long version sent to commun...@snowdrift.coop.)



I tried to build the test platform, but encountered a classic bug: the space 
bug.



Easy to replicate: make a directory with a space in its name, such as "foo 
bar". In my case, it was "Backup One". Navigate (cd) your terminal to this 
place. Follow the build instructions in BUILD.md, starting with the "git 
clone..." line.



Well, something in the build script does not handle that space.



Using my example with "Backup One", it expects a Unix socket to be at:



/run/media/jthomas/Backup/.s.PGSQL.5432 



Notice the "/Backup/" part should be "/Backup One/".



Furthermore, navigating to jthomas reveals that there is no "Backup" directory. 
So that file really does not exist. (Sometimes these things make the 
directories that they think should exist. Not in this case.)





Cheers,

Jake

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