internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: microsoft/ptvsd

Issue:
Concurrent imports cause error in force_pydevd 
Happened in Flask multiproc test on macOS, but I think it can potentially occur in any scenario where a module is imported concurrently from another thread:
```
I+05.947: Debuggee-86 stderr:
          b'Error on request:\n'
          b'Traceback (most recent call last):\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/werkzeug/serving.py", line 304, in run_wsgi\n'
          b'    execute(self.server.app)\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/werkzeug/serving.py", line 292, in execute\n'
          b'    application_iter = app(environ, start_response)\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/flask/_compat.py", line 36, in reraise\n'
          b'    raise value\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/tests/test_data/flask1/__init__.py", line 1, in <module>\n'
          b'    import debug_me  # noqa\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/tests/DEBUGGEE_PYTHONPATH/debug_me/__init__.py", line 49, in <module>\n'
          b'    import ptvsd.server\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/ptvsd/server/__init__.py", line 9, in <module>\n'
          b'    import ptvsd._vendored.force_pydevd  # noqa\n'
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/ptvsd/_vendored/force_pydevd.py", line 14, in <module>\n'
          b"    prefix_matcher('pydev', '_pydev'))\n"
          b'  File "/Users/runner/runners/2.159.2/work/1/s/.tox/py37/lib/python3.7/site-packages/ptvsd/_vendored/__init__.py", line 101, in check_modules\n'
          b'    for modname, mod in sys.modules.items():\n'
          b'RuntimeError: dictionary changed size during iteration\n'
```
It needs to take a snapshot of the module list before iterating.


Discussion:

Resolving patch:
diff --git a/src/ptvsd/_vendored/__init__.py b/src/ptvsd/_vendored/__init__.py
--- a/src/ptvsd/_vendored/__init__.py
+++ b/src/ptvsd/_vendored/__init__.py
@@ -98,7 +98,7 @@ def check_modules(project, match, root=None):
         root = project_root(project)
     extensions = []
     unvendored = {}
-    for modname, mod in sys.modules.items():
+    for modname, mod in list(sys.modules.items()):
         if not match(modname, mod):
             continue
         if not hasattr(mod, '__file__'):  # extension module


Test patch:
Repository: microsoft/ptvsd

Issue:
Ensure that the `ptvsd_attach` event sets the right name for child processes
Currently we use the same name as the parent config for the child process config.

The name for child process should probably be `Process #<id>` or something similar.


Discussion:

Resolving patch:
diff --git a/src/ptvsd/adapter/ide.py b/src/ptvsd/adapter/ide.py
--- a/src/ptvsd/adapter/ide.py
+++ b/src/ptvsd/adapter/ide.py
@@ -9,7 +9,7 @@
 import sys
 
 import ptvsd
-from ptvsd.common import json, log, messaging, sockets
+from ptvsd.common import fmt, json, log, messaging, sockets
 from ptvsd.common.compat import unicode
 from ptvsd.adapter import components, servers, sessions
 
@@ -421,6 +421,7 @@ def notify_of_subprocess(self, conn):
             body = dict(self.start_request.arguments)
             self._known_subprocesses.add(conn)
 
+        body["name"] = fmt("Subprocess {0}", conn.pid)
         body["request"] = "attach"
         if "host" not in body:
             body["host"] = "127.0.0.1"


Test patch:
diff --git a/tests/ptvsd/server/test_multiproc.py b/tests/ptvsd/server/test_multiproc.py
--- a/tests/ptvsd/server/test_multiproc.py
+++ b/tests/ptvsd/server/test_multiproc.py
@@ -98,6 +98,7 @@ def grandchild(q, a):
         expected_child_config = dict(parent_session.config)
         expected_child_config.update(
             {
+                "name": some.str,
                 "request": "attach",
                 "subProcessId": some.int,
                 "host": some.str,
@@ -116,6 +117,7 @@ def grandchild(q, a):
             expected_grandchild_config = dict(child_session.config)
             expected_grandchild_config.update(
                 {
+                    "name": some.str,
                     "request": "attach",
                     "subProcessId": some.int,
                     "host": some.str,
@@ -174,6 +176,7 @@ def parent():
         expected_child_config = dict(parent_session.config)
         expected_child_config.update(
             {
+                "name": some.str,
                 "request": "attach",
                 "subProcessId": some.int,
                 "host": some.str,
@@ -191,6 +194,7 @@ def parent():
 
             child_pid = backchannel.receive()
             assert child_pid == child_config["subProcessId"]
+            assert str(child_pid) in child_config["name"]
 
             ptvsd_file = backchannel.receive()
             assert ptvsd_file == ptvsd.__file__
Repository: microsoft/ptvsd

Issue:
Using Ctrl+C causes launcher to print traceback
## Environment data

- PTVSD version: master
- OS and version: linux
- Python version (& distribution if applicable, e.g. Anaconda): 3.7
- Using VS Code or Visual Studio: VSC

## Actual behavior

```console
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/kanadig/GIT/ptvsd/src/ptvsd/launcher/__main__.py", line 74, in <module>
    main()
  File "/home/kanadig/GIT/ptvsd/src/ptvsd/launcher/__main__.py", line 37, in main
    adapter.channel.wait()
  File "/home/kanadig/GIT/ptvsd/src/ptvsd/launcher/../../ptvsd/common/messaging.py", line 1231, in wait
    parser_thread.join()
  File "/usr/lib/python3.7/threading.py", line 1032, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.7/threading.py", line 1048, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
```

## Expected  behavior

This is normal way to shutdown the servers. Show not print exception in launcher.




Discussion:
To be more specific, we should be catching and suppressing `KeyboardInterrupt` at top level in the launcher (what's observed is the default behavior for Python). The debuggee will get that exception as well, and can do whatever it wants about it. But even in the default case, it means that both launcher and debuggee will print the traceback, and we only want the debuggee to do this.
For attach scenarios, adapter has the same issue, because it is spawned by the debuggee, and thus shares the console/tty.

Resolving patch:
diff --git a/src/ptvsd/launcher/__main__.py b/src/ptvsd/launcher/__main__.py
--- a/src/ptvsd/launcher/__main__.py
+++ b/src/ptvsd/launcher/__main__.py
@@ -8,6 +8,7 @@
 
 import locale
 import os
+import signal
 import sys
 
 # WARNING: ptvsd and submodules must not be imported on top level in this module,
@@ -25,6 +26,11 @@ def main():
     log.to_file(prefix="ptvsd.launcher")
     log.describe_environment("ptvsd.launcher startup environment:")
 
+    # Disable exceptions on Ctrl+C - we want to allow the debuggee process to handle
+    # these, or not, as it sees fit. If the debuggee exits on Ctrl+C, the launcher
+    # will also exit, so it doesn't need to observe the signal directly.
+    signal.signal(signal.SIGINT, signal.SIG_IGN)
+
     def option(name, type, *args):
         try:
             return type(os.environ.pop(name, *args))


Test patch:
Repository: microsoft/ptvsd

Issue:
Debug hover: shows empty when hovering over bogus words
Hi, VS Code dev here :wave:

1. Have a python program and hover over some bogus words - like part of a string
2. Debug hover appears with no content
3. The issue here is that the python debug for `evaluate` of `"This"` returns a successful response. I suggest that for evaluating bogus expressions the python debugger returns a response with `success = false`

In this picture I am hovering over `This`.

Related issue: have a bogus expression in the WATCH view. The value is a structured object, instead it shuold just be an error like in the debug console

![Screenshot 2019-12-24 at 15 16 03](https://user-images.githubusercontent.com/1926584/71416358-50a61900-2660-11ea-9ecd-5b9ac4c5835c.png)

![Screenshot 2019-12-24 at 15 17 57](https://user-images.githubusercontent.com/1926584/71416427-a67ac100-2660-11ea-8bc2-f305d52cba12.png)

fyi @qubitron @DonJayamanne 


Discussion:
I think it's possible that this is this way because returning `success=false` on some cases force-stopped the debugger on Visual Studio (but I think that this should be fixed now), so, returning `success=false` should be ok at this point (but we should double-check with the Visual Studio team).

I created https://github.com/microsoft/ptvsd/issues/2014 to address the issue related to the error as a str.
Ok thanks. 

Resolving patch:
diff --git a/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py b/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
--- a/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
+++ b/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
@@ -982,7 +982,7 @@ def __create_frame():
         is_error = isinstance(eval_result, ExceptionOnEvaluate)
         if is_error:
             if context == 'hover':  # In a hover it doesn't make sense to do an exec.
-                _evaluate_response(py_db, request, result='')
+                _evaluate_response(py_db, request, result='', error_message='Exception occurred during evaluation.')
                 return
             elif context == 'watch':
                 # If it's a watch, don't show it as an exception object, rather, format


Test patch:
diff --git a/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py b/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
--- a/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
+++ b/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
@@ -2052,6 +2052,10 @@ def test_evaluate(case_setup):
         stack_frame = next(iter(stack_trace_response.body.stackFrames))
         stack_frame_id = stack_frame['id']
 
+        # Check that evaluating variable that does not exist in hover returns success == False.
+        json_facade.evaluate(
+            'var_does_not_exist', frameId=stack_frame_id, context='hover', success=False)
+
         # Test evaluate request that results in 'eval'
         eval_response = json_facade.evaluate('var_1', frameId=stack_frame_id, context='repl')
         assert eval_response.body.result == '5'
Repository: microsoft/ptvsd

Issue:
When bogus expression is in the WATCH view the value should not be a structured object.
See: https://github.com/microsoft/ptvsd/issues/2011 for more details.


Discussion:
@isidorn As a note, we do that because we just catch any errors and show a reference to the error.

During evaluation it's hard to know whether the error happened in user code and the exception is from there or not, but I guess we can work on `NameError`, `AttributeError` and `SyntaxError` and show as `str()` for those which are the most common evaluation errors... or we could show a str() for any exception in the watch regardless of the type. @int19h @karthiknadig do you have opinions here?

Resolving patch:
diff --git a/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py b/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
--- a/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
+++ b/src/ptvsd/_vendored/pydevd/_pydevd_bundle/pydevd_comm.py
@@ -984,6 +984,13 @@ def __create_frame():
             if context == 'hover':  # In a hover it doesn't make sense to do an exec.
                 _evaluate_response(py_db, request, result='')
                 return
+            elif context == 'watch':
+                # If it's a watch, don't show it as an exception object, rather, format
+                # it and show it as a string (with success=False).
+                msg = '%s: %s' % (
+                    eval_result.result.__class__.__name__, eval_result.result,)
+                _evaluate_response(py_db, request, result=msg, error_message=msg)
+                return
             else:
                 try_exec = context == 'repl'
 


Test patch:
diff --git a/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py b/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
--- a/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
+++ b/src/ptvsd/_vendored/pydevd/tests_python/test_debugger_json.py
@@ -2052,7 +2052,10 @@ def test_evaluate_failures(case_setup):
             json_hit = json_facade.get_stack_as_json_hit(json_hit.thread_id)
             if i == 0:
                 first_hit = json_hit
-
+                # Check that watch exceptions are shown as string/failure.
+                response = json_facade.evaluate(
+                    'invalid_var', frameId=first_hit.frame_id, context='watch', success=False)
+                assert response.body.result == "NameError: name 'invalid_var' is not defined"
             if i == 1:
                 # Now, check with a previously existing frameId.
                 exec_request = json_facade.write_request(
Repository: microsoft/knossos-ksc

Issue:
Calls to "main"
In merging #550 I find I need ``ks::main``.  
Looking at this comment in 
https://github.com/microsoft/knossos-ksc/blob/18f654086f349cceb59c30dcbc8de2c534dcb5ec/src/ksc/Cgen.hs#L801

I wonder is it time to look at removing that?


Discussion:
@toelli-msft 
By "I need `ks::main`" do you mean that you are forced to provide a `ks::main` (even though you don't particularly want to) in order for the generated `.cpp` to compile?
> By "I need `ks::main`" do you mean that you are forced to provide a `ks::main` (even though you don't particularly want to) in order for the generated `.cpp` to compile?

Yes, specifically for it to link and produce a dll/so for Python.  I think the only place the above-linked code is really needed now is in the Haskell "compile-and-run" methods, so if we are redoing KSC some time, it might be worth cleaning up.   For now, I'll provide the main...
I think it would be good to get rid of automatic main generation. (I believe that the earlier justification for keeping it in was that it could be `#define`d away.)
Agreed.  Not too urgent, but nice for code health. For now I just added this in knossos-pybind11.h:
```
// This is needed as long as https://github.com/microsoft/knossos-ksc/issues/606
int ks::main(ks::allocator *) { return 0; };
```

Resolving patch:
diff --git a/src/python/ksc/utils.py b/src/python/ksc/utils.py
--- a/src/python/ksc/utils.py
+++ b/src/python/ksc/utils.py
@@ -221,14 +221,11 @@ def generate_and_compile_cpp_from_ks(ks_str, name_to_call, arg_types, return_typ
 
     generated_cpp_source = generate_cpp_from_ks(ks_str, generate_derivatives=generate_derivatives, use_aten=use_aten)
 
-    cpp_str = """
-#include "knossos-pybind.h"
+    cpp_str = f"""
+    #include "knossos-pybind.h"
+    {generated_cpp_source}
 
-""" + generated_cpp_source + """
-
-int ks::main(ks::allocator *) { return 0; };
-
-"""
+    """
 
     args_str = mangleTypes(arg_types)
     name_str = encode_name(f"{name_to_call}@{args_str}")


Test patch:
Repository: microsoft/knossos-ksc

Issue:
infer_fn_type_from_derived_fn_args should return Type?
Should the return type here be `Type`? I don't understand how the return type could be `StructuredName`.

https://github.com/microsoft/knossos-ksc/blob/fe0771d7451685c47aa519dfec80bd6ccd256b4f/src/python/ksc/type_propagate.py#L86-L88


Discussion:

Resolving patch:
diff --git a/src/python/ksc/type_propagate.py b/src/python/ksc/type_propagate.py
--- a/src/python/ksc/type_propagate.py
+++ b/src/python/ksc/type_propagate.py
@@ -83,9 +83,7 @@ def _type_propagate_helper(ex: ASTNode, symtab, respect_existing: bool):
 # [rev [fwd f]] : ((S, dS), dT) -> (dS, dS)
 
 
-def infer_fn_type_from_derived_fn_args(
-    sname: StructuredName, argtype: Type
-) -> StructuredName:
+def infer_fn_type_from_derived_fn_args(sname: StructuredName, argtype: Type) -> Type:
     if sname.is_derivation():
         derivation = sname.se[0]
 


Test patch:
Repository: microsoft/knossos-ksc

Issue:
Bug: Segmentation fault in sqrl_pytorch-PyTorch CUDA
Just saw this while working on something else.   I haven't done a lot to debug it, but note that it's in copydown, on a fairly innocuous operation (aten::sum(Tensor 2) -> Float), so might be something to do with KS_ALLOCATOR not being defined?
Or could just be out of memory not caught?
![image](https://user-images.githubusercontent.com/128119/130364073-023976aa-9222-4d55-ad43-95a7ac530d76.png)



Discussion:
Easiest way to replicate the situation above is to edit launch.json to include
```
		{
			"name": "(gdb) pytest",
			"type": "cppdbg",
			"request": "launch",
			"program": "/anaconda/envs/knossos/bin/python",
			"args": [
				"-m",
				"pytest",
				"src/bench/",
				"-v",
				"--modulepath=examples/dl-capsule/sqrl",
				"--benchmarkname=sqrl",
			],
			"stopAtEntry": false,
			"cwd": "${workspaceFolder}",
			"environment": [
				{"name":"PYTHONPATH", "value":"./src/python"}
			],
			"externalConsole": false,
			"MIMode": "gdb",
			"setupCommands": [
				{
					"description": "Enable pretty-printing for gdb",
					"text": "-enable-pretty-printing",
					"ignoreFailures": true
				}
			]
		},
```
And then "Debug: Select and Start Debugging" in VS Code, picking "(gdb) pytest".

The problem is that we have

```
@knossos.register
def sqrl(x: torch.Tensor):
    ...


def sqrl_pytorch(x: torch.Tensor):
    return sqrl(x)
```

which means that `sqrl_pytorch` isn't actually a PyTorch implementation at all: it calls the Knossos implementation. I think this was accidentally broken by the addition of the `knossos.register` decorator in #960. We'll need to rewrite `sqrl_pytorch` so that it's a genuine PyTorch implementation.

Before #976 was merged this morning, functions defined using `@knossos.register` were compiled for CPU only; but the "PyTorch CUDA" benchmark puts the input tensors on the GPU. The segmentation fault occurs when trying to read this data on the CPU.

After #976 is merged, the KscStub detects that the input is on the GPU and tries to compile for the GPU, but this raises an error ("Only elementwise operations can be compiled for GPU"), which I think is the correct behaviour. There is no "Knososs CUDA" benchmark for sqrl, because the "Knossos CUDA" benchmark is only enabled for elementwise operations.

Resolving patch:
diff --git a/examples/dl-capsule/sqrl.py b/examples/dl-capsule/sqrl.py
--- a/examples/dl-capsule/sqrl.py
+++ b/examples/dl-capsule/sqrl.py
@@ -23,12 +23,12 @@ def sqrl(x: torch.Tensor):
 
 # run-bench: PyTorch "fast" implementation
 def sqrl_pytorch(x: torch.Tensor):
-    return sqrl(x)
+    return sqrl.raw_f(x)
 
 
 # run-bench: PyTorch "nice" implementation
 def sqrl_pytorch_nice(x: torch.Tensor):
-    return sqrl(x)
+    return sqrl.raw_f(x)
 
 
 # run-bench: Define a range of values at which to call the methods


Test patch:
Repository: microsoft/knossos-ksc

Issue:
Apply "remove-unused" to torch frontend
Apply #1020 to torch frontend.


Discussion:

Resolving patch:
diff --git a/src/python/ksc/compile.py b/src/python/ksc/compile.py
--- a/src/python/ksc/compile.py
+++ b/src/python/ksc/compile.py
@@ -60,7 +60,7 @@ def subprocess_run(cmd, env=None):
     )
 
 
-def generate_cpp_from_ks(ks_str, preludes, prelude_headers):
+def generate_cpp_from_ks(ks_str, ks_entry_points, preludes, prelude_headers):
     ksc_path, ksc_runtime_dir = utils.get_ksc_paths()
 
     with NamedTemporaryFile(mode="w", suffix=".ks", delete=False) as fks:
@@ -86,7 +86,12 @@ def generate_cpp_from_ks(ks_str, preludes, prelude_headers):
         *(opt for header in prelude_headers for opt in ("--cpp-include", header)),
         "--cpp-output-file",
         fcpp.name,
-        "--all-defs",
+        "--remove-unused",
+        *(
+            opt
+            for entry_point in ks_entry_points
+            for opt in ("--used", str(entry_point))
+        ),
     ]
 
     try:
@@ -225,7 +230,9 @@ def mangled_with_type(structured_name):
 
     preludes = ["prelude.ks"] + (["prelude-aten.ks"] if use_aten else [])
     prelude_headers = ["prelude.h"] + (["prelude-aten.h"] if use_aten else [])
-    cpp_ks_functions, decls = generate_cpp_from_ks(ks_str, preludes, prelude_headers)
+    cpp_ks_functions, decls = generate_cpp_from_ks(
+        ks_str, [sn for _, sn in bindings_to_generate], preludes, prelude_headers
+    )
     (
         cpp_entry_point_declarations,
         cpp_entry_point_definitions,


Test patch:
Repository: spesmilo/electrum

Issue:
Lite Mode GUI displays incorrect choice of conversion rate beside balance
When using the Lite Mode option in Electrum 1.7.2 in Windows, Electrum displays BRL as the currency unit, instead of AUD as was set by myself in the preferences window. Conversion works as normal in the Classic GUI.



Discussion:
This happens in the Mac OS X client as well, same version number.  Also, the BRL conversion looks wrong assuming BRL is Brazilian Reals.

The error is in line 790 of gui_lite.py. It tries to get 'conversion_currency' from the wallet configuration, but the attribute is only called 'currency' in the wallet class. Changing that line does the trick.


Resolving patch:
diff --git a/gui/gui_lite.py b/gui/gui_lite.py
--- a/gui/gui_lite.py
+++ b/gui/gui_lite.py
@@ -787,7 +787,7 @@ def change_theme(self, theme_name):
     def set_configured_currency(self, set_quote_currency):
         """Set the inital fiat currency conversion country (USD/EUR/GBP) in 
         the GUI to what it was set to in the wallet."""
-        currency = self.wallet.config.get('conversion_currency')
+        currency = self.wallet.config.get('currency')
         # currency can be none when Electrum is used for the first
         # time and no setting has been created yet.
         if currency is not None:


Test patch:
Repository: spesmilo/electrum

Issue:
Change datafiles install locations on Linux depending on permissions
When doing a pip install in a virtualenv or with --user flag Electrum lacks the permissions to write it's datafiles. If this is the case it would be preferable to see if there is a work-around possible to write these files to a different location where they can still be used. 



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -11,18 +11,23 @@
 if sys.version_info[:3] < (2,6,0):
     sys.exit("Error: Electrum requires Python version >= 2.6.0...")
 
+usr_share = '/usr/share'
+if not os.access(usr_share, os.W_OK):
+    usr_share = os.getenv("XDG_DATA_HOME",
+                           os.path.join(os.getenv("HOME"), ".local", "share"))
+
 data_files = []
 if (len(sys.argv) > 1 and (sys.argv[1] == "sdist")) or (platform.system() != 'Windows' and platform.system() != 'Darwin'):
     print "Including all files"
     data_files += [
-        ('/usr/share/applications/',['electrum.desktop']),
-        ('/usr/share/app-install/icons/',['icons/electrum.png'])
+        (os.path.join(usr_share, 'applications/'),['electrum.desktop']),
+        (os.path.join(usr_share, 'app-install', 'icons/'),['icons/electrum.png'])
     ]
     if not os.path.exists('locale'):
         os.mkdir('locale')
     for lang in os.listdir('locale'):
         if os.path.exists('locale/%s/LC_MESSAGES/electrum.mo'%lang):
-            data_files.append(  ('/usr/share/locale/%s/LC_MESSAGES'%lang, ['locale/%s/LC_MESSAGES/electrum.mo'%lang]) )
+            data_files.append(  (os.path.join(usr_share, 'locale/%s/LC_MESSAGES'%lang), ['locale/%s/LC_MESSAGES/electrum.mo'%lang]) )
 
 data_files += [
     (util.appdata_dir(), ["data/README"]),


Test patch: