Jeremy Lainé added the comment:
I have started implementing a QUIC stack in Python [1] so I'll share a couple
of thoughts in addition to Christian's two valid points:
- SSLSocket is almost certainly not going to be the right entry point. QUIC's
interface to TLS is entirely foc
New submission from Jeremy Cline :
This is related to the new AsyncMock[0] class in Python 3.8b1. A simple
reproducer is:
from unittest import mock
mock_obj = mock.MagicMock()
mock_obj.mock_func = mock.MagicMock(spec=lambda x: x)
with mock.patch.object(mock_obj, "mock_func")
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
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37386>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue37531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30687>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30263>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 iden
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:
This is ready to be merged, pending any comments from Zach.
--
___
Python tracker
<http://bugs.python.org/issue30368>
___
___
Pytho
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
<h
Jeremy Kloth added the comment:
On Mon, Jun 19, 2017 at 6:24 AM, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Pushed utility to github: https://github.com/jkloth/loadavg
>
> Hum, I see two implementations:
>
> * LOADAVG_USE_REG: use the
Jeremy Kloth added the comment:
Race conditions, not so much, but definitely helps with random timeout errors ;)
--
___
Python tracker
<http://bugs.python.org/issue30
Changes by Jeremy Kloth :
--
pull_requests: +2355
___
Python tracker
<http://bugs.python.org/issue29591>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue29
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
<http://bugs.python.org/is
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:
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 wrote:
>
> STINNER Victor added the comment:
>
>
>
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30860>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue30
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). Plu
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: +j
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 (
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
<http://bugs.python.org/issue31
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue31260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue31340>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue31371>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue31499>
___
___
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 sugg
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue35420>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 that the
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10243
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Py
Change by Jeremy Kloth :
--
pull_requests: +10244
___
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 :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue9566>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/i
Jeremy Kloth added the comment:
Also, my buildbot *should* fail until this change is merged.
--
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue35433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +10247
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32805>
___
___
Py
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 com
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:
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:
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 che
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:
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 ha
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/is
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:
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 stand
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:
> 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
rework
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:
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 for
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, the
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, they
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
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:
> 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 recomm
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
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue36085>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Heiner:
I had some statements inside a `with` statement to write data to an entry in a
ZipFile. It worked great. I added a second `with` statement containing almost
exactly the same statements. That still worked great.
I refactored those common statements into a
Changes by Jeremy Heiner :
--
title: zlib -> zlib.error: Error -2 while flushing: inconsistent stream state
___
Python tracker
<http://bugs.python.org/issu
Jeremy Kloth added the comment:
Looking at test.support, the only errors that I can see being ignored by
unlink() is FileNotFoundError and NotADirectoryError (line 399). The only bare
OSError except clause is on line 359, but for an lstat() call.
--
nosy: +jkloth
Jeremy Kloth added the comment:
The change to sysconfig *may* be a regression wrt bpo-15366.
I'm not in the position to be able to check this possibility, ATM, but it is
possible that other things have also changed since this was commited 5 years
ago.
--
nosy: +j
Jeremy Kloth added the comment:
PR1515 addresses the issue from bpo-15366 (venv from Python compiled with
builddir != srcdir). It seems that the original fix from bpo-15366 no longer
worked. This addresses that.
--
___
Python tracker
<h
Jeremy Kloth added the comment:
Yeah, sorry, I was working (fighting ;) with the new GitHub workflow while you
updated the status.
--
___
Python tracker
<http://bugs.python.org/issue30
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30318>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
See http://bugs.python.org/issue15526
--
___
Python tracker
<http://bugs.python.org/issue30334>
___
___
Python-bugs-list mailin
Jeremy Kloth added the comment:
A few things...
First to Victor's comments on the devguide. The following sentence after the
one quoted states:
"To use the build files in the PCbuild directory you will also need Visual
Studio 2010"
In short, you need *both* VS2008 and VS2010
Jeremy Kloth added the comment:
All builders have been reset and pass, with the exception of the VS9 one which
is a different problem.
--
___
Python tracker
<http://bugs.python.org/issue29
Jeremy Kloth added the comment:
Now that my buildbot is back online, there is one unresolved issue pertaining
to using VS9.0 only for building. That is building without Perl. It was a
supported feature prior to backporting the MSBuild toolchain. With recent
OpenSSL releases, without Perl
Jeremy Kloth added the comment:
> Wait? Why not suggesting to use this recent VS 2015 if it's
> supported?
In theory it is supported, yes. However, it is not compatible with previous C
runtimes. Meaning things like memory allocation (malloc) and file pointers
(FILE *) wouldn
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30371>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Watch this space, but I'm pretty sure that it is (was) bad memory. It passes
memtest86+ but I had issues with these kits in other machines. I swapped out
the stick I believe that had the stuck bit.
Unfortunately, it is a wait and see solution, as th
Jeremy Kloth added the comment:
My thinking is that in normal running, the in-use memory is below the bad bit.
It is due to that test using such a large chunk of memory that it pushes the
data into the bad area. I would wager that if largemem tests were run, the
would error as well
Jeremy Kloth added the comment:
That's the real problem, I'm not *sure* it's the memory, but it does have the
symptoms. And that is why my buildbot was down earlier, I was attempting to
determine the bad stick and replace it. I'm just hoping I changed the right
one. T
Changes by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue30339>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth:
Attempting to append to an existing file fails with no error set:
>>> import os, tempfile
>>> fd, fn = tempfile.mkstemp()
>>> os.write(fd, 'some text')
9
>>> os.close(fd)
>>> with open(fn, 'r+') a
Changes by Jeremy Kloth :
--
pull_requests: +1888
___
Python tracker
<http://bugs.python.org/issue30368>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Submitted PR-1805 that should restore perl-less building.
Also some open issues as noted in the PR.
--
___
Python tracker
<http://bugs.python.org/issue30
Jeremy Kloth added the comment:
On my VM, ssltests pass, but both the Perl and non-Perl segfault in
test_ssl (and many others). My VM has just VS2008 installed, does
VS2010 come with an updated SDK?
--
___
Python tracker
<http://bugs.python.
Jeremy Kloth added the comment:
OK, testing with the 7.1 SDK installed changes the crashes around, but
something is really amiss. I'd like to do more testing, but it will need to
wait until morning here.
--
___
Python tracker
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 direc
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:
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
Changes by Jeremy Kloth :
--
pull_requests: +2044
___
Python tracker
<http://bugs.python.org/issue30339>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
occu
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
<http://bugs.python.org/issue30
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 f
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/is
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:
>
> 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 McMillan added the comment:
I think the code in SaltStack to handle scoped IPv6 addresses is mature, so
please look at these examples.
https://github.com/saltstack/salt/blob/2085cb1078f187adf82a0cf19b39d350ff1bbd50/salt/_compat.py#L125
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:
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(loc
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,
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_str
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue10653>
___
___
Python-bugs-list mailing list
Unsubscribe:
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, &#
201 - 300 of 577 matches
Mail list logo
