Re: [Simulavr-devel] simulavr and C++

[Klaus Rudolph]

Hi Tod, hi all,



> 
> Klaus brought up a good point about having design discussions versus just
> digging in a writing code and then refactoring. I've tried to start the
> discussions with two things in mind: to get my ideas in the open and/or to
> motivate someone to write some code with or without using my ideas.  It's
> not my intention to discuss the design for ever, but more a chance for
> others to say the design is crap before I waste time implementing crap.
> Another thing I've noticed is that as more features are added it becomes
> increasingly more difficult to refactor out bad design decisions. This may
> be a consequence being written in C, but I can't imagine it not being a
> factor in C++ too.

interfaces in c++ could be much better encapsulated. Any changes inside
that "software parts" could be done much easier than in C, I think.
If there is done a big mistake and the interfaces are wrong: You have 
to rewrite them, it doesnt matter if that is C C++ or what else.
I will give an example where c++ simplifies coding:
If there are a lot off conected pins somewhere in the code the "values"
must be 
calculated. For that you have to write some algos that "know" how the
value is stored and
must be handled. In c++ you simply have a class Pin and can give an
operator "+" for that class.
So you can write simple pin_x= pin1+pin2+pin3. If you rewrite later the
class pin 
to handle also analog values you can simple change the class. The rest
of the program must not
be changed for that while the operator handle all the value
calculations. That is my point of view
why I think c++ is a good language to first write a bit of code, find
out the needs and later refactor it.

 


> 
> So, what does the future hold for simulavr?
> 
> There's my C version. Regardless of what happens in public, I will continue
> working with my code. It does what I need for my continued work with gdb. It
> is very important for me to have a 100% understanding of the simulator so
> that I can know when it's a bug in the sim or a bug in gdb.
> 
> Then there's Klaus' C++ version. It looks like he has done some very
> interesting work there. I'm sorry that he couldn't achieve what he wanted to
> without the fork, but the GPL has given him the right to do what he wants
> with my code and I am fine with that.
> 
> I'm going to leave it to the community to pick the direction they want the
> public simulavr to go. Here's the choices:
> 
> 1: Stick with C. If this is the case, I will continue as developer and
>    maintainer of simulavr on savannah. Of course, in this case, Klaus has
>    every right to continue with his work.

Thanks :-)))

> 
> 2: Convert to C++. If this is the case, I will give the savannah site over
>    to who ever steps up (be that Klaus or who ever). I will step aside and
>    it is very unlikely that I will be involved with C++ development since my
>    C++ skills are not up to par and not likely become so until there is some
>    financial incentive for me to do so. My current job entails C and python
>    programming and I just don't have the time right now to learn C++ to the
>    proper level of proficiency.

As I wrote in my last mail, I am not interested in doing all the needed
"management".
If there  is one or some guys outside which can help to do the
management things I´ll be
interested to do the "technical" things. But I really wont handle
mailing lists and 
add/change user accounts and so on... Maybe that is a killing point
here. But as I wrote:
I need a tool for doing my real work. And the simulator is only a very
small part of
that work I must do. So my job is to write avr code, not a simulator.
All I can and want do
is to develop the simulator that support my "real" work. That do not
mean that there is no way to add features
which other gues needs. There is also no problem to watch out for
"foreign" changes and
maintain the software development. Currently I have no idea how many
time must be spend in maintaining all the
"rest". (User Accounts/Mailing Lists/cvs repositories....). 
If you and the rest of the comunity can accept that I do the technical
(source code) things and some
one else do the rest the project can start here. If simulavr++ becomes
only a one man show I´m not interested at all.



> 
> 3: Fork into public simulavr (in C maintained by me) and public simulavr++
>    (in C++ and maintained by Klaus and/or others???). I really wish to avoid
>    this as it will just confuse users as to which one to use. It would also
>    create some confusion as to where to go for help and/or support. Of
>    course, choice is not a bad thing, but in this case, I think the
>    community is better served with a single focused effort since simulation
>    of all devices with all features with external interfaces is going to be
>    difficult and lots of work. A newbie should only have to think about how
>    to get his avr code working, not which simulator to use because one
>    provides feature set X versus Y.

Absolutly ACK.

> 
> My long term goal is that there will be a single, free, publicly developed,
> AVR simulator that will be the better AVR Studio or any proprietary product.
> I don't care how that goal is achieved, either 1 or 2. I don't think that 3
> will help that goal.

ACK

> 
> I'll be more than happy to turn over the simulavr savannah project to other
> developers if the community would rather see a C++ simulavr. On the other
> hand, I would be very disappointed to turn over the project and see a short
> flurry of activity in converting to C++ (or bringing in Klaus' code) and
> then have everyone loose interest.

Thats what I mean with  "one man show".

> Also, note that taking over the project
> means taking over the mailing list, the download area, the project admin
> duties, the web site, answering user questions, etc. All that takes
> someone's time.

Yes of course. I know that is too much time for me. And I´m not
interested in doing all 
the things as I wrote here and some mails before. 
So if the community wants to have simulavr++, I will spend my code, I
will do the technical
support and maybe a bit more but not much more. And, and that is
important, there must be some
developers which support that project with me. If there is no other one
helping simulavr++ there
is a simple way for me: I do my work for me :-) and make that public
maybe as tar balls somewhere.
Why should there a home site for a project which is only supported from
a single person? That is not what
open source means!
 
In hope the group is not disappointed about that, but I dont want
promise things which I can not fullfill.

Currently we have two solutions for all the users here. So whats todo? 
I think the discussion should start with the question what the community
needs in the simulator.
And we should decide how to fit in the needed features and how man time
this will take with simulavr or simulavr++.
If there are no other developer outside which would/could support c++,
maybe while c++ is not known, 
the group should decide the c solution. 

In a short compact sentence: If the group wants c++ and will also spend
some time for it, I will support
all the technical things, maintain the c++ code, spend my c++ code as a
startpoint and continue my
work with the users here or maybe somewhere else if there is a need to
continue the c solution. I´m not
interested to do a "hostile takeover". Tod have spend a lot of time for
me and my problems and
I hope that my work will not split persons. Thats abolutly not what I
want.... And I think we
all need Tods knowledge in avr-gdb. There are a lot of open points which
should 
go to the gdb port. (code coverage tests, runtime analysis with gprof
and that things, a simplier "run" and re-run
watchpoints and ....).


That is my offer, the group should discuss that now and I think we find
a good solution. Remember: I search good
technical solutions and want not split persons into groups here! I
repeat that, while I think that there is a bit 
of "personal competition" here, what is not needed at all. 

Regards
        Klaus

P.S. I´m not able to support a web site in english. Please don´t ask me
why, please only read my mails :-))))