Re: [Simulavr-devel] [patch #7032] unitialized HWUart, did never finish sending

[Petr Hluzín]

Hi Thomas

2009/12/22 ThomasK <address@hidden>:
>> Do users test if their MCU type is ok for compiler by feeding it to
>> simulator the first? I think they do not, they feed it to compiler
>> first (usually by makefile). In such case the relaxed requirement in
>> simulator does not matter.
>
> If you write and compile a program at first and then start simulavr by hand.
> People are (ok, should be ... ;-) ) flexible enough to use the right
> writing.

Flexible, yes. The proposed change does not restrict flexibility even
a bit. Actually enlarges a bit.

> But think about automated test systems and the scripts behind. If you use 2
> forms to explain device type, you have to configure it. Two times the same
> information with different writing is one possible source of mistakes. And
> such automated tests are necessary! I have found some bugs in code by using
> (now more extended) regression tests over all device types. And we need much
> more of such tests!

Yeah, regression tests are good. The proposed change does not break
the tests. The "any-case-you-want" feature is probably not worth
testing.

>> I have not, my changes are bit older. My repository is based on CVS
>> around 2009-06. I made quick look at Onno's git repo. I found some
>> interesting changes and some fixes I independently made, too. I found
>> a discussion about a repository/version-system on the list but I did
>> not see a conclusion.
>
> That's right, there is no conclusion. What's your opinion to this
> discussion? Stay on CVS or change it?

I do not know what is better for the project.

For me: I am not familiar with anything else than CVS and Subversion.
Learning new ideas is acceptable for me, but I have ideological
difficulties with learning tools implementation details,
oops-we-implemented-it-this-way issues, human-machine translations
("If you want it to do the common thing you have to specify -a -b
-c").

On my Windows machine I could use TortoiseGit (or Tortoise- anything,
they look all the same) so Git is mostly fine. For my Linux there are
no simple GUIs, I am afraid. (And command-line interface to Git is
difficult, I have heard.)

>> (I want to keep some changes in my private repository.)
>
> Why not, that's possible and normal. And with git it's much more easy to
> hold such changes in private branches and to participate in all new changes
> from "offcial" branches. (or other private or development changes of course)

I meant private as "not available to public" - because of my
assignment. The changes will be published when it is done, which may
take a year or more. Do not hold your breath. I am aware of the future
merging hell. (Although git or other distributed tool may ease it.)

I plan to publish patches unrelated to my assignment, like those I
already submitted, though.

-- 
Petr Hluzin