#techempower-fwbm

[FrameworkBenchmarks] hamiltont pushed 21 new commits to master: http://git.io/8mCUDQ

FrameworkBenchmarks/master 5253166 Gerard Roche: Add Zend Framework 1; similar to the 2.0 version https://github.com/TechEmpower/FrameworkBenchma...

FrameworkBenchmarks/master d75b930 Gerard Roche: :bug: Fix weird zf-tool `create project` produces mangled characters

FrameworkBenchmarks/master 620c1fd Gerard Roche: Add Ant script lint checker; be double sure there are no silly syntax errors

[FrameworkBenchmarks] hamiltont pushed 2 new commits to master: http://git.io/saFaGA

FrameworkBenchmarks/master 202ab37 Gerard Roche: Fix zend framework 2 db multi queries should default to min/max 1/500...

FrameworkBenchmarks/master 7064c54 Hamilton Turner: Merge pull request #1148 from gerardroche/zf2-fix-db-multi...

TE-msmith: online?

yabro, sup

Re gh#1150

Dropwizard/plaintext resource now returning precomputed byte array: https://github.com/TechEmpower/FrameworkBenchma...

I had alex pull your branch and start that work

the "__killProcess" thing

but go on

FAIL for http://127.0.0.1:9000/db?queries=foo is a failure because there is no response (the FW threw an exception)

You're correct that this one should be a warning: "FAIL for http://127.0.0.1:9000/db?queries=501";

nice

but I feel that an empty response should be a failure

no?

it should be

well

depends on the test

?queries=501/foo returning empty should be a warning

empty as in HTTP 500?

(that's what happened here IIRC)

either a 200 with an empty body or a 500

e.g. not empty as in []

I understand

for this round, that should be a warning

ok

has alex made any substantial progress on my branch? I was thinking of trying to knock it out later today

not really

but if he's got it then I'll abstain

I think he implemented the method I suggested, but I don't know the state of testing

aight, I'll see if I can wrap it up

I think you can basically copy/paste what I have there, add `out` and `err` as function parameters, and it should be good to test

I still cannot test (damned windows machine)

wait, i might be able to test

sec

I'm actually kind of confused about that line ending stuff - doesn't the project already use windows line endings?

no

the project uses system line endings locally

huh

ok

I'm a bit out of my depth, haven't dealt with line ending problems in years and I remember being frustrated :-p

that setting of "autocrlf true" means that when you clone the code, you will replace whatever line endings are on the remote with your system's endings, and when you push, it will change them back

so here's the problem

I clone the code on my Windows box with autocrlf=true, it sets the line endings of everything to \r\n

I use `vagrant up`

it copies over the files verbatim

when I try to do ANYTHING with the toolset, I get parse errors from the linux python interpretter because \r is an invalid char

So there's no setting we can enable in linux to make it understand /r/n?

not really, but we don't want to do that anyway

there are unix tools for converting: dos2unix and unix2dos

essentially, we just want to ensure that this is part of the process

Would you need to do it for the python files too?

Or does it not care?

For what it's worth, you could try adding this to vagrant-common/bootstrap.sh : "find ~/FrameworkBenchmarks -name "*.sh" -exec dos2unix {} \;

"

Although I'm not convinced that the git program would not suddenly detect that you had changed every single bash file. I'm not sure if the autocrlf setting let's it totally ignore changes in line endings and just commit the proper type

^

so here's my thought

:-(

we need to change the vagrant setup

or... I dunno

I see two options

1) when copying the files from local to vagrant, replace the line endings a la dos2unix on the vagrant system

the problem here is that if it's a shared drive, then that will also change the host environment - undesirable

2) change the vagrant script to clone the repo

the problem here is that development will have to be done in 2 places (one on vagrant to test and one on local to create a PR)

am I missing anything?

I know you don't seem to like this, but option 3 may be:

3) Tell users to clone with autocrlf off, which means they will get TFB's linux line endings in windows. This isn't an issue if they are only running the scripts inside vagrant, and I would hope most powerful windows editors can support preserving original line endings

the reason I'm against this is because most windows users will clone before they read anything

I can add in option (2) fairly simply, just by making it another option like the ones here: https://github.com/TechEmpower/FrameworkBenchma...

Something like "TFB_VB_NOMOUNT=true vagrant up"

I'm just not sure I like any of the options here

let me ping brianhauer and see if keith has any input

Well we can have (1) be fallback behavior e.g. check host OS and line endings inside the vagrant script, and if they don't match we can automatically print a big warning that (3) is preferred but we will run the conversion for them

Oh - we can add a .gitattributes file to our project's root that will override the autocrlf setting the user has by default

That might help

will that override the global attr?

if that's true, I think I'd like that as the simplest solution

Yes according to https://help.github.com/articles/dealing-with-l...

Does powershell understand CRLF?

who edits in powershell?

again, I'm pandering to the lowest common denominator

ah, brain fart. Ignore that sentence ;-)

if the windows user is editing on a vanilla installation, they would be using notepad - that doesn't understand anything but /r/n

so what would you want to set using this git attributes file?

I would need to research it

but basically lock the line-endings to /n

Agreed.

so it "just works" for linux users and windows users might have to deal with some minor pain

If they can't at least bump to pspad...

I mean, we would be helping them out anyways ;-)

if you create a branch, I can clone it to test the vagrant setup

Sure. Are bash files the *only* problem?

or does python have the same issue

both

presumably ALL files might succumb to this

so we should just default ALL file's line-endings to /n

Ok, so we start with a global setting

nnnnno

because I have so many projects that use autocrlf=true

can we make it project-wide?

replace "global" with "*"

I forgot global was the word git uses to describe config

yeah

I'm saying we start with this in the attributes file for TFB : "* text eol=crlf"

that doesn't fix anything

"* text eol=lf"

grr..damn typos

that's the linux way, yeah?

yea

sorry

ok ok

gotta jump on a quick call, brb

I'm just gonna go make the branch

k

TE-msmith: newlines-1147 is the branch in my repo: https://github.com/hamiltont/FrameworkBenchmark...

If you follow the directions at https://help.github.com/articles/dealing-with-l... then don't push directly to master - make sure you do a PR

Mostly because that "git add . -u" can do some unexpected things in our repo

back!

so wait wat

okay... confused

You should be able to clone my repo locally to your windows machine, then cehckout that branch

here's what I'm thinking for testing

right

then do the directions in that article?

If you have to

it might just work

not sure TBH

well, unless your master is the branch with the correct line-endings, my global autocrlf=true

so it'll prolly have my line-endings

meaning I'll need to check out your branch, which will likely tell me all my files are modified

we'll see - i'm cloning

I think you're right

so many MiB