#techempower-fwbm

there we go

boom!

so I will cancel the current build

boom?

alex brought the boom...

also, I may be a bit drunk

attakid

it's 9am here, I hope that it's the morning where you are as well

alex-techempower: i see that travis has marked our build as 'canceled'

how do I kick a new one off?

TE-msmith: I think we just let it do it

oh

okay

cancel builds 1 through 3 though

how?

ps - because we have such a large matrix for each build, you may have to hit cancel two or three times

See https://travis-ci.org/TechEmpower/FrameworkBenc...

there should be a cancel button on the top right

crap

I accidentally hit the restart

>_<

all right

how are you able to access this?

lol

should be canceled

TE-msmith: I don't know

maybe because i'm a collaborator?

TE-msmith: did you sign in?

I think I can just cancel builds

to travis-ci.org

yeah, I'm signed in

Hmm

i see builds 1-3 are canceled

build 4 is yellow

Perhaps ask the guys over in #travis how to use travis with a team?

but the "current build" is #1

refresh

Yea just give it a minute

we are in their peak load time

Also, they currently have a minor issue on travis-ci.com, not sure if it's affecting .org

[FrameworkBenchmarks] jyentechempower pushed 1 new commit to master: http://git.io/weB_eA

FrameworkBenchmarks/master 7da5f82 James Yen: If OS is windows avoid replace environ.

See http://status.travis-ci.com/ for their status...it's updated regularly

Hey alex-techempower, something to be aware of

you guys are either going to need to start using "[ci skip]" in your commit messages, or do a lot of cancelling

you probably don't want to run a full build but once per day

yea

I'll let jyen know

solid

it'll take some time to get everyone used to it

or you'll be cancelling a lot for the first week...

yea

I wish we could opt in to builds

rather than opting out

yea, I mentioned that in my pull request

I could scan the commit messages for an opt-in flag

I just thought that for the first week it makes more sense to opt out

ah

all right

becuase no one would know the flag...so they wouldn't know what they were missing

but yea...I think just looking for *any* change in toolset/ is way to aggressive for long term use

the project is probably going to stagnate for the next couple of weeks, so if you want something to be merged that you think is important, you need to get it in today or tomorrow

mk

im just going to be fixing one-offs for a bit i think

all right

cool, it works

you only touched .travis.yml in your commit

so it's cancelling all of the jobs ;-)

hamiltont: so I need to touch the framework-test.py?

yea

that or anything inside toolset/

then sit back and wait for ~5 hours ;-)

I wasn't really able to test this with pull requests, so I'm not sure how those will be handled yet

that'll be interesting

but they should just be cloned/checkedout and then build

it might take some minor fixing to get that to ideal

[FrameworkBenchmarks] jyentechempower pushed 1 new commit to master: http://git.io/KEMjjg

FrameworkBenchmarks/master b0dc6fe James Yen: [ci skip]...

thar we go

hello, is there any room left for running Windows tests, because it seems that the new updates come with the implicit assumption that the OS is Linux

hamiltont: ^^

for example the stop method in framework_test.py relies on a relative directory method, which needs a Linux OS

and the new replace environ thingy is implicit in its Linux need

^the above sentence is probably not good english

rofl

looking...

jyenTE: by relies on a relative directory method, are you referring to "setup_util.path_relative_to_root"

If so, that could be generalized to any OS by using os.path.relpath inside of path_relative_to_root

This is indicitative of the current master situation I'm afraid - many changes are linux-only, but they have been done in such a way that you can add windows support in one place and it will be used everywhere

I just don't know anyone making major contributions to support windows at the moment. If you're interested I'd be happy to offer what advice I can as you're coding, but every environment I have is linux so I can't do more than talk :-/

hamiltont: there really isn't - most of the ASP.NET tests fail anyway

and though there's a few PRs, none of them fix it

Yea...nothing that's been changed recently would prohibit using windows

but AFAIK there's just no one working on it

we're trying to get the benchmark suite working on windows - some people consider servers running on windows to be statistically significant

it would definitely be relevant

stackoverflow runs IIS on windows I think

(for part of their stuff, not all of it obviously)

hamiltont: I noticed you made a few commits R.E. gh#927

Benchmarker does not properly terminate child processes: https://github.com/TechEmpower/FrameworkBenchma...

is that in a PR right now?

I think that's something we're interested in merging soon as well

I could refactor them into an isolated PR

although to be honest

the fact that windows calls __run_test as a function and linux calls __run_test as a process has been one of the major stikcing points

I'm not even sure why windows does that, I haven't found a solid answer on why there was a comment saying "windows doesnt have these features" when multiprocessing explicitely works cross-platform

So I've been holding off putting in major changes to how __run_tests calls __run_test, even though I know I can clean it up a lot on linux

because I don't know what I'm potentially breaking

that's a good TE-msmith question, although what we've been doing is just having all the windows set in a conditional block that says "if os == windows, use this, else, use this"

but windows is already broken ;)

Yea, unfortunately the subprocess vs not makes just using conditionals harder

for example, multiprocessing shouldn't be used with "except KeyboardInterrupt"

it currently is in master, which breaks Ctrl-C quite a bit for me

but it's there for a reason - to stop the test cleanly

I would just move that 'stop cleanly' into __run_tests and abolish the except in the subprocess, but that's requires special code when using a process that would interfere with the code that's just calling a function

its a mess :-/

I'm leaning towards just standardizing on multiprocess in __run_tests and fixing things for linux

hah

understatment of the year

and letting someone figure out windows if they want to

but as jyenTE bring up, it already looks from the outside like we can't run windows. At the moment that's not really true - the only changes needed are minor

without knowing why we were not using multiprocessing on windows, I may be causing semi-permanent damage to our ability to ever use windows

so yea...I've thought about it a little bit :-P

TE-msmith: may be able to provide some input hopefully

hamilton would it be possible to replicate all of the setup_util functions such that they do the same thing on Windows?

or I guess what I'm saying is, the entire test sequence that we have now, is it possible to replicate that same thing on Windows?

like the replace environ and so on and so forth for Windows

forgive my ignroance

wat

It definitely is, that was one main point of moving some complex shell functions into setup_util - if someone wants to add windows support they just need to update the internals of the functions in setup_util

SUH WEEET

TE-msmith: hamiltont had some questions about the implementation decisions that we made for windows

such as?

jyenTE: but someone still has to do that wokr and test it on windows

TE-msmith: mind reading the discussion above? It was a lot of typing ...

jyenTE: *hint* *hint*

yes I will be doing that today

will stay in this room and ping for help if needed!

Sounds great!

THUNDERCATS R GOO

TE-msmith: I think he was referring to https://github.com/TechEmpower/FrameworkBenchma...

and why we used multiprocessing on windows

jyenTE: I think the hardest part may be handling the 'command' parameter to replace_environ. In a number of places I'm using the bash && operator to pass in multiple commands. The windows command shell doesn't support that I think

So you would likely need to split the command string by the '&&' pattern inside of replace_environ to handle that case

Perhaps hardest is not the right work, it's just a bit tricky

as to why we do things differently on windows

no idea

TE-msmith: Darn

I inherited this code from a colleague who left the company