Today I am trying out using ChatGPT to convert libusb tests/

Original pthread based C code. <a href="https://github.com/libusb/libusb/blob/mast

No issues under macOS with my Mac Mini M1. <div class="snippet-clipboard-content n

I asked ChatGPT to create the code to match the intention of <code class="notranslate"

libusb stress_mt.c conversion to pyusb,about pyusb/pyusb

Comments (16)

jonasmalacofilho commented on June 12, 2024 1

Let me start by saying that discussing ChatGPT-suggested code here (or elsewhere) is usually unproductive:

its bugs are nonsensical;
it isn't actually reasoning anything;

Proposing the inclusion of such code in PyUSB would, on top of those concerns, also be unacceptable due to copyright issues. (And I suspect that the common argument that it's "just like a compiler" will fail miserably once actually tested in court... as it's not a compiler, but rather a copyright laundering machine).

With that out that the way, you mention in the libusb issue that you're actually using ChatGPT here more or less like a fuzzer. That's interesting, and it may turn out to be a productive use of ChatGPT. (But let's evaluate that later).

So, the first thing is to ignore any pseudo-justification provided by ChatGPT: in the best case it's just noise, and in the worst it's noise that will also point us in the wrong direction. I rather not even see it. There's no reasoning behind it, it's just a (large) predictive text language model. Honestly, it doesn't even make any sense to ask it to reason about anything, much less something it generated, where it might tend to keep the coherence, which is actually very bad when the generated thing was wrong to start with.

Next, can you get some thread IDs onto those messages (whenever threading is in use)? That's necessary to accurately reason about errors in multi-threaded code, except in a few cases (like when there's really only one thread that could be involved in causing that type of error).

Now, on to the errors on Windows: at a glance, libusb_open doesn't support the first device returned dev.find(), which is the one the test always picks. Maybe it's a root hub or protected for some other reason? Either way, you'll probably want to find a suitable device in the system before running the stress part of the test on it...

Which brings me a more important observation: the code generated by ChatGPT doesn't resemble anything like the original!

While stress_mt.c is a test "that creates and destroys contexts repeatedly", what ChatGPT generated tries to read the string descriptor with id 1 from whatever happens to be the first device found by PyUSB. (For compleness: it tries to read that descriptor 160000 times—16 threads × 10000 iterations/thread).

P.S. I think you'll agree that, at this point, the ChatGPT-as-a-sort-of-a-fuzzer experiment isn't off to a good start. ~~But feel free to try a few more times if you want.~~

P.P.S. I removed the last sentence of the P.S. because I don't want to seem like I'm encouraging this sort of thing, and the way I had phrased it could be interpreted that way. What I meant to say is: this time it sucked, I make no additional claim about whether it will suck next time (besides the general arguments I mentioned), but you're free to use your time however you see fit, and for now allowed to bring me into the discussion as well (on the off chance that, like with a fuzzer, these experiments may eventually produce some useful observations).

from pyusb.

mcuee commented on June 12, 2024

Original pthread based C code.
https://github.com/libusb/libusb/blob/master/tests/stress_mt.c

Discussion:

libusb/libusb#1128

from pyusb.

mcuee commented on June 12, 2024

This is what ChatGPT says about the error messages.

It's possible that there is an issue with the PyUSB codes or the PyUSB library itself, but it's also possible that the issue is related to the platform you are running the code on. The error message "Operation not supported or unimplemented on this platform" suggests that there may be some limitations or compatibility issues with the USB backend being used by PyUSB.

You can try checking the PyUSB documentation or contacting the developers to see if there are any known issues or workarounds for the error message you're seeing. Additionally, you may want to try running the code on a different platform or with a different USB device to see if the issue persists.

from pyusb.

mcuee commented on June 12, 2024

No issues under Linux. I need to use sudo though to avoid permission errors like ValueError: The device has no langid (permission issue, no string descriptors supported or device error), which is not a real problem.

mcuee@UbuntuSwift3:~/build/python/stress_mt_python$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 1c7a:0575 LighTuning Technology Inc. EgisTec EH575
Bus 003 Device 004: ID 04f2:b6dd Chicony Electronics Co., Ltd HD User Facing
Bus 003 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 006: ID 8087:0026 Intel Corp. 
Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

mcuee@UbuntuSwift3:~/build/python/stress_mt_python$ sudo python3 stress_mt_pyusb.py 
All threads completed successfully

