Hi Sergey,
On 10 April 2017 at 19:45, Sergey Kurdakov wrote:
> BCDEDIT /Set IncreaseUserVa 3072
According to the documentation here:
https://msdn.microsoft.com/en-us/library/windows/hardware/bb613473(v=vs.85).aspx
this line has no effect on Windows 64 (even if the running program is
32-bit), but
Hi Matti,
after double checking pypy-c.exe headers with
dumpbin /headers pypy-c.exe
(actually while objects are compiled with /LARGEADDRESSAWARE flag in
windows.py - final exe does not contain required flag so possibly here
- either this flag should be removed or set correctly such that
produced
Hi Matti,
>Are you using 64-bit windows? Then using the editbin /largeaddressaware trick
>as mentioned on the windows build >page you should be able to access all your
>memory from the 32-bit python executable used for translation.
yes I'm on windows 64 ( win 10/64 ) and I did, but to no avail
On 08/04/17 19:26, Sergey Kurdakov wrote:
while compiling pypy lack of memory is an issue even on machines with
more memory that required for compilation.
Basically pypy will crash when achieves 2 Gb memory limit even with
setting pypy to use extended memory
I suppose it starts to interfere w
Hi Armin and Matti,
now my project works.
So concerning current stock installation of pypy seems that the only
problem was a lack of sufficient stack space on windows,
in debug pypy is configured to increase stack, but in release it is
not. And as stack space is insufficient - some code might cr
Hi Armin,
concerning pull request.
there are few issues:
the new PyVerify_fd code will not work with vs 2013 as that compiler
has a bug: it reports console fd s as positive numbers ( earlier ms
compilers and vs 2015 are correct to return negative values )
so both versions ( previous and new one
Hi Matti,
>How are you coping with third party packages?
I built them myself,
>Were these directions at all useful
they were useful to the extent, for example openssl won't build with
these instructions ( nasm step was missing ) also opensssl will use
/MT library option by default after ms/do_m
On 05/04/17 22:54, Sergey Kurdakov wrote:
Hi Armin,
ok, I will prepare pull request,
though there are other things to change.
somehow openssl crashes on callback
openssl is compiled by default with __cdecl, but export win32
functions in pypy are defined as __stdcall so callback to openssl is
Hi Armin,
ok, I will prepare pull request,
though there are other things to change.
somehow openssl crashes on callback
openssl is compiled by default with __cdecl, but export win32
functions in pypy are defined as __stdcall so callback to openssl is
sent as stdcall but it expects __cdecl ( may
Hi Sergey,
On 5 April 2017 at 16:56, Sergey Kurdakov wrote:
> with additionally changed pypy\rpython\rlib\_rsocket_rffi.py file
> (see attachment)
Cool! But it would be more useful for us if you could open a pull
request on the bitbucket project page, https://bitbucket.org/pypy/pypy
. Failing
Hi,
btw seems I got why error 10035 appears in VS 2015 build network calls,
in pypy code there is check for EWOULDBLOCK and required steps are made
to deal with situation.
but in VS 2015 EWOULDBLOCK is defined as
#define EWOULDBLOCK 140
while 10035 error is defined as
#define WSAEWOULDBLO
Hi Sergey,
Thanks a lot for trying to look into this! Some more windows expertise is very
welcome.
Cheers,
Carl Friedrich
On April 2, 2017 11:56:41 AM GMT+02:00, Sergey Kurdakov
wrote:
>Hi Armin,
>
>>As an aside, we'd love to get any precise information about
>>"unstabilities" of the stand
Hi Armin,
>As an aside, we'd love to get any precise information about
>"unstabilities" of the standard PyPy.
the precise instability is that stock installation crashes on my project (
unfortunately it is too big to catch for me - so that
I try to compile some custom version and find out )
>We n
Hi Sergey,
On 1 April 2017 at 13:57, Sergey Kurdakov wrote:
> but now I have seemingly more stable pypy, but at the same time that network
> error, any hints what might be involved here and how to debug?
As an aside, we'd love to get any precise information about
"unstabilities" of the standard
Hi,
I managed to build pypy with visual studio 2015 ( win32 build on window
10/64 )
with both python and by pypy itself
but I have one strange behavior
it manifest in a first steps using new pypy by running pip
pypy-c -mpip install -U wheel
and an error reads
Retrying (Retry(total=4, connect=
15 matches
Mail list logo
