On 2012.06.19 00:07, Peter Stuge wrote:
> Do you know all possible reasons are for that error code?
Do I know the content of MSDN by heart? Do I believe that the WinUSB DLL
designers have documented all the possible reasons under which this
error code to be returned? Do I even believe that the error code I
mentioned is the only one that can be reported, even though I didn't run
a proper test? Also, do you have any other questions like this one?
>>> The topic is that transfers don't complete at all rather than the
>>> error code.
>>
>> The topic is that someone unplugs a device and expects some
>> specific unplug handling to occur,
>
> Think about it from the libusb API perspective rather than from the
> Windows API perspective;
No. For once, think about what you are asking *others* to do before
stopping at what *you* want, and how the library should get closer to
*your* vision. If needed to be reminded, this is a collaborative effort,
and you're only one the participants.
I'll tell you frankly, that has to be your main point of failure as a
project maintainer, which is hugely surprising, as I would really expect
you to know better from direct experience in various projects. Somehow,
you seem to expect others to be at your every command, be it for patch
reviews (expecting for ACKs or others to lead reviews and whatnot, as
well as complaining that they don't), expecting time to be spent post
haste for every single thing you decide to tag as a "bug" (as per the
present and other issues), reworking an implementation that works fine
for our usage, but that you don't like ("Hey, I spent a few hours
conducting *limited* tests in wine - Therefore, I really think someone
should scratch the many more hours they spent on the exact same effort,
where they came with a completely different alternative, and just spent
the next few days following *my* guidelines"), compensating for compiler
limitations ("MSVC doesn't have named initializers? Someone should work
on implementing that!"), preventing the inclusion of samples unless
broken down as per your ideal vision, and so on...
And I could add that the irony is, when you do decide to take action
yourself, such as for timestamped log or reworking autotools files,
other people's input suddenly need not apply.
So, if you wanna talk about perspective, then let me try to extend your
perspective a little bit: the API is really only one part of it. And
it's far from being the one ring to rule them all. There is such thing
as trying to balance API requirements with resources, as well as user
requests...
>> Thus, unless there is an issue when the device remains plugged, I'm
>> not planning to do a thing about it
>
> That's up to you of course. Thanks for clarifying!
I think I have been pretty clear about this for quite some time.
Thus, I can only hope that it will *remain* clear then...
>> I was referring to the following:
>>
>> On 2012.05.17 14:27, Peter Stuge wrote:
>>> If a device becomes unavailable (which can happen without this patch
>>> too of course) then the backend has to start failing transfers with
>>> LIBUSB_ERROR_NO_DEVICE. Is this what currently happens?
>
> Right, "device" refers to the logical device representation that
> libusb gets from Windows, not the physical thing.
>
> Of course I can work only on code without communicating at all, but
> for a new contributor I think pointers in interesting directions can
> be valuable for getting the problem solved, and they also help to
> show that there is interest in the problem.
BZZZT!
You specifically asked somebody *else* to answer a question *you* could
easily answer yourself. If you really wanted to help Uri, instead of
sending him on an avoidable quest, you would have checked the code to
answer that question, and alerted him to the fact that
LIBUSB_ERROR_NO_DEVICE may not be returned in case of hotplug, in the
remote case he could ever need that information. I kind of felt bad not
replying to that mail actually, to tell him so, but I also expected he'd
have better things to do than invest time on that one.
Considering your history, I think it is fairly safe to state that this
was yet another attempt at trying to get others point to elements that
you could then label as bugs in the Windows backend, which is something
I can't fail to notive you've been going on about for some time now. The
e-mails you sent over these last few months with regards to the Windows
backend are almost comical in the probability of seeing you utter
another one of your "This is a bug" statement at the earliest
possibility, regardless of whether any proper analysis has been conducted.
> You're really overreacting to me clarifying for a user that the
> observed behavior is a (deliberate) bug.
I'm reacting to what I see, which is the e-mails you've been sending to
various mailing lists of late. And they're looking awfully biased, but
short of evidence to back up that bias.
Also I am not reacting to your statement that this is a bug (since I've
gotten very used to your utterance of these words as pointed out above).
I'm reacting to your trying to pass your obvious *opinion* that the
Windows backend should not be trusted for lack of usage and that issues
should be expected there, as an undeniable fact that users should be
alerted to.
>>> What I did write, and you've quoted it several times now, is that
>>> there were few *reports*, which "doesn't mean much" because there
>>> can be many users who do not have the same trouble as Liam but have
>>> not let us know, because everything is working.
>>
>> Well, first of all, more than 2 years of mailing list archives do
>> dispute the "not very many reports of libusb use on Windows",
>> either for expected or problematic usage,
>
> Did you count? How many orders of magnitude off is ten-twenty then?
> Fifty reports would still be "not very many", at least compared to
> the hundreds of thousands SF number.
Hey, didn't you use to state, when it was convenient to you as an excuse
*not* to produce a libusb release, that hundred of thousands of SF
downloads didn't matter that much, and that those users should use git
or distro packages (which, by the way, Windows also has had for some
time through cygwin...).
How about comparing reports with reports, since "not many reports of
libusb use on Windows" should logically be "in comparison with reports
of libusb use on Linux"? Of course, if we do that, then we all know that
your statement becomes complete bullshit, since we're not getting that
many more reports of use for Linus either.
Now if you want to go through an estimate of libusb/Windows use, through
analysis of figures, rather than try to compare SF downloads with
mailing list reports, have a look further down.
>> And you are also now somehow distorting "reports of libusb use" into
>> "reports of bug", which of course changes the meaning of the earlier
>> sentence altogether.
>
> Your sentence is confusing, but I think I understand it. "not very
> many reports of libusb use" does not refer to reports of bugs, but
> refers to reports of use, since I wrote "use."
Which is exactly how I interpreted it. I'm talking about reports of
libusb usage, and your implicit dimissal of libusb usage being that high
on Windows (with high enough seemingly being entirely up to you to define).
>> Still, what would you say is the most logical interpretation of your:
>> "You are the first one to report it, but there have not been very many
>> reports of libusb use on Windows at all, so that doesn't mean much"?
>
> I actually think it is fairly clear as-is, but..
>
>> 1. This is the first report we have for this issue, but not many people
>> *use* libusb on Windows, so there's a good chance it's a major issue in
>> the library.
>
> This is almost right, but you misinterpret the very part you emphasize.
Then pray how is one supposed to interpret this following statement of
yours, that attempted to clarify the above:
> What I did write, and you've quoted it several times now, is that
> there were few *reports*, which "doesn't mean much" because there
> can be many users who do not have the same trouble as Liam but have
> not let us know, because everything is working.
How is "there can be many users who do not have the same issue and for
which everything is working" compatible with your original "there have
not been very many reports of libusb use on Windows at all"?
And let's say your statement was really about the impossibility of
estimating Windows usage "at all", then what was the point of it with
regards to interpreting the validity of Liam's report? It just doesn't
follow.
"Well, there's this thing we don't know. And then there's your report."
> I wrote nothing about how many people use libusb on Windows.
I beg to differ, as per the above.
> We can't
> know that. We can only know what we learn from actual feedback, and
> not many people have said that they use libusb on Windows.
>
> It could be hundreds of thousands, but it could also be ten-twenty.
Or -2 while we're at it. Unless you mean ten-twenty *thousands*, which
would actually be my lowest estimate (in which case you will have to
explain how 10-20 thousand is negligible as a user base)
For this, we can take a look at the latest download figures from
http://code.google.com/p/libusb-winusb-wip/downloads/list, where I
placed the libusb Windows binary archives.
I'm going to be somewhat ungenerous and assume that a vast majority of
the people who downloaded the previous archives will also have
downloaded the the latest one, and thus count only ~2000 unique user
downloads for the Windows binary, ever, in the 2 last years.
With Windows being experimental, and with quite a few more people
expected to want to pick up source rather than binary (since both are
advertised on the same page, and the library is obviously targeted at
developers), I also expect at least an order of magnitude higher rate of
people having compiled from git (but of course, you could have provided
a much better estimate of that if you had analysed clones of -pbatard
from your git server). And I have no idea what to make about possible
cygwin users.
So my estimate would probably be between 20,000 and 100,000 individual
users, for part of a project that was never actually officially released.
How's that for low expected rate of usage of the Windows backend?
> Maybe you'll agree that libusb and libusbx Windows support is still
> experimental though?
I never once said that it wasn't. If you actually bothered to pay
attention to the lists, you'll remember that I actually insisted on
flagging it as EXPERIMENTAL for the first few releases. And this is how
it is tagged in libusbx.
Of course, the reason the Windows backend has to be flagged
experimental, after more than 2 years development is that someone sure
did their darnedest to prevent users from accessing in a convenient manner.
If you value SF downloads as much as you want to make us believe, now
that it's convenient for you to do so, and genuinely would like to have
seen increased usage reports and user feedback for the Windows backend
on the list, then why on earth did you drag your feet for 2 years before
reluctantly providing a release that includes Windows support there?
Also, as per
https://sourceforge.net/apps/mediawiki/libusbx/index.php?title=Main_Page#Supported_Environments,
yet another question you could easily have answered yourself.
Regards,
/Pete
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
