CeDeROM wrote:
> I would really prefer to talk over the code, rather than dreams :-)

Yes, I agree.


> mpsse driver is just a different interface to the MPSSE engine of
> FT2232, its direct communication using libsusb, not libftdi, so
> there is an efficiencly improvement. How does that relate to the
> architecture change of OpenOCD?

It doesn't at all. As I wrote, the ft2232/mpsse is just a "simple"
issue with the current proof of concept, but it is very much work in
the wrong direction, which is enough reason to not include the code.

It has nothing to do with OpenOCD internals.


> >> If we really don't get any consensus, it will be necessary to
> >> fork the project I guess
> >
> > Don't you realise that you already did that when you said that
> > you do not want to change your code?
> 
> That concludes this trolling discussion and your ignorance..

Don't tell me that I am ignorant, work with me to understand what I
mean instead.


> I said I dont want to change my code because the changes are on
> purpose and I need good argument to change anything. I am open for
> discussion and good arguments. I did not say its impossible, I just
> need a good argument.

Awesome! I don't think anyone understood that this is your attitude
for these changes. I sure did not. I think this is a big
misunderstanding in this thread, thanks for clarifying that!
(I was really surprised about how I first understood what you wrote.)


> Rebasing changes and editing commits is not enough, I told you can
> do it if you feel its mandatory, for me its not.

I think a big part of the misunderstanding is that you seem unwilling
to even do a simple rebase. It signals that you aren't really
interested in having the commits included into openocd.git,
or at least not in their current form, but that you expect someone
else to change them. I now understand better what you mean, I think
everyone was under the impression that you pushed the commits with
the honest intention for them to be included in openocd.git as-is,
and in that case you really have to be prepared to do some rebasing
as the repo changes underneath, and to take whatever feedback there
is into account. For proof of concept that's of course not neccessary
if there will anyway be some major changes going forward.


> I have applied most of the changes requested by Spen. Still you
> complain.

I disagree - I haven't read the code so I can't complain about it,
and I don't believe that I have. The only real issue so far that I
know of is using ft2232.


> I expect to get better solution instead only telling what is wrong.

That is also not quite realistic. Of course there will be some
suggestions but I don't think anyone who does review will produce
a better solution. The idea with review is that you get feedback
which you can make use of while reworking the code.


> you seem to have no alternative no idea no plan no example to
> share. I am still waiting for that.

Sure - but if I had a good design I might already have implemented it.


> This work is a good starting point. Solution that works. Its a
> proposition of the solution, not the only acceptable solution.
> It can be day by day improved.

I certainly agree with all of this!


> It will be easier to improve code that works rather than working
> with imaginary solutions and plans for upcoming years.

I disagree completely with this, but I also recognize that it is
very much an individual thing. I for one am vastly faster at working
on code in my head than in files.


> I dont care how other projects work nor how bridges are built

I think it's a good idea to reuse what seems to work for others.


> There are no constructive changes over the current proposition in
> the code, not even here on the list. This tells me a lot what could
> happen in future when bigger changes are necessary to introduce.

I don't think it makes sense to extrapolate assumptions like that.
I've already pointed out: you made lots of changes and pushed them in
bulk, while stating that you weren't interested in updating them.
That sends the worst possible signals to those who might otherwise
want to do review.

Other than that - I think people have just not had time. Weeks or
even months is not really a very long time for a project which might
not be everyone's highest priority. Things happen when they happen.


> If you have nothing constructive to say, say a lot about things you
> don't even read,

Please separate things I say about code in general from things I say
about specific code. I haven't said much about your commits,
specifically because I haven't read them yet.


> and I am supposed to do all of the work alone,

That's the exact opposite of what I would hope for, but in reality
you *have* worked on LibSWD all alone. For good and bad - the good is
that it now works because you didn't have to wait for any discussion,
the bad is that there was no discussion, not so much for LibSWD which
is your project and you should do that whatever way you like of
course, but for OpenOCD and how it should interact with LibSWD.

It is no surprise that SWD does not fit very well into OpenOCD, so
I think much of the disappointment and critique in this thread is
about ignoring that rather significant problem, talking about
"restrictions by existing code" and then expecting LibSWD commits
to be included exactly as-is without a single minor touchup or even
rebase. I think I'm discovering that actually this isn't at all what
you intended to communicate. I think that's a good thing! :)


//Peter

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to