Re: [Simulavr-devel] Settings for stackpointer

[Klaus Rudolph]

Hi again :-)

> Gesendet: Dienstag, 23. Februar 2016 um 17:53 Uhr
> Von: "Thomas K" <address@hidden>
> An: address@hidden
> Betreff: Re: [Simulavr-devel] Settings for stackpointer
> 
> @Klaus: maybe tiny11/12/15 was implemented in the "old" version 0.1.2.6?

I know that I wrote a 3 level stack sometimes in the early years of simulavr++. 
Maybe I can spend some time to search for this. But it is not so important, if 
it is already gone. I currently need no 1200er... :-)

> It wasn't since I'm "on board"! And with the source control system it's easy 
> to
> check ... So, I don't agree, that so many features are dropped!

The broken TCL interface and the non working tracing are two points for me 
which are gone.


> (most because of missing docu - and
> I haven't forgotten your request about docu for PortPin, it's in work. But 
> you know
> ... god has made the clock, but humans have made the computer!)

Nice to hear that this is still in your mind :-)


 
> >BTW: Can we start to develop new features on branches and merge later on
> >the master? It is much easier to play around with the code base if we
> >can go to an older version, merge some branches in and get the things to
> >work. Cherry picking of single commits is not as easy I believe. :-)
> 
> Why not upload "development" branches. Git is made for that! There should be 
> one agreement:
> only the owner=creator of this branch should change (except there is somebody 
> explicit invited
> to change too) And the owner can also remove such branch without notice (even 
> if it would be
> better to inform the list) And such branches should not live "forever" (in 
> the meaning of
> holding a parallel production version - then it would be better to fork - as 
> Markus made
> for example on github!) And maybe one more agreement: naming of such branches 
> with "dev" or so and
> userid to mark this as development branch from a particular developer.

I have another intention: If someone starts a feature he should start with 
creating a feature branch, maybe per convention feature_xxx. After the feature 
is finished, it can be merged into master. But I prefer to keep all the 
feature_xxx branches for one option: You can later branch fom an earlier point 
and merge only feature 1,4,5 and ignore 2&3. OK, if interfaces are changed 
often this will not help at all. But not every change is a interface change and 
maybe we should spend a bit more time to make interfaces smaller and cleaner... 
Having this feature branches did not cost anything, git is made for this. We 
should simply start doing so.


> 
> Cherry picking is easy - sometimes. :-) It depends on how and what. I've 
> cherry picked a few days ago
> some changes from master branch to rel-1.1 branch. Just one command and 
> finished ... (but I know,
> that there are cases, where it's better - because less effort - to copy 
> source and create a new commit)

I hate cherry picking. Having a branch is quite clearer. And you can merge a 
branch without any additional overhead to multiple other branches. So if 
someone have a "private" dev branch, he can merge it or leave it. He must not 
deal with commit ids and must not know which commits must merged together. It 
makes the things easier to have feature branches!

> 
> >I especially ask for that, because I want to create my own branch where
> >I will get the old tcl interface and the old tracing stuff to work
> >again.
> 
> You got a "like" from me for this plan! :-) My problem is, that I don't use 
> tcl and have not
> time to support it in all features ... (even if it should work basically!)

It is mainly a "going back" to the old interface. I have no idea why so many 
things have simply overwritten without a functional change. It makes no sense 
to discuss this today. It has happened but it breaks my work and makes a lot of 
things unusable for other users too. The current tcl scripts are totally over 
engineered. never seen such a reverse include stuff only to get remove some 
lines... unreadable!
> 
> >And if so, it is easier to get new features with merging branches and not by 
> >cherry
> >picking unordered commits.
> 
> This is definitively right.
> 
So just do it :-)

> >I also need the decoded instructions in the
> >more or less old version to have the trace info which was dropped from
> >the current source.
> 
> What's dropped? Sure, there are some changes in this section and so there is 
> maybe some output different
> from the old version. But it shouldn't be lost!

Tracing contains no information of values written to memory or registers. So 
tracing only contains the stack information and the pc. That's not what I need 
:-)
And the "trace output dump bla bla manager" is much stuff to replace a cout. I 
have no idea what is the intention to make it so complicated. And in addition, 
the code is still broken. The "manager" crashes after a few seconds. I made a 
workaround for tracing but I have no idea why the implementation is so 
confusing. If I have a avr project next time ( don't know what "next" means :-) 
), I will spend some time to get the old features back. Maybe it is possible to 
get a simple interface to use "both" kinds of output. Again, the current 
tracing is useless for me.

If some code can not be kept we should discuss a proper solution before we 
start implementing. Merging on master should only be done if people agree with 
that. Simply that.

Because I go back with the sources for my personal needs, I will start with a 
personal branch. I will drop a lot of code which I personally did not 
understand, which is only a rework of existing code without benefit and code 
which breaks my needs. I will do it only on my branch but I will prepare also 
feature branches for that. Maybe some other people want to have also a simpler 
version to start from that point. The current code is a bit to complex for the 
simple things we achieve. Maybe that's only my position.

And another thing on my personal list: remove all new avr_error / assert 
things, if they can be replaced with a useful alternative. There was already an 
answer that the thread recognition can be removed, because it simply had never 
worked.

Enough things to do :-) I have currently a big other not avr related project. 
So my start point is "somewhere" in the future... Nobody should wait for my 
contribution in the moment :-)

OK, so we should start working in feature branches, do a bit more docu and 
especially unit tests and should not remove things which are not disturbing new 
features. Thats all :-) Meta discussions why all is bad and users are stupid 
are not on my todo list. And I hope we will not have such "discussions" again!

Regards
 Klaus