mcuee@UbuntuSwift3:~/build/python/stress_mt_python$ python3 stress_mt_pyusb.py 
Exception in thread Thread-1:
Traceback (most recent call last):
Exception in thread Thread-2:
Exception in thread Thread-3:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Exception in thread Thread-4:
Traceback (most recent call last):
Exception in thread Thread-5:
Exception in thread Thread-6:
Traceback (most recent call last):
Exception in thread Thread-7:
Traceback (most recent call last):
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
Exception in thread Thread-9:
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Exception in thread Thread-8:
Exception in thread Thread-11:
Traceback (most recent call last):
Exception in thread Thread-12:
Exception in thread Thread-13:
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
Exception in thread Thread-10:
Traceback (most recent call last):
Traceback (most recent call last):
Exception in thread Thread-15:
Exception in thread Thread-16:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Traceback (most recent call last):
Exception in thread Thread-14:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
    self.run()
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
    self.run()
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
    self.run()
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
    self.run()
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
  File "stress_mt_pyusb.py", line 18, in run
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
  File "stress_mt_pyusb.py", line 18, in run
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "stress_mt_pyusb.py", line 18, in run
    usb.util.get_string(self.dev, 1)
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
    self.run()
  File "stress_mt_pyusb.py", line 18, in run
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
  File "stress_mt_pyusb.py", line 18, in run
  File "stress_mt_pyusb.py", line 18, in run
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "stress_mt_pyusb.py", line 18, in run
    usb.util.get_string(self.dev, 1)
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
    self.run()
    usb.util.get_string(self.dev, 1)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
  File "stress_mt_pyusb.py", line 18, in run
    self.run()
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "stress_mt_pyusb.py", line 18, in run
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
    usb.util.get_string(self.dev, 1)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
    usb.util.get_string(self.dev, 1)
  File "/usr/local/lib/python3.8/dist-packages/pyusb-1.2.1.post41+g73e87f6-py3.8.egg/usb/util.py", line 308, in get_string
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
ValueError: The device has no langid (permission issue, no string descriptors supported or device error)
All threads completed successfully

from pyusb.

mcuee commented on June 12, 2024

No issues under macOS with my Mac Mini M1.

(py310venv) mcuee@mcuees-Mac-mini stress_mt_python % python stress_mt_pyusb.py 
All threads completed successfully

from pyusb.

mcuee commented on June 12, 2024

the code generated by ChatGPT doesn't resemble anything like the original!

You are absolutely right. And it admited the mistake.

Yes, the Python code using pyusb does not exactly match the function of the original C code. The C code creates multiple threads, each of which repeatedly calls libusb_get_device_list to obtain a list of all the USB devices attached to the system. The Python code using pyusb, on the other hand, only opens a USB device and sends a control message to it.

If you would like to use pyusb to implement a similar functionality as the C code, you could modify the Python code to create multiple threads and have each thread repeatedly call the pyusb equivalent of libusb_get_device_list. Here is an example of how you could modify the code:

import threading
import usb.core
import usb.util

NUM_THREADS = 16
NUM_ITERATIONS = 10000

def thread_func(thread_id):
    dev = usb.core.find(find_all=True)
    for i in range(NUM_ITERATIONS):
        devs = list(dev)
        if len(devs) == 0:
            print("Thread {} found no devices".format(thread_id))
        else:
            print("Thread {} found {} devices".format(thread_id, len(devs)))

threads = []
for i in range(NUM_THREADS):
    threads.append(threading.Thread(target=thread_func, args=(i,)))

for thread in threads:
    thread.start()

for thread in threads:
    thread.join()

print("All threads completed successfully")

This modified code creates NUM_THREADS threads, each of which repeatedly calls usb.core.find to obtain a list of all the USB devices attached to the system. Note that the find_all parameter is set to True to ensure that all devices are returned. The list of devices is then printed to the console.

from pyusb.

mcuee commented on June 12, 2024

Just want to state what I want to achieve through the chatgpt experiment.

Not to generate codes which will be merged -- only for testing purpose. This should avoid copyright concerns.
Reuse test cases across libusb and the two python bindings -- pyusb and python-libusb1. In this example, the libusb C code is the start. But often it may be easier to write a test case in Python than C.
Test method -- to verify the test results across Windows, macOS and Linux to see if there are potential problems. For example, if the results under Linux and macOS are the same, but there is a problem under Windows, then there is a potential problems under Windows. It may well be there is a valid reason why Windows performs different but it may also be possible that there is a real problem under Windows.

