On 2011.02.25 18:20, Peter Stuge wrote:
> I think it is unproblematic, so I see it being committed relatively
> soon. Only thing might be if we should do the backend register thing
> first, to get out of the bad situation with the Windows code lacking
> named initializers.
OK, I was hoping someone would reply to that first, to save you the
"Libusb: more concerned about bringing C99 features to C89 compilers,
than producing what is actually needed for a release."
Please have a look at Hans latest patch proposal, and tell us we need to
fix Windows lacking named initializers because...? Hans even explicitly
indicated so ("Note this patch does not add any OS specific code). Do
you even read proposed libusb patches?
And this clearly exposes your real problem as a maintainer right here.
If you ever deem that something is "unclean", you seem to go into tunnel
vision mode and will ignore anything else. Just like you took your
wishes for reality of WinUSB and HID accessing the driver directly,
without going through a DLL, there again, you place your wish of a C99
like MSVC above the reasonable course of action which is not to add
anything we don't need to do for a release that has been delayed way too
much. And once more, you go into absolutes "C89 = bad situation" (oh
really?), which I can't help to also find quite inconsistent since a few
months ago, as we've previously established, your view was that we
didn't have much of a choice but to go C89 on the whole project...
Now, if you want to do something actually "good" vis a vis C99 features,
how about providing some __VA_ARGS__ equivalent for MSVC6. That's a
feature I could _actually_ use on K, since compilation is currently
expected to break on MSVC6.
>> If it's before Windows,
> If by Windows you mean libusb-pbatard.git is same as libusb.git then
> yes, I find that very likely.
Eventhough we currently have 1/3rd of a feature, and don't know when the
2 other 3rds are going to be completed. Don't worry, as far as Windows
is concerned, as I've already pointed out, it shouldn't be that
difficult, so I'll see what I can do. But priority wise, K support will
take precedence over get_speed.
> But actually it depends on what commits or patches there are. At the
> moment, what I think you mean here is available as libusb-pbatard.git,
> which is perceived by me as requiring very large effort to come into
Let's discuss this again when my integration branch is up.
> If I understand you correctly you consider it to be not
> that bad, and if there are patches which require no effort by me then
> they would of course get to libusb.git quicker.
Indeed, I don't think it should be that bad. I may be wrong, but most of
the stuff is new-enum, which will occupy a single commit.
On that subject, would you be OK with factorizing the hash_table I use
on new-enum code into core for integration? I don't think we can escape
the need to use a hash table (for device UIDs) for hotplug, and my
understanding is that Nathan could also use one right now, to speed up
OS-X enum. So I think it would make a lot of sense to just go for it
while we're at it. It would only be used by Windows in the proposed
patch of course (=> wouldn't impact core functionality), and left
available for use to the other platforms. This would also probably
reduce the complexity of the hotplug patch once we do it.
> I pushed my current tree to libusb-stuge.git master,
Thanks. I've been waiting on that.
> but it will change further
Meaning commits that currently exist might disappear.
I'll see if I can live with that, but please understand that if it
becomes a PITA, and I have to waste my time resolving conflicts as a
result of using a branch that is not stable, I will switch my
integration base to official. As a result, this current attempt at
creating an integration branch will be suffixed by -temp.
> The configure.ac changes may or may not be
> finished, but maybe this is enough for you to move forward?
> (You could also just ignore configure.ac and fix that up in the
> relevant commit after the changes are in libusb.git.)
And waste time that I know I can avoid wasting? Not gonna happen.
>> the priority of a non existing API can hardly be expected to take
>> precedence over the ever delayed Windows integration
> Sure it can. Especially if a new API requires very little effort.
Yes, let's push for _incomplete_ features as we speak, and ignore the
completed one. If you want incomplete proposals, I've got a get_port and
all its friends for ya. The thing is, it's pretty much the same thing as
get_speed. We know we want topology, and we've established (accordingly
with some difficulties) how we want to introduce it. And it's in the
exact same state as get_speed (i.e. 1/3rd complete). But of course,
you're not going to want to integrate that because...?
> Another example of something that comes "before Windows" is Graeme's
> API change that moves event completion condition checking around,
> though it requires a bit more effort than the get speed API.
OK, I will have to look that one up, coz I haven't paid any attention to
it. Can you summarize how you see it as a necessary change before
Windows, because had I seen it so, it would be in my branch right now. I
think I actually integrated some of Graeme's patches that didn't make it
into mainline some months ago, so maybe it's already there.