Discussion:
[pyusb-users] Change suggestion
Hermann Hamann
2015-06-17 08:11:40 UTC
Permalink
------------------------------------------------------------------------------
Wander Lairson Costa
2015-06-18 12:29:16 UTC
Permalink
2015-06-17 5:11 GMT-03:00 Hermann Hamann <hermann-***@web.de>:
>
> I want to suggest a small change to pyusb to improve speed.
> Currently you can only provide an array.array buffer to put the USB data
> into.
> I use the multiprocessing feature and the final destination of the USB data
> is a mmap.mmap
> Object. I would like to specify this as a receive buffer to save a pickle
> and
> unpickle operation.
> It is not so difficult to use the pyapi.PyObject_GetBuffer function to
> retrieve address and length
> of any buffer protocol compliant object.
> So this array restriction should be lifted, I assume there are more users
> who would
> appreciate this change. I would not like to distribute my software with a
> modified pyusb.
> Sincerely
> Hermann Hamann
>
> Here follows the modifications I made:
> -----------------------------------------
> # in backend1.py, similar for other backends
> from ctypes import *
> from struct import unpack
> getBuffer = pythonapi.PyObject_GetBuffer
> getBuffer.argtypes = [py_object, c_void_p, c_int]
> view = create_string_buffer(11*sizeof(int))
> def getBufferInfo(someObject):
> pointer_to_sO = py_object(someObject)
> result = getBuffer(pointer_to_sO,view,1) # flag writeable
> ### this call can raise an Exception. However this would be a
> consequence
> ### of an invalid caller, so no recovery is possible and simply let it
> ### crash, the message is helpful.
>
> if result != 0 : return None,None
>
> bufadr,objadr,buflen,itemsize,readonly,ndim,bformat,shape,strides,\
> suboffsets,internal = unpack("11I",view)
>
> result = pythonapi.PyBuffer_Release(string_buffer)
> return (bufadr,buflen)
>
> # and some lines later
> def __read(self, fn, dev_handle, ep, intf, buff, timeout):
> ### !!!! changed address, length = buff.buffer_info()
> address,length = getBufferInfo(buff)
> ##length *= buff.itemsize changed
>
> ----------------------------------
> # in core.py
> if isinstance(size_or_buffer,int):
>

Hi,

Could you please open a Pull Request or, if you are not willing to
supply a patch, an issue detailing your proposal?



--
Best Regards,
Wander Lairson Costa

------------------------------------------------------------------------------
Hermann Hamann
2015-06-19 14:12:47 UTC
Permalink
------------------------------------------------------------------------------
Tormod Volden
2015-06-20 09:10:08 UTC
Permalink
On Fri, Jun 19, 2015 at 4:12 PM, Hermann Hamann wrote:
> I am sorry, but I am too old and too stupid to learn on the fly how to use a
> github pull request
> to push some files.
>
> So I use the stone age way to attach the modified files core.py and
> libusb1.py to this mail, hoping,
> that some kind soul will find them and treat them as required.

Hermann,

What version of pyusb are your changes based on? Without knowing this,
it is difficult to figure out exactly what are your changes.

You are giving the maintainer a lot of extra work by just dumping your
files on him. At least, use a "diff" utility to make a
machine-readable diff instead. BTW, the original "diff" was made in
the seventies, so age is no excuse.

Regards,
Tormod

------------------------------------------------------------------------------
Steven Michalske
2015-06-20 10:05:55 UTC
Permalink
> On Jun 20, 2015, at 2:10 AM, Tormod Volden <***@gmail.com> wrote:
>
> On Fri, Jun 19, 2015 at 4:12 PM, Hermann Hamann wrote:
>> I am sorry, but I am too old and too stupid to learn on the fly how to use a
>> github pull request
>> to push some files.
>>
>> So I use the stone age way to attach the modified files core.py and
>> libusb1.py to this mail, hoping,
>> that some kind soul will find them and treat them as required.
>
> Hermann,
>
> What version of pyusb are your changes based on? Without knowing this,
> it is difficult to figure out exactly what are your changes.
>
> You are giving the maintainer a lot of extra work by just dumping your
> files on him. At least, use a "diff" utility to make a
> machine-readable diff instead. BTW, the original "diff" was made in
> the seventies, so age is no excuse.
>
> Regards,
> Tormod
>
> ------------------------------------------------------------------------------
> _______________________________________________
> pyusb-users mailing list
> pyusb-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyusb-users

Hermann,

Presuming that you used git to clone the source repository there is one of the few basic git commands to get a properly formatted patch that tracks the source revision.

Please use git format-patch to generate diffs based upon the checkout that you worked against.

`git format-patch origin/master`

As for pull requests in github, you are not too stupid nor too old. Your self deprecation begs for mockery from others. I accept no ageism, my grandmother was an avid computer user, that was self taught when she was 62, on a 8088 IBM PC clone.

1. Fork the pyusb repository.
2. Commit your changes to a branch in your new fork on your computer.
3. Push your changes to in the forked repository on github.
4. Submit a pull request for that new branch against the pyusb repository.

Please refer to this documentation from github.
https://help.github.com/articles/using-pull-requests/ <https://help.github.com/articles/using-pull-requests/>

Steve
Hermann Hamann
2015-07-01 07:07:52 UTC
Permalink
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
Tormod Volden
2015-07-01 18:41:22 UTC
Permalink
On Wed, Jul 1, 2015 at 9:07 AM, Hermann Hamann wrote:
> Well, identifying the version of a source file would be very easy if you put
> a
> comment at the beginning containing the modification date. Back in the 70s
> we
> were able to fully automate this using available tools (this was not on
> Unix).
> I feel, sed (available since the 70s) could do this for you.

The source revision control system log has taken over this function.

> I finally succeeded in getting a basic understanding of diff, but could not
> find out if patch needs a "diff original modified" or a "diff modified
> original" to work properly.

It should be "original modified" (from to). Please also used "unified"
format for more robust patches (they include some context). The
general diff command that matches the "git diff" output and similar is
"diff -Nurp old new" where old and new also can be directory trees.

> The original is from walac-pyusb-39816be.

39816be is actually the most recent repository revision. There are a
lot more changes between 39816be and the files you posted, than in
your diff files. And some changes in your diff that are already in the
repository.

> I was astonished to learn, that the sourceforge files are from 2014.

Which also indicates you were basing it on an older version.

Thanks for providing the diffs but unfortunately they don't apply
against the latest revision. I spent a lot of time trying to find
which revision you had used but was not successful.

> I hope you can proceed with the modifications. There are 4 lines to change
> and
> 20 lines to insert. Back in the 70s we could do this within 15 minutes.

It would be easy if we knew against which version... Maybe someone
familar with the code and its history can figure it out, but I am just
a patch fairy.

Best regards,
Tormod
Hermann Hamann
2015-07-04 09:53:13 UTC
Permalink
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
Loading...