These are chat archives for dropbox/pyston

6th
Aug 2015
Rudi Chen
@rudi-c
Aug 06 2015 00:26
Would it make sense to have testing scripts in the main repo and only the submodules in a separate repo?
Kevin Modzelewski
@kmod
Aug 06 2015 00:38
yeah, though I think at that point the second repo isn't super useful
Rudi Chen
@rudi-c
Aug 06 2015 00:40
The main goal is just to avoid downloading all the testing subrepositories but still make it easy to get the building ones right?
Kevin Modzelewski
@kmod
Aug 06 2015 00:41
yeah, that's the immediate goal, though I thought having a clean separation might be nice
but that might have been a bit off
for example it's probably not good to have separation between the expected test results and the repo
Rudi Chen
@rudi-c
Aug 06 2015 00:45
Maybe as long as we always update the main repo before the test repo. The nice thing about having a separate testing repo is to have be strict about compatibility requirements, and in theory we would always bump the requirements "up" (e.g. removing an "expected fail").
The more troublesome case is if we need to bump the requirements down temporarily (to put an issue aside).
In that case the testing repo needs to be updated before the main repo.
Well I guess that's still fine.
Kevin Modzelewski
@kmod
Aug 06 2015 07:50
oh interesting, it looks like we can have travis-ci test our personal repos
so that we don't have to create PRs to run it through travis
not sure if there's a good way to do have fine-grained control though over what gets tested or not
you can put [ci skip] in the commit log but that seems like a pain since you have to go back and take them out
Sun
@Daetalus
Aug 06 2015 07:52
If I create a PR, travis-ci test it before merge or after merge?
Kevin Modzelewski
@kmod
Aug 06 2015 07:52
after merging
Travis Hance
@tjhance
Aug 06 2015 07:53
no way to be like “test commit xyz”?
Kevin Modzelewski
@kmod
Aug 06 2015 07:53
hmm maybe we could enable "build pull requests" but not "build pushes" and then you can just create PRs in your own fork
Sun
@Daetalus
Aug 06 2015 07:54
ok, thanks!
Kevin Modzelewski
@kmod
Aug 06 2015 07:54
or we could have a whitelist like "build master and anything of the form ci_*"
and then you can push the commit to a temporary ci_foo branch
Sun
@Daetalus
Aug 06 2015 07:55
#807 is a exciting thing!
Kevin Modzelewski
@kmod
Aug 06 2015 08:07
lots more things to fix that it uncovers :)
Kevin Modzelewski
@kmod
Aug 06 2015 08:28
also I think make check is still pretty comprehensive
it doesn't test quite all the same configurations
(I don't think it checks gcc)
but it does more than just quick_check
Sun
@Daetalus
Aug 06 2015 10:17
If my estimation is correct, test_complex could pass by tomorrow... A lot of improvments...
Marius Wachtler
@undingen
Aug 06 2015 13:58
:-) :+1:
Sun
@Daetalus
Aug 06 2015 18:17
Hi, could someone give some help? The subtype of complex always return <type 'complex'>. How to let the subtype has correct type name? Thanks!
Rudi Chen
@rudi-c
Aug 06 2015 18:41
Is the tp_name also complex? Can you find where tp_name gets written to (or fails to be written to)?
Sun
@Daetalus
Aug 06 2015 18:42
Thanks, checking it.
Sun
@Daetalus
Aug 06 2015 19:08
The subclass's tp_name also is complex. I didn't find where the subclass may rewrite it. I will continue to investigate it tomorrow.
Sun
@Daetalus
Aug 06 2015 19:35
@rudi-c for #782 , formatbuilt-in function already exists, just not support complex. But I implement it in my repo.
Sun
@Daetalus
Aug 06 2015 20:19
@kmod Will restart #809 could make it pass gcc build?