Specifically to the stress_mt.c tests, I suspect there is an issue with the libusb Windows backend when it comes to ref count. The converted C++11 codes seem to be able to expose the problem (to be confirmed).

from pyusb.

mcuee commented on June 12, 2024

The generate pyusb code may still not match the intention to be a test "that creates and destroys contexts repeatedly". But it seems to me that there is a potential issue with Windows. Or is it the code is again not valid?

Run log with NUM_THREADS = 4 and NUM_ITERATIONS = 4

(py310x64venv) PS C:\work\libusb\libusb_test\stress_mt_python> python .\stress_mt_pyusb_1.py
Thread 3 found 7 devices
Thread 3 found no devices
Thread 3 found no devices
Thread 3 found no devices
Thread 1 found 7 devices
Thread 0 found 7 devices
Exception ignored in: <function _AutoFinalizedObjectBase.__del__ at 0x0000026865EE0E50>
Thread 2 found 7 devices
Traceback (most recent call last):
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 86, in __del__
Exception ignored in: <function _AutoFinalizedObjectBase.__del__ at 0x0000026865EE0E50>
Traceback (most recent call last):
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 86, in __del__
Exception ignored in: <function _AutoFinalizedObjectBase.__del__ at 0x0000026865EE0E50>
Traceback (most recent call last):
    self.finalize()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 146, in finalize
    self.finalize()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 146, in finalize
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 86, in __del__
    self._finalizer()
  File "C:\Users\xiaof\AppData\Local\Programs\Python\Python310\lib\weakref.py", line 591, in __call__
    self._finalizer()
  File "C:\Users\xiaof\AppData\Local\Programs\Python\Python310\lib\weakref.py", line 591, in __call__
    self.finalize()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 146, in finalize
    return info.func(*info.args, **(info.kwargs or {}))
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 106, in _do_finalize_object_ref
    return info.func(*info.args, **(info.kwargs or {}))
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 106, in _do_finalize_object_ref
    self._finalizer()
  File "C:\Users\xiaof\AppData\Local\Programs\Python\Python310\lib\weakref.py", line 591, in __call__
    obj._do_finalize_object()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 73, in _do_finalize_object
    obj._do_finalize_object()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 73, in _do_finalize_object
    return info.func(*info.args, **(info.kwargs or {}))
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 106, in _do_finalize_object_ref
    self._finalize_object()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\backend\libusb1.py", line 613, in _finalize_object
    self._finalize_object()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\backend\libusb1.py", line 613, in _finalize_object
    obj._do_finalize_object()
  File "C:\work\python\py310x64venv\lib\site-packages\usb\_objfinalizer.py", line 73, in _do_finalize_object
    _lib.libusb_unref_device(self.devid)
    _lib.libusb_unref_device(self.devid)
OSError: exception: access violation reading 0x0000000000000200
Thread 1 found no devices
    self._finalize_object()
Thread 1 found no devices
  File "C:\work\python\py310x64venv\lib\site-packages\usb\backend\libusb1.py", line 613, in _finalize_object
Thread 1 found no devices
OSError: exception: access violation reading 0x0000000000000200
Thread 0 found no devices
    _lib.libusb_unref_device(self.devid)
Thread 0 found no devices
OSError: exception: access violation reading 0x0000000000000200
Thread 0 found no devices
Thread 2 found no devices
Thread 2 found no devices
Thread 2 found no devices
All threads completed successfully

from pyusb.

rabryan commented on June 12, 2024

I'm sorry, but as an AI language model, I don't have access to any specific code or run logs that you may be referring to. However, if you're running a PyUSB stress test with multiple threads and iterations on a Windows system, there may be some potential issues to consider, such as differences in USB drivers, device settings, or system resources. To help troubleshoot any issues that you may be experiencing, you may want to: 1. Review the PyUSB documentation and forums to ensure you're following best practices for stress testing USB devices using PyUSB. 2. Review any error messages or logs generated by your stress test to identify any specific issues or errors that may be occurring. 3. Consider testing your code on multiple systems (both Linux and Windows) to ensure it works correctly across different platforms. 4. Consider running your stress test with different settings (such as different thread and iteration counts) to see if the issue is related to the specific test configuration. 5. Consider using additional tools or utilities (such as USB sniffers or debuggers) to help diagnose any issues that may be occurring at a lower level. By reviewing your code and logs, testing on multiple systems, and using additional tools, you may be able to identify and resolve any issues that may be occurring during your PyUSB stress test.

from pyusb.

mcuee commented on June 12, 2024

I asked ChatGPT to create the code to match the intention of stress_mt.c, but generated pyusb code does not work at all.

I will pause for a while with the pyusb experiment.

import threading
import time
import usb.core

NUM_THREADS = 16
NUM_ITERATIONS = 10000

def thread_func(thread_id):
    for i in range(NUM_ITERATIONS):
        try:
            dev = usb.core.find()
        except usb.core.USBError as e:
            print(f"Thread {thread_id}: error finding device: {e}")
            return

        time.sleep(0.001)

    usb.util.dispose_resources()

threads = []
for i in range(NUM_THREADS):
    t = threading.Thread(target=thread_func, args=(i,))
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print("All threads completed successfully")

Note from ChatGPT, not so sure if it is valid or not.

Note that in this example, we're not passing the Context object to each thread; rather, each thread is creating its own Context object by calling usb.core.find(). This is because pyusb is not thread-safe, so each thread needs its own Context object. If you need to share a Device object between threads, you'll need to use a lock to ensure that only one thread accesses the device at a time.

from pyusb.

mcuee commented on June 12, 2024

@rabryan

If you want to continue the experiment, please help to create a version which matches the intention of stress_mt.c. Thanks.

I know too little about the topic of Python threading to be able to carry forward with the experiment for now.

from pyusb.

mcuee commented on June 12, 2024

FYI, the generated code below for python-libusb1 seems to match stress_mt.c and runs fine under Windows.

vpelletier/python-libusb1#87 (comment)

from pyusb.

jonasmalacofilho commented on June 12, 2024

@mcuee,

Just want to state what I want to achieve through the chatgpt experiment.

Not to generate codes which will be merged -- only for testing purpose. This should avoid copyright concerns.

Reuse test cases across libusb and the two python bindings -- pyusb and python-libusb1. In this example, the libusb C code is the start. But often it may be easier to write a test case in Python than C.

Except that this would be code that would be merged, conflicting with (1).

More importantly, test code needs to be reliable.

Test method -- to verify the test results across Windows, macOS and Linux to see if there are potential problems. For example, if the results under Linux and macOS are the same, but there is a problem under Windows, then there is a potential problems under Windows. It may well be there is a valid reason why Windows performs different but it may also be possible that there is a real problem under Windows.

Yeah, I had already seen you mention this intent in the libusb issue.

And this was the potentially interesting use case of GPT I meant by "more or less like a fuzzer".

rabryan

If you want to continue the experiment, please help to create a version which matches the intention of stress_mt.c. Thanks.

I know too little about the topic of Python threading to be able to carry forward with the experiment for now.

We need to accept that the experiment has already gone awry:

even as a fuzzer ChatGPT hasn't performed well;
since I and other maintainers, i.e. humans, are part of that fuzzing loop, that's too high a cost (usually fuzzers only waste CPU time);
and in less than 24 hours we already have someone casually pasting ChatGPT output in a conversation (with nothing else added); they showed a total disregard for our time, for open-source in general, and for basic community building and fostering.

For the same reasons, I propose we ban ChatGPT (and, for that matter, Copilot) output from PyUSB, whether in issues, discussions, PRs or in any other PyUSB-related context (including contacting us personally).

P.S. This issue will now be locked and comments restricted to us/maintainers.

from pyusb.

mcuee commented on June 12, 2024

@jonasmalacofilho

Thanks.

When I say "reuse test cases` -- that does not mean to merge the test codes.

But I agree I have not been able to get ChatGPT to create a meaningful equivalent of stress_mt.c with pyusb. So I will stop this experiment for a while.

from pyusb.

jonasmalacofilho commented on June 12, 2024

When I say "reuse test cases` -- that does not mean to merge the test codes.

Well, not necessarily, but we generally want to keep (useful) tests in the repository.

Even in this specific example: it would make sense to, just like libusb has stress_mt.c, have our own stress_mt.py in this repository.

Maybe it would not do the exact same thing as the libusb one, but it could do something else that's relevant to a MT stress test case scenario for PyUSB. Regardless, it would make sense to keep it in the repository, so that we (and others) could use it regularly.

from pyusb.

mcuee commented on June 12, 2024

Ah, you have a good point here. Now I agree it is better to avoid ChatGPT for this use case.

from pyusb.

libusb stress_mt.c conversion to pyusb about pyusb HOT 16 CLOSED

Comments (16)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent