Ivan Pozdeev added the comment:
@christian.heimes https://github.com/python/cpython/pull/25481 also needs
backporting to 3.9 and 3.8.
A Pyenv user has been affected by the "implicit declaration of function
‘SSLv3_method’" compliation error that it fixes in 3.9.9:
https://github
Ivan Pozdeev added the comment:
> Someone nonchalantly updated these in
> https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17
> so this bug is now fixed
That PR only goes into 3.11. While this ticket claims to have fixed the problem
for 3.10 as well
Ivan Pozdeev added the comment:
While we are at it, shall we enable build config validation
(https://docs.travis-ci.com/user/build-config-validation)?
It would produce warnings for outdated keys like this.
--
___
Python tracker
<ht
Ivan Pozdeev added the comment:
> New changeset 94d2c8df1a7657015a2fcdb4c4d43392f91f8348 by Inada Naoki in
> branch 'master':
bpo-39035: travis: Don't use beta group (GH-17602)
> INADA-san: do you want to close this issue since you pushed changes?
This may actually fix the problem
Ivan Pozdeev added the comment:
I already diagnosed this in
https://mail.python.org/archives/list/python-...@python.org/message/3Z4FNPEFTFTYDX6RYOQ54UKOVLQAWUEU/:
* https://travis-ci.org/python/cpython/jobs/616384134 looks for `pythonX.Y` but
doesn't account for the fact that it could
Ivan Pozdeev added the comment:
Got this issue today in AppVeyor's PR check:
https://ci.appveyor.com/project/python/cpython/builds/24945165, so it's not
local to David's worker.
(At rerun, the test succeeeded, so the check status was not affected.)
--
nosy: +Ivan.Pozdeev
versions
Ivan Pozdeev added the comment:
> which unfortunately use `is` to determine whether two datetimes are in the
> same zone or not
This sounds like a bug. Whether a tzinfo is a constant from a predefined set or
something with a smart comparison semantic is none of datetime's bu
Ivan Pozdeev added the comment:
Given the downsides, I think the proposed solution as it's now is too hacky to
be a net improvement.
"Skip mode_t checks" looks like the only way to go (since I've no idea how to
"create temporary dirs" transparently for arbitrary test
Ivan Pozdeev added the comment:
Seeing during PR composition how basically every mode check and every
`test.support.temp_umask` use is broken by ACLs, I'm starting to doubt that
fixing individual test cases is the way to go.
Though we can simply not worry about supporting everything
Change by Ivan Pozdeev :
--
keywords: +patch
pull_requests: +12584
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36501>
___
___
Py
New submission from Ivan Pozdeev :
In Linuxes with ACLs enabled, the following tests fail, as Steve Dower
discovered in
https://mail.python.org/pipermail/python-dev/2019-March/156929.html:
==
FAIL: test_mode
Ivan Pozdeev added the comment:
On 02.03.2019 9:01, Barry A. Warsaw
In all the cases you've described, Python is no different from any other
Linux software. E.g. I can install something into /etc/profile.d that
would break the shell or set an envvar that would change the behavior
Ivan Pozdeev added the comment:
On 02.03.2019 2:25, Barry A. Warsaw wrote:
> The fact that .pth files are global and affect the entire Python
> installation. <...> Right now, there’s no control over the scope of such
> environmental customizations; it’s all or nothing.
Th
Change by Ivan Pozdeev :
--
keywords: +patch
pull_requests: +12134
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36160>
___
___
Py
New submission from Ivan Pozdeev :
Sample failure:
> cpython\branches\3.7>python.bat -m test.test_site
Running Debug|x64 interpreter...
E.s.
==
ERROR: test_addpackage (__main__.HelperFunction
Ivan Pozdeev added the comment:
On 01.03.2019 20:27, Ivan Pozdeev wrote:
> The fact that this feature is mixed up with and often supplements
> "real packages" that a program would explicitly use is actually
> incidental: a package with a .pth does not need to have a
Ivan Pozdeev added the comment:
On 01.03.2019 3:58, Steve Dower wrote
> Import hooks can always be injected by a package __init__.py before the
> importer will try and resolve the module, so nothing is needed there.
I thought the flaw in this reasoning in
https://bugs.python.org/issu
Change by Ivan Pozdeev :
--
pull_requests: +12117
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Pozdeev added the comment:
On second thought, the inability to debug code that runs at startup, before
user code ever gets control, is a fundamental issue (this problem arises for
any software that has startup code), so such a facility in stock codebase has a
merit
Change by Ivan Pozdeev :
--
pull_requests: +12114
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ivan Pozdeev added the comment:
On 26.02.2019 23:37, Barry A. Warsaw wrote:
> My opposition would lessen if there were clear ways to debug, and preferably
> also prevent, pth interpretation.
Easy. Insert a chunk into site.py that would call pdb.set_trace() if an envvar
(e.g. `PYSIT
Ivan Pozdeev added the comment:
> This brings to mind the transition of many programs from using a single
> config file or startup script to using a directory of config/startup files
> parsed/executed in alphabetical order. Would a sitecustomize.d/ directory
> (with files within
Ivan Pozdeev added the comment:
> I’m a little concerned about this approach because it means random third
> party modules can affect the global environment for your application, without
> knowing it. Since the hook installation happens at import time, and just
> depending
Ivan Pozdeev added the comment:
@barry
> Interdependent namespace packages. If they get loaded in the wrong order,
> they can mess up __path__ settings
Actually, when writing the PR, I had a revelation how this could be
implemented. Via an import hook that would work like a un
Ivan Pozdeev added the comment:
See
https://bugs.python.org/issue33826?@ok_message=msg%20328824%20created%0Aissue%2033826%20message_count%2C%20messages%20edited%20ok&@template=item#msg319692
how IPython stores source from interactive input and why it's not appropriate
for vanilla REPL
Ivan Pozdeev added the comment:
> which, as I explained, is already possible without the patch
Sorry, I myself explained in https://bugs.python.org/msg319692 that it's not
possible. The rest still stands though.
--
___
Python tracker
<
Ivan Pozdeev added the comment:
@Thomas Viehmann , as it's currently formulated, this is a duplicate because it
strives to allow getting class source from past interactive input -- which, as
I explained, is already possible without the patch and seems to be
inappropriate for vanilla console
Ivan Pozdeev added the comment:
The primary motivation behind the suggestion seems to be the fact that the
feature is abused.
However, the documentation has no info whatsoever on what is the intended use
-- thus what constitutes abuse. Without that, the accusations are kind of
baseless
Change by Ivan Pozdeev :
--
keywords: +patch
pull_requests: +9463
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Py
Ivan Pozdeev added the comment:
I confirm violation of https://tools.ietf.org/html/rfc3986#section-3.2.2 .
URLs are now covered by RFC 3986 which obsoletes RFC 1808 that `urllib's
documentation refers to.
This new URL RFC adds [] to 'reserved' characters, so them being present
unquoted
Ivan Pozdeev added the comment:
> They are very difficult to debug because they're processed too early.
.pth's are processed by site.py, so no more difficult than site/sitecustomize.
You can e.g. run `site.addpackage(,,None)' to debug the logic.
> They usually contain globs of inscr
Ivan Pozdeev added the comment:
I *think* we need to ask maintainers of packages who use .pth -- at least, Mark
Hammond (pywin32) -- to find out the impact and if everything can be done with
other means.
AFAICS it at least allows pywin32 to have many top-level modules without
cluttering
Ivan Pozdeev added the comment:
Oh, I see, you want to be able to get the source for code entered into the
interactive session.
IPython does this by creating a separate fake "file name" for every input and
adding corresponding entries for them into `linecache.cache'. This do
Ivan Pozdeev added the comment:
I got that part, thank you.
I can't get 1)what you're expecting as an output and 2)why this should work the
way you're suggesting 'cuz functions and classes are very different.
In particular, classes can be modified dynamically, unlike functions. So if you
Ivan Pozdeev added the comment:
What do you mean by "class source code" anyway? A class doesn't actually
contain any executable code (and there's no code object associated with it).
--
___
Python tracker
<https://bugs.python.o
Ivan Pozdeev added the comment:
In [1]: import logging
In [2]: logging.Logger.__module__
Out[2]: 'logging'
In [4]: import sys
In [6]: sys.modules[logging.Logger.__module__].__file__
Out[6]: 'C:\\Program Files\\Python36\\lib\\logging\\__init__.py'
--
nosy: +Ivan.Pozdeev
Ivan Pozdeev added the comment:
In 3.x, it turns out, this doesn't result in test failures in stock
configuration.
It does though if PYTHONLEGACYWINDOWSFSENCODING is in system environment.
I was diagnosing failures in 2.x and saw that 3.x has the same logic, so it was
a no-brainer
Ivan Pozdeev added the comment:
It's not about "convincing" me or anyone else. It's about showing how this will
be a strict improvement.
I showed that the HTTP RFC allows apps to rely on the fact that they are
receiving all the headers. So filtering them arbitrarily violate
Ivan Pozdeev added the comment:
... can be built with such a glaring mistake in the script.
--
___
Python tracker
<https://bugs.python.org/issue33711>
___
___
New submission from Ivan Pozdeev :
c:\Users\Sasha\Documents\cpython\Tools\msi>python msi.py
Traceback (most recent call last):
File "msi.py", line 1372, in
add_files(db)
File "msi.py", line 956, in add_files
generate_license()
File "msi.py&quo
Change by Ivan Pozdeev :
--
pull_requests: +6904
___
Python tracker
<https://bugs.python.org/issue33709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ivan Pozdeev :
--
keywords: +patch
pull_requests: +6903
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33709>
___
___
Py
New submission from Ivan Pozdeev :
This causes test_ntpath and test_posixpath to fail in subj.
Sample failure:
==
FAIL: test_expandvars_nonascii (__main__.NtCommonTest
Ivan Pozdeev added the comment:
@markroseman I'm about 50% okay with your changes. Could you create a PR
against my branch so we can work out the specifics?
--
___
Python tracker
<https://bugs.python.org/issue33
Ivan Pozdeev added the comment:
On 29.05.2018 23:20, Mark Roseman wrote:
> Mark Roseman added the comment:
>
> Ivan, thanks for making a good first pass of this. The thread section still
> feels a lot like 'fighting' with the model. Do you mind if I take a crack at
>
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Found yet another race condition -- when creating multiple Tk()s. Attached
example (loops indefinitely inside Tcl: some internal list becomes circular for
some reason).
The obvious fix by wrapping Tcl calls with locks in Tka
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
According to
https://stackoverflow.com/questions/1969709/how-to-forward-headers-on-http-redirect
, there's nothing in the specs that mention (even the possibility) of any
special request header processing.
According to
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
>one will see all the variables and call hierarchy
and be able to step through the code. With optimizations, the current line
jumps unpredictably, and some lines can't be visited because they're optimi
New submission from Ivan Pozdeev <ivan_pozd...@mail.ru>:
(the output is for 2.7 head; for master, it's the same save for paths, library
versions and DeprecationWarning's)
>python.bat -m ensurepip
Running Debug|x64 interpreter...
Looking in links: c:\users\sasha\appdata\local\temp\
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> So, nothing more to do here.
In case that was cryptic, it means: the PR can be acted upon, no other changes
are needed.
--
___
Python tracker <rep...@bugs.python.org>
<https
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
I'm currently rewriting the docs, too, according to the plan @ #msg316492. WIP
@ https://github.com/native-api/cpython/tree/tkinter_docs .
You PR lines up fine though is made redundant by
https://github.com/native-api/cpython/
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
pull_requests: +6627
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33257>
___
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
2nd fix ready.
@devteam The issue is fixed completely now, the fix can be merged.
Pushed to the same PR, see
https://github.com/python/cpython/pull/6444#issuecomment-389844872 why.
Used the option "Hold the Tcl lock for
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
@markroseman replied to python-dev since those perspectives are off topic for
this ticket.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> So I would drop the pretense and make these fns void.
Scratch that. In POSIX, they are #define'd as pthread fns which do return an
error code.
So, nothing more to do here.
--
_
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> This seems very complicated. The official line on threads for Tk has always
> been to make all Tk calls from one thread, which is at least predictable and
> comprehensible. Is there any reason for Tkinter to suggest any
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
I was composing a letter to python-dev with all I know of how tkinter works
with regard to threads and Tcl, and the fixing plans so that we're all on the
same page if you wish to participate.
I'm no longer sure if it b
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Such drastic changes of uncertain usefulness are best discussed at python-ideas
first.
What you're really asking for seems to be to parse all "levels" at the same
time.
Try to think of a use case that would make th
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
The 1st PR is ready.
I'll continue working on the 2nd one in this ticket, too, if there are no
objections.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Without thread support, event generation from multiple threads fails
> immediately.
This ticket is for threaded Tcl only, so this is off topic.
In nonthreaded Tcl, this script crashes rather than freezes, for an entire l
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Attached a fixed script.
`Tk.after()` works from a worker thread, while `Tk.destroy()` doesn't.
That's because Tkinter implements Tcl calls (_tkinter.c:Tkapp_Call) from
another thread by posting an event to the interpreter's
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Another possibility is for stop() to change conditions so that
> 'self.target.event_generate(c)' fails with an exception
Could you elaborate? Since there're no docs on event_generate(), I can't look
up how to m
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file:
https://bugs.python.org/file47566/0001-build-2.7-with-threaded-Tcl.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file:
https://bugs.python.org/file47565/0001-Build-non-threaded-debug-Tcl.zip
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
... Finally, since https://bugs.python.org/issue30916, the 3.x Windows build
uses a binary external and needs even more patching to build and link against a
debug and/or custom Tcl/Tk (too long to describe, can give a
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Is threaded tcl just a compile switch, as with CPython?
Yes.
In tcl.vcxproj, tk.vcxproj and tix.vcxproj, there are parameters named like
TclOpts that are passed as OPTS arg to the lib's makefiles. For Tcl 8.5, you
need to pass
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> An automated test would need to fail more consistently, without needing to
> click. Running faster would also be good (and perhaps increase failure
> rate). The the test would be that the file runs in subprocess with
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
>
Do you have a suggestion for what to do short of dropping Tkinter support?
Didn't really look into this.
At first glance, from the trace log, the main thread seems to grab a lock at
some initial point, and then tries to grab
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Ivan, as I also said there, it is not clear to me, given your subsequent
> comments, what you consider to be the status of the PR.
The PR fixes the problem exposed by TkinterCrash2-2.py and TkinterCrash3-2-2.py
an
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> I ran TkinterCrash3-2-2.py 15 times on 64-bit Win10, installed x64 3.6.5,
> with tk 8.6.8, and experienced no crashes.
I wrote in the initial message that this bug only happens with nonthreaded Tcl,
regardless of Python ver
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> So this issue doesn't occur when linked with a thread-aware Tcl/Tk,
right? Maybe we should just make sure that's the only configuration we
ensure?
This would break compatibility, including some usage patterns (see th
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Here are the possible courses of action to fix this.
All require design changes, thus can be shot down on a whim. So I'll ask for
advice and approval at python-dev first, to be sure that my efforts won't be
scrapped.
First
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> worker threads are waiting for the Tcl lock
Pardon. They are waiting for Tkapp_ThreadSend()s into the main thread to
return. The effect is still the same.
--
___
Python tra
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file: https://bugs.python.org/file47564/trace.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Ivan Pozdeev <ivan_pozd...@mail.ru>:
With threaded Tkinter, TkinterHanders3.py from
https://bugs.python.org/issue33257 (attached) hangs.
Tracing with thread_debug and a modified trace.py (to show TIDs, attached)
shows that worker threads are waiting for the Tcl lock
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file: https://bugs.python.org/file47563/trace.zip
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file: https://bugs.python.org/file47561/TkinterHanders3.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Look like the only way is to rearrange Tcl stack frames so that the right one
> is on top.
Scratch that. Tkinter allows to execute entire scripts where the order of the
frames
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Finally dug up the reason but unsure how to fix it.
Here's the trace. The format is `$TID: $FUNCTION [some of the args]'
0x1A34: Tkapp_Call(_object *, _object *)
0x1A34: PythonCmd(void *, Tcl_Interp *, int, cons
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
In all PyMUTEX_* and most PyCOND_* functions, all the underlying APIs are void.
So there's no point for the functions to return anything other than as
convention.
A comment at the start of condvar.h says: "APIs general
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
keywords: +patch
pull_requests: +6237
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Ivan Pozdeev <ivan_pozd...@mail.ru>:
In win7 x64 debug mode with thread_debug=1, every PyThread_release_lock() is
accompanied with a message on stderr:
Could not PyThread_release_lock() error: 0
--
components: Interpreter Core, Windows
messages: 31549
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Removed file: https://bugs.python.org/file47535/TkinterHanders.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file: https://bugs.python.org/file47536/TkinterHanders.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Attached reproducing example for event handlers. If launching more than one
EventThread, it abort()'s immediately.
--
Added file: https://bugs.python.org/file47535/TkinterHanders.py
___
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Wait a second... I think I noticed another similar bug.
In Tkapp_CallProc. Same case, Tkapp_CallArgs and Tkapp_CallDeallocArgs are
called when not holding both locks.
The attached example doesn't use Python event handlers, so it
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
@terry.reedy Apparently, this bug has gone unnoticed for years (to be precise,
since
https://github.com/python/cpython/commit/b5bfb9f38c786c3330b2d52d93b664588c42283d
in 2002),
and there are all kinds of weird rumors circulating
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
My best idea for a test as of now is to run the example ~20 times in a loop (or
continuously for a comparable amount of time & threads) and catch and register
any exceptions in all threads as per
https://stackoverflow.com
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
Treating 'utf-8' and its aliases differently (when they specifically mean the
Python's, rather than something else's, encoding) is definitely as issue.
You shouldn't hardcode a list of aliases though; rather use existing faci
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
keywords: +patch
pull_requests: +6139
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Added file: https://bugs.python.org/file47530/TkinterCrash3-2-2.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Ivan Pozdeev <ivan_pozd...@mail.ru>:
(Marked only 2.7 as affected but this would affect any branch if built with
nonthreaded Tcl.)
When running the attached TkinterCrash2-2.py repeatedly with 2.7.14 and 2.7
head, win7 x64, two kinds of errors pop up randomly:
1. C
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
type: crash -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22552>
___
_
Ivan Pozdeev <ivan_pozd...@mail.ru> added the comment:
> Xavier de Gaye <xdeg...@gmail.com> added the comment:
>
> On a Samsung device with Android 5.1 and tethering enabled, only one network
> device has a MAC address and it is not an all-zero MAC address.
>
> Iv
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
Removed file:
https://bugs.python.org/file47178/0001-Allow-for-all-zero-MAC-based-node-ID-e.g.-mobile-mod.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
pull_requests: +4701
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31643>
___
Change by Ivan Pozdeev <ivan_pozd...@mail.ru>:
--
keywords: +patch
pull_requests: +4679
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Ivan Pozdeev <ivan_pozd...@mail.ru>:
On this machine, C:\Users is a junction to D:\Users .
Sample failure:
Running Release|x64 interpreter...
FFFs...s..s.s.ss..
1 - 100 of 170 matches
Mail list logo
