Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37387>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
The test run was stopped by me terminating the stuck processes on the buildbot
worker itself. This happens approximately once a month or so.
As of late, its been stuck in test_concurrent_futures, but it can get stuck in
any test that uses multiprocessing
Jeremy Kloth added the comment:
> * the experimental UTF-8 support was enabled because "de_DE" is not a
> known Windows locale name - try with "de-DE"
>
> Perhaps it would be easy to do the replacement of underscores with hyphens
> on Windows in this functi
Jeremy Kloth added the comment:
I have managed to setup a VM that can reproduce the error. Unfortunately, the
error (heap corruption) is coming from within the UCRT. Attempting to work
around that, I came across another error in the UCRT.
Due to these errors in all available UCRT versions
Jeremy Kloth added the comment:
I've added another test executable (issue36792-2.zip) which should bring some
insight into where things are going wrong. Please run and post the results.
--
Added file: https://bugs.python.org/file48324/issue36792-2.zip
Jeremy Kloth added the comment:
Thanks again! I will have some more tests for you to try tomorrow as I am out
of time for today.
I'm currently of the belief that there is something Python is going to have to
do to work around an issue within the CRT, but more testing will prove
Jeremy Kloth added the comment:
Final test, this time, no Python what so ever. I've added a zip containing a
simple C program (source and .exe) that performs the same test.
The output should be similar to:
The current locale is now: C
The time zone is: 'Mountain Daylight Time' (22
Jeremy Kloth added the comment:
Here is another test, this time removing Python from the equation (mostly :)
import ctypes, struct
crt_locale = ctypes.CDLL('api-ms-win-crt-locale-l1-1-0', use_errno=True)
crt_time = ctypes.CDLL('api-ms-win-crt-time-l1-1-0', use_errno=True)
crt_locale
Jeremy Kloth added the comment:
You can safely execute each line individually (omitting the aforementioned
count/value pairs) or depending on how the copy/paste is being done, just paste
the script into a text editor (notepad) and comment out those lines. Then
copy-paste that modified
Jeremy Kloth added the comment:
Thanks for your patience with this Charlie, but please try another run this
time without the strftime() and mbstowcs() calls. Honest, we are getting
closer!
--
___
Python tracker
<https://bugs.python.
Jeremy Kloth added the comment:
Thanks for the reminder Eryk Sun. This means the test needs to be run yet one
more time :)
import ctypes, locale, struct
crt_time = ctypes.CDLL('api-ms-win-crt-time-l1-1-0', use_errno=True)
locale.setlocale(locale.LC_ALL, 'de_DE')
buf
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue10653>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Oops, I forgot to add in my snippet, the setlocale() call prior to calling the
C strftime() function. So an updated test:
import locale
locale.setlocale(locale.LC_ALL, 'de_DE')
import ctypes, struct
libc = ctypes.cdll.msvcrt
buf = ctypes.create_string_buffer
Jeremy Kloth added the comment:
Ok, now let's try it using the C runtime directly:
import ctypes, struct
libc = ctypes.cdll.msvcrt
buf = ctypes.create_string_buffer(1024)
tm = struct.pack('9i', 2019, 5, 6, 9, 50, 4, 0, 126, 1)
print('count:', libc.strftime(buf, 1024, b'%Z', tm))
print('value
Jeremy Kloth added the comment:
So does that mean that simply doing:
import locale, time
locale.setlocale(locale.LC_ALL, 'de_DE')
time.localtime(time.time())
is enough to trigger the heap corruption? If yes, then what is the output of:
import locale, time
locale.setlocale(locale.LC_ALL
Jeremy Kloth added the comment:
Related to issue bpo-36319
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36792>
___
___
Python-bugs-list m
Jeremy Kloth added the comment:
>
> How does that cause tests to fail? Is it going to stderr? Or just causing
> an error.
>
It is causing an "unexpected output error". When the test is re-run at the
end, it is run in verbose mode so the extra output is ignored and thu
Jeremy Kloth added the comment:
A missed print statement in the 2.7 patch is causing the tests to fail.
Line 647 of Lib/test/test_urlparse.py
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36
Jeremy Kloth added the comment:
When I visit the provided link, I also see what OP describes.
Is it a caching/location issue? I'm in US-Colorado.
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36085>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Thank you for your testing of the venv and pip workflows. At this point, I
believe that all that remains would be for Steve Dower to incorporate the
`IncludeVEnv=true` parameter into the nupkg build process.
I personally do not see a problem with including
Jeremy Kloth added the comment:
> Why do I need to fetch another tool just to fetch Python?
Well, you still need a tool to fetch the zip and you need another tool
to unzip it. If not, how are you bootstrapping your script for those
uses?
> If this is the final decision then I rec
Jeremy Kloth added the comment:
On Sat, Feb 16, 2019 at 8:32 AM jt wrote:
> Is nuget a standard windows utility?
No, but if your script can download a zip of Python, it could download
the nuget executable.
> What happens if that process is interrupted?
Same as interrupting an
Jeremy Kloth added the comment:
For a "tool-style" installation of Python, see the 'PCBuild\find_python.bat'
script in the Python source tree, specifically the nuget section.
Ultimately, it is just:
> nuget install pythonx86 -ExcludeVersion -OutputDirectory "some\path&q
Jeremy Kloth added the comment:
Also of note, a largish temporary directory (16K+ entries) seemed to be causing
a slowdown in the cleanup of the tests, thus triggering the failures. A quick
purge later and the tests seem to run to completion.
Although the tests are currently passing
Jeremy Kloth added the comment:
This is an old, but recurring issue with Windows and directory tree removal:
see issue15496
Basically, for stable (Windows) buildbots, directory tree removal needs to go
through support.rmtree, not any of the stdlib methods for doing so. In a
nutshell
Jeremy Kloth added the comment:
GH-11274 desperately needs to be addressed! The 2 Windows 7 buildbots have been
failing on 3.x since the merge of GH-11135 on 12-18. Either that or the commit
b5c8cfa needs to be reverted.
Being the holiday season and all I can see the extra time needed
Jeremy Kloth added the comment:
All the Windows 3.6 windows buildbots are happy! Thanks to all!
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
> Oh, it's not the installation itself, I'm just wondering if allowing a newer
> version is ok too?
The original PR (included in 3.7, 3.x) uses the latest discovered SDK,
but Steve stated that that logic broke the Pipelines build, so I
reworked to PR t
Jeremy Kloth added the comment:
Well, if VS2015 is installed, the simplest way to have the required SDK(s) is
to go to Control Panel -> Uninstall -> Microsoft Visual Studio (Community) 2015
Click Modify.
Expand "Windows and Web Development"
Expand "Universal Windows
Jeremy Kloth added the comment:
I forgot to mention that the presence of UseWindows81SDK in the build log
indicates that the Build Tools are at most at version 1.2 (included with VS2015
Update 1) which should still work (it's what I tested against), but the
difference may be the standalone
Jeremy Kloth added the comment:
A quick look at the good build log does indicate that the 8.1 SDK was being
used (vars UseWindows81SDK=true and WindowsTargetPlatformVersion=8.1) which is
the default behavior for VS2015 if a matching (from python.props) Win10SDK
cannot be found.
It seems
Jeremy Kloth added the comment:
See also bpo-35450: venv module doesn't create a copy of python binary by
default
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue34
Jeremy Kloth added the comment:
I've added a PR for 3.6 using a different methodology for finding the available
SDK.
Without some change, my buildbot will continue to stay in the red (for 3.6).
It does not the the highest SDK currently (previously?) listed the hard-coded
list. It has
Change by Jeremy Kloth :
--
pull_requests: +10294
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Sorry for the delay, but I wanted to get an environment that still had an older
VS2015 install to test against. VS2015 prior to Update 3 use a different
heuristic to determine the SDK version for building.
I've made the following changes:
- version checking
Jeremy Kloth added the comment:
Not to be impatient or anything, but this change is keeping my buildbot from
being useful. Would it be possible for someone to merge as it has already been
approved (msg331263).
--
___
Python tracker
<ht
Jeremy Kloth added the comment:
> Is it a warning or an error? What is the warning/error message? What is your
> buildbot?
It is a compiler error as you point out below (with message). By buildbot is:
https://buildbot.python.org/all/#/workers/12
> Right now, it seems like on
Jeremy Kloth added the comment:
Sorry Victor, I should have added more context when I nosy'ed you to this issue.
Since you seem to be the "buildbot keeper" as of late, I wanted to give you a
pointer to the reason for my failing buildbot. Which, as I surmised, is
failing c
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10247
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32805>
___
___
Py
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Also, my buildbot *should* fail until this change is merged.
--
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Jeremy Kloth added the comment:
I've added two PRs (GH-11010 and GH-11011) along with bpo-35433 that should get
3.x warning free (finally!) on 64-bit Windows.
--
___
Python tracker
<https://bugs.python.org/issue9
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +10245
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +10244
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10243
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Py
New submission from Jeremy Kloth :
In the process of eliminating compiler warnings on my buildbot, I needed to
update VS2015 to the latest toolset (VS2015 Update 3). This in turn now causes
an error due about not having the required version of Windows SDK installed.
It seems
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue35420>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
As a heavy user of the non-limited Python C API, I would like to offer my
suggestions for consideration. (I'm not allowed to post in discourse)
First off, to me, 'unstable' comes off quite negative, i.e. risky or erratic.
Brett's suggestion of 'broad
Jeremy Kloth added the comment:
The changed succeeded in killing the actively stuck process, so I say its all
good! Thanks for the merge.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracke
Jeremy Kloth added the comment:
It seems my buildbot has a stuck process again.
The "sticking" occurred in this case due to test_concurrent_futures being hung
(for over 38hrs! which is a different issue) and a DSL link reset at the same
time.
So now, all builds on the master b
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +9263
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34980>
___
___
Py
Jeremy Kloth added the comment:
Alternatively, to test for yourself:
1) build a 64-bit python:
> build -e -d -k -v -p x64
2) start the newly built interpreter:
> amd64\python_d.exe
3) in a different command prompt (using dummy target to just do the KillPython)
> build
Jeremy Kloth added the comment:
My testing shows differently:
D:\Public\Devel\cpython\master\PCbuild>set MSBUILD="C:\Program Files
(x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe"
D:\Public\Devel\cpython\master\PCbuild>build -k -v -t foo
Using py -3.6 (found 3.6 with py.exe)
F
New submission from Jeremy Kloth :
Since the KillPython target has been rewritten as an InlineTask, it can no
longer detect 64-bit processes due to MSBuild being 32-bit.
This leads to stuck buildbot runs:
https://buildbot.python.org/all/#/builders/17/builds/348
A few solutions that I can
Jeremy Kloth added the comment:
This is also an issue on Windows when the target path resides within a
junction, paths outside of a junction respond (err, fail) as expected.
https://developercommunity.visualstudio.com/content/problem/272379/createfile-non-error-on-filename-with-trailing
Jeremy Kloth added the comment:
Did you attempt to use the 3-line change I posted earlier? I stepped through
to test line-by-line to find the offending piece of code. And it was indeed
the open() call causing the test-tree to be processed prior to it being
completed. Thus making the .py
Jeremy Kloth added the comment:
For pip, in call_subprocess() (given here in rough pseudo-code)
is_python = (cmd[0] == sys.executable)
kwds = {}
if is_python:
env['PYTHONIOENCODING'] = 'utf8'
kwds['encoding'] = 'utf8'
proc = Popen(..., **kwds)
.
.
.
if stdout is not None:
while
Jeremy Kloth added the comment:
Related to issue34421
--
___
Python tracker
<https://bugs.python.org/issue34618>
___
___
Python-bugs-list mailing list
Unsub
New submission from Jeremy Kloth :
When running Python via subprocess with captured output an encoding error
occurs attempting to output a Unicode filename. The same does not happen when
just using spawnl().
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit
(AMD64
Jeremy Kloth added the comment:
The existing re-code solution is being triggered, as the `errors` in this case
is 'surrogateescape' with an encoding of 'cp1252'.
Here, pip is using subprocess.Popen() to have Python run setup.py. During
execution, a filename, 'taqdir\\\u0634\u0645\u0627
Jeremy Kloth added the comment:
Since my buildbot has been infected with this bug, I took some time to hunt it
out. It turns out that issue is caused by an internal import triggered by the
open() function (at least on Windows).
A recent change to the interpreter (commit 9e4994d) changed
Jeremy Kloth added the comment:
The RegisterWaitForSingleObject() function does use the thread pool API:
https://docs.microsoft.com/en-us/windows/desktop/ProcThread/thread-pool-api
However, PdhCollectQueryDataEx() also creates a user-space thread to handle its
work of setting the event
Jeremy Kloth added the comment:
Correct. Windows provides the building blocks for implementing getloadavg(),
but does not provide an interface that does the averaging. That is deferred to
a per application basis. The best that an application can do for that is to
use thread pools. You
Jeremy Kloth added the comment:
Not that it matters all that much, but from a terminology standpoint, WMI !=
PDH != Performance Counters.
Performance counters (the objects, not the topic) are provided by DLLs
registered in the HKLM\SYSTEM\CurrentControlSet\Services key. Their data
Jeremy Kloth added the comment:
Also prior conversation:
https://bugs.python.org/issue30263#msg296311
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue34
Change by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
The PR resolved the stack overflow in dfs(), however it now fails in the
stackdepth() routine (technically, the stackdepth_walk() helper).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Jeremy Kloth added the comment:
Using master to debug, the (first) offending part of the generated file is the
get_match_iter() function. The problem is not that there is too much nesting,
rather it is simply the fact of too many if's period.
Simple testing at the command prompt (using
Jeremy Kloth added the comment:
> Is that an actual convention? I didn't see any other references, so I figured
> Zach had made it up.
It has existed in the Windows build files since 2.5, when x64
supported was initially added by MvL.
--
nosy: +jeremy
Jeremy Kloth added the comment:
> In this case, the Powershell dependency fails on Windows 7 since it does not
> have the Invoke-WebRequest command (unless you've been installing all your
> updates).
Just to note, PowerShell must be updated *manually* (at least on Win7). Plus
Jeremy Kloth added the comment:
Or, use the preexisting convention of the HOST_PYTHON envvar that was used
prior to the recent merged PRs
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
Just a note with the PR, the changes to PCbuild\pyexpat.vcxproj and
PCbuild\_elementtree.vcxproj should probably be merged forward as
well.
On Wed, Jun 21, 2017 at 1:14 PM, STINNER Victor <rep...@bugs.python.org> wrote:
>
> STINNER Victor added
Jeremy Kloth added the comment:
Added PR to issue29591 to address issue building Expat. In short, the project
files were not updated along with the copy of Expat.
I cannot reproduce the GUI build problem. I would need to see the build logs
to attempt to resolve
Jeremy Kloth added the comment:
Re buildbot failure: see PR on issue29591
It's not a problem with Expat, but with our project files.
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
Added pull_request2355 to address issues from upgrading to Expat 2.2.0 on
Windows 2.7
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
pull_requests: +2355
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
Race conditions, not so much, but definitely helps with random timeout errors ;)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
On Mon, Jun 19, 2017 at 6:24 AM, STINNER Victor <rep...@bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
>> Pushed utility to github: https://github.com/jkloth/loadavg
>
> Hum, I see two implementations:
>
> *
Jeremy Kloth added the comment:
Pushed utility to github: https://github.com/jkloth/loadavg
It is currently just a command-line utility PoC. The routines of interest
would be CalculateLoadReg and the loop in wmain().
--
___
Python tracker <
Jeremy Kloth added the comment:
This is ready to be merged, pending any comments from Zach.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
Following up as the last run on my 3.5 buildslave:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/198
had the timeout again. It is running at a 50% success rate with the only fault
being warnings/errors due to this test
Jeremy Kloth added the comment:
I've implemented a getloadavg() equivalent using Windows performance counters
that could be used to display the load in regrtest, as it happens, before
finding this issue. It is implemented in C (although it *can* be done in only
Python).
It has the identical
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
nosy: +jkloth
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
It seems that commit
(https://github.com/python/cpython/commit/c52572319cbd50adff85050a54122c25239a516d)
changed the parameter name in the definition of _PyCFunction_FastCallDict().
I believe that changing 'func_obj' to just 'func' should fix it (in
Tools/gdb
Jeremy Kloth added the comment:
Just a status check, as I would like to see my buildbot go green again. (This
along with the PR on issue30339).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Jeremy Kloth added the comment:
Added PR1978 that resolves this issue on my buildbot at least. Note that it is
against 3.5 as that is the branch that has the issue, it seems.
I'm guessing improvements in startup time on newer Pythons is why it doesn't
occur for them
Changes by Jeremy Kloth <jeremy.kloth+python-trac...@gmail.com>:
--
pull_requests: +2044
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeremy Kloth added the comment:
See bpo-10030 (and pr #550). It removed that function in favor of the current
approach.
Also, that current code does not generate *every* time, but just once. Note
that the computed value is stored in a global cache.
--
nosy: +jkloth
Jeremy Kloth added the comment:
It seems to me that it is a quite simple fix:
--- a/Objects/fileobject.c
+++ b/Objects/fileobject.c
@@ -1110,7 +1110,7 @@ file_read(PyFileObject *f, PyObject *args)
-clearerr(f->f_fp);
+if (ferror(f->f_fp)) clearerr(f->f_fp
Jeremy Kloth added the comment:
Updated PR. It seems that in my testing back and forth, some build artifacts
were affecting my outcomes. That's what I get for cutting corners...
Per Zach's comment, I've changed to VS project files to use the prepare_ssl.py
include directories (include
101 - 200 of 392 matches
Mail list logo
