[WIP]Some other building issue #1364
Conversation
only lookup __[set/get/del]slice__ for slice AST nodes
Or rather, have execfile() be more permissive in what it accepts. It may still abort when we get to pickGlobalsAndLocals() and we discover that we can't actually execute in that particular attrwrapper.
It keeps timing out
Support attrwrapper as globals argument to execfile
…ue1197 Add missing tp_as_mapping
VRegSet: use a llvm bitvector as representation
The repro is: - import a.b, and in a.b do - import a.b as ab This will cause an attribute error, since a.b (the name) is successfully importable, but a.b (the attribute) doesn't exist yet.
I had spelled the test name wrong
Some scipy fixes
(it uses old-style iteration) And crazily, there is code that relies on this. I wouldn't usually want to give in to code relying on such an esoteric feature, but this seems to be a speedup as well (though that deserves looking into, itself).
- special-case classes that we know have a fixed length (ex str) - do patchpoints for getIterHelper
Cython try to store argcount, nlocals, and varnames through PyCode_New. But Pyston don't do anything with those or support getting them back out.
In PyDict_Next, the 3rd argument `pkey` and 4th argument pvalue could be NULL. lxml will try to call it by PyDict_Next(kwdict, &pos, &key, 0). And a check like CPython did.
Because scipy rely on NumPy, so add scipy test to numpy_test.py. And rename it to scipy_test.py. numpy_full_test.py will check numpy test suite. The scipy_test.py only for check scipy test suite. But scipy test will take a long time. So disabled it by default.
This is hacky, but delve into scipy souce code to fix the numerous implicit function declaration is not make sense for now.
Some SciPy fixing.
at somepoint we really should split all this common code into a function...
keep track of which variables are known to be a python bool so that we can remove some of the nonzero() calls
… r15, rbx, rbp in PPs and the bjit Keeping the available registers in a bitset makes it more memory efficient and also easier and more performant to calculate a subset of the registers. I will soon implement the 'otherThan' functionality using it which would fix the current problem of only allowing to exclude one register
…r block when possible
use r12, r15 and rbx in bjit and inside bjit ICs, remove some nonzero checks
[WIP]Let GCC 5 happy and update the CPython test notes
We symlink the CPython tests into our tests directory to control which ones we will attempt to run. A bunch of the tests though need other test files in order to run, and we hadn't symlinked those in. At some point we should switch to symlinking the Lib/test directory instead of individual files, but for now this helps.
Main difference is lowering the recursion-depth on unoptimized builds, since we need more stack space per python frame.
to not conflict with CPython's -O. They're quite similar (increase optimization level), but some tests ask for -O when they don't really want our version of it.
For some reason the max-RSS limit doesn't seem to be kicking in. Switch to putting a limit on the virtual size instead, and bump the limit from 500MB to 1.5GB.
…test and the implementation we copied
needed because of how we symlink things
ie did some quick debugging and added test notes
Two of these tests pass in release mode but not in debug (one is a timeout, the other is an assertion) Two of them are failing in both and I don't know why I marked them as succeeding.
and only run the small variant in debug mode to avoid timeouts. Previously I had tried splitting it in half, but it looks like that's both not enough to avoid timeouts, and it also has a race condition when trying to run two copies of the test at the same time (one will read the not-fully-written pickled output of the other).
Take a pass over the CPython tests
Fix docs about stats option
When Pyston try to build C extension, it will add *.pyston suffix. Pyston add this by define `"SO": ".pyston.so"` in _sysconfigdata.in. We need to let Pyston also find shared library without *.pyston.so suffix when build C extension.
Daetalus
force-pushed
the
building_issue
branch
from
0d8f30f
to
61b7210
Compare
Daetalus
force-pushed
the
building_issue
branch
from
61b7210
to
67e5971
Compare
| @@ -246,6 +246,7 @@ def find_library_file(self, dirs, lib, debug=0): | |||
| shared_f = self.library_filename(lib, lib_type='shared') | |||
| dylib_f = self.library_filename(lib, lib_type='dylib') | |||
| static_f = self.library_filename(lib, lib_type='static') | |||
| non_pyston_shared_f = '.'.join(shared_f.split('.')[:-2] + ['so']) | |||
There was a problem hiding this comment.
I would prefer if this would explicitly check if shared_f ends in .pyston.so and only than remove it.
- comments which mention that this is a pyston change before every change please
Makefile
Outdated
| @@ -155,11 +152,6 @@ COMMON_LDFLAGS += `pkg-config tinfo 2>/dev/null && pkg-config tinfo --libs || ec | |||
| # TODO should probably do the linking before MCJIT | |||
| COMMON_LDFLAGS += -Wl,-E | |||
|
|
|||
| # We get multiple shared libraries (libstdc++, libgcc_s) from the gcc installation: | |||
There was a problem hiding this comment.
I think instead of removing parts of the unused makefile code in this commit we should leave it in and instead remove the whole non cmake related build code from the makefile sometime in the future.
If it really does not work without removing ifneq ($(GCC_DIR),/usr) than I guess there is more stuff used than I thought I will have review it more carefully again.
| @@ -743,6 +743,10 @@ def detect_modules(self): | |||
| missing.extend(['imageop']) | |||
|
|
|||
| # readline | |||
| # Pyston change: in some container system, the dependencies are provided by | |||
There was a problem hiding this comment.
mmh I'm not so sure about this change, I don't think it hurts but I'm not sure and would prefer if you server would not need this.
I found cpythons https://bugs.python.org/issue21571 but it's still open :-(.
@kmod what do you think about this change?
There was a problem hiding this comment.
CPython uses CPPFLAGS and LDFLAGS. https://github.com/Daetalus/cpython/blob/master/configure#L2796
So I can also modify the CMakefile, for example(The $ENV{CPPFLAGS}):
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e660dc3..2250f89 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -273,7 +273,7 @@ if(ENABLE_OPROFILE)
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -Wextra -Werror -Wreturn-type -Wno-sign-compare -Wno-unused -Wno-unused-parameter -fno-omit-frame-pointer -g")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_C_FLAGS} -std=c++11 -fno-rtti -fexceptions -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -Woverloaded-virtual -Wno-invalid-offsetof -Wcast-qual -Wno-sign-conversion -Wnon-virtual-dtor -Winit-self -Wmissing-include-dirs -Wstrict-overflow=5 -Wpointer-arith -Wtype-limits -Wwrite-strings -Wempty-body -Waggregate-return -Wmissing-field-initializers -Wredundant-decls -Winline -Wint-to-pointer-cast -Wlong-long -Wvla -Wno-attributes -g")
+set(CMAKE_CXX_FLAGS "$ENV{CPPFLAGS} ${CMAKE_CXX_FLAGS} ${CMAKE_C_FLAGS} -std=c++11 -fno-rtti -fexceptions -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -Woverloaded-virtual -Wno-invalid-offsetof -Wcast-qual -Wno-sign-conversion -Wnon-virtual-dtor -Winit-self -Wmissing-include-dirs -Wstrict-overflow=5 -Wpointer-arith -Wtype-limits -Wwrite-strings -Wempty-body -Waggregate-return -Wmissing-field-initializers -Wredundant-decls -Winline -Wint-to-pointer-cast -Wlong-long -Wvla -Wno-attributes -g")
Thoughts?
Updates
After some experiments, I am back to vote the current implementation... Because although modifies CMakefiles can build extensions. But it can not effect the file search in from_cpython/setup.py. But search the environment variable CPATH and LIBRARY_PATH seems could solve both. Correct me if I was wrong/ :)
There was a problem hiding this comment.
I'm not clear on the details, but this change does seem strange since it's not Pyston-specific -- does CPython have this same issue when built in this kind of environment?
There was a problem hiding this comment.
When builds CPython in this kind of environment(a.k.a SlapOS). The build script only needs to provide LDFALGS and CPPFLAGS. Something like this:
CPPFLAGS=-I${zlib:location}/include -I${readline:location}/include ...
LDFLAGS=-L${zlib:location}/lib -L${readline:location}/lib -L${libexpat:location}/lib ...
There was a problem hiding this comment.
My vote is to keep it as close to the way that CPython does it as possible. If it's something in their configure script, then it seems like we should put it in our CMake configuration.
I don't know if it matters here, but I think there's also a small confusion between CPPFLAGS and CXXFLAGS -- confusingly, CPPFLAGS doesn't have anything to do with C++, and is instead about the "C pre-processor". I wouldn't be surprised if our cmake configuration just doesn't pick up that variable when it should.
kmod
force-pushed
the
master
branch
2 times, most recently
from
352fd89
to
6488a3e
Compare
No description provided.