simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Undo the fork ...


From: Petr Hluzín
Subject: Re: [Simulavr-devel] Undo the fork ...
Date: Tue, 23 Mar 2010 22:39:42 +0100

Hello

On 24 March 2010 00:05, address@hidden <address@hidden> wrote:
> On Tue Mar 23 14:20 , Onno Kortmann  sent:
>
>>Hi Michael,
>>As soon as the git is setup, just mail me off-list with your potential
>>problems of getting the code. As it will not include any of the fancy
>>git-cvsimport stuff, doing a checkout/update will be easy.
>
> In my experience, "It's easy" means that the utterer
> has been doing it long enough to be comfortable.
> Once habit takes over, people tend to lose the
> ability to explain it to people who find it hard.

I feel the same. Even integer factorization is easy - when you know the primes.

> Even if I manage to git code out of savannah,
> the semi-dead body will be a worry because I won't
> know when something else will decide to emulate it.
> When not causing actual worry,
> it will still be an annoying example of ignorance.

As long as I will have enough willpower I will fight these "oh that's
easy you just have to do/know this and that" attitudes. Join me on
this crusade!

That is why I suggested fixing and relaxing criteria for entering
"correct" MCU type.
This is why I added the patch that displays frequency in MHz. (And
fought when someone marginalized the issue.)
This is why I added the diagnostics (instead of crash) when user tries
to run simulator without a program.
This is why I added a diagnostic to detect gdb of wrong architecture.
(Once I spent a day hunting down the problem.)

If you know any other simulavr's unfriendly behavior then tell me - I
always want to fix that.
The same for completely different program - just persuade its
maintainers first (this is the hardest part).

The same goes for a program's internals.

-- 
Petr Hluzin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]