An error occurred fetching the project authors.
- 01 Sep, 2015 1 commit
-
-
Kevin Modzelewski authored
It does use the old parser, but it also forces the use of the llvm tier for everything which usually ends up being the more important part of the configuration.
-
- 18 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 14 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
We currently over-build it quite a bit; I'll try to look into that issue, but for now we can lessen the effects by at least building it in parallel.
-
- 11 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 05 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 02 Aug, 2015 1 commit
-
-
Kevin Modzelewski authored
Haven't looked into it that much, but my guess is that it was introduced in some newer version of clang than what some people are using. It was added for the use of the clang-pgo build, but we ended up dropping that so it should be ok to drop this flag.
-
- 28 Jul, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 25 Jul, 2015 3 commits
-
-
Chris Toshok authored
-
Chris Toshok authored
-
Chris Toshok authored
-
- 24 Jul, 2015 1 commit
-
-
Chris Toshok authored
instead of building twice in the same build dir (which if there's an error can lead to using the -fprofile-generate thinking it's the -fprofile-use build), we build the -fprofile-generate build as pyston_release_gcc_pgo. The resulting -fprofile-use build is the normal pyston_release_gcc build. Deps aren't quite there yet, but this should also allows you to re-train the pgo build later and then apply the new data to the release build, e.g.: ``` $ rm -f ./build/Release-gcc $ ./pyston_release_gcc_pgo ${training.py} $ make pyston_release_gcc ```
-
- 21 Jul, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 17 Jul, 2015 1 commit
-
-
Kevin Modzelewski authored
-
- 16 Jul, 2015 1 commit
-
-
Rudi Chen authored
-
- 15 Jul, 2015 1 commit
-
-
Daniel Agar authored
-
- 13 Jul, 2015 2 commits
-
-
Chris Toshok authored
-
Chris Toshok authored
-
- 30 Jun, 2015 1 commit
-
-
Kevin Modzelewski authored
We already have this for the rest of our code, but it wasn't enabled for C files.
-
- 24 Jun, 2015 1 commit
-
-
Rudi Chen authored
-
- 17 Jun, 2015 4 commits
-
-
Daniel Agar authored
-
Daniel Agar authored
-
Daniel Agar authored
-travis-ci will timeout with no output after 10 minutes, running ctest manually will produce output as it runs
-
Daniel Agar authored
-sync local testing with travis-ci testing -remove duplication -ctest provides a nice test summary
-
- 13 Jun, 2015 1 commit
-
-
Daniel Agar authored
-
- 03 Jun, 2015 1 commit
-
-
Kevin Modzelewski authored
virtualenv_test currently takes ~7m for me. we should probably move most of the stuff it does to the "extra" tests, but for now at least make `make check` not fail.
-
- 02 Jun, 2015 2 commits
-
-
Kevin Modzelewski authored
I think this lets us specify that certain functions should be put together at the end of the text segment. This is inspired by a similar feature of HHVM's build, though the goal for us for now is just to improve performance consistency rather than overall performance. Hopefully soon/eventually we can do profile-guided sorting like they do.
-
Kevin Modzelewski authored
First, that we would only apply our patchset once. If we ever revert the patches (I'm not sure under what conditions that happens), we previously would never apply them again. Attempted to fix this by adding a special patch that adds a new file that CMake looks for; if the file doesn't exist, cmake runs the patches again. Second, that we didn't rebuild libunwind if we apply new patches. I'm not sure if there's a good general solution to this, but I was able to figure out how to force libunwind to rebuild if we need to rerun the patch command. It took some hacking since CMake doesn't track dependencies on external projects, so we have to add some custom dependencies.
-
- 01 Jun, 2015 1 commit
-
-
Chris Toshok authored
-
- 26 May, 2015 2 commits
-
-
Kevin Modzelewski authored
and add a pyc "stress test". I think these issues are the source of our sporadic ci failures; it makes sense based on where things fail (usually in the parser), and because it's stateful (if you already have pycs generated you don't run into the issue) and because it only happens in multithreaded mode. changes: - read the entire file at once, then do checks - add a simple xor checksum in addition to the expected length
-
Chris Toshok authored
-
- 22 May, 2015 2 commits
-
-
Michael Arntzenius authored
The signal-blocking is used to prevent libunwind from being entered recursively, if a signal handler invokes libunwind. We don't call libunwind from signal handlers, so this is not a problem for us. The conservative checks just make crashes behave more nicely. They have a small but measurable performance impact. We enable them in debug mode and disable them for release mode.
-
Michael Arntzenius authored
We also modify .gitmodules so that our patches to libunwind/ don't make git think the tree is dirty.
-
- 19 May, 2015 2 commits
-
-
Kevin Modzelewski authored
-
Daniel Agar authored
-
- 17 May, 2015 1 commit
-
-
Kevin Modzelewski authored
by adding from_cpython/setup.py. This way we can build _multiprocessing as a shared module to be loaded on-demand, since it's quite expensive right now for us to import it. CPython has a similar setup.py, but theirs is pretty large (2kloc) so I don't feel like we need to try copying yet. We could/should move other modules to use this strategy. I'm not 100% happy with the build system support, but we can iterate on that.
-
- 14 May, 2015 5 commits
-
-
Daniel Agar authored
-
Daniel Agar authored
-
Daniel Agar authored
-
Daniel Agar authored
-use pyconfig.h instead of config.h
-
Daniel Agar authored
-