simulavr-devel
[Top][All Lists]
Advanced

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

[Simulavr-devel] Executive decision: status-quo on names, request for he


From: Bill
Subject: [Simulavr-devel] Executive decision: status-quo on names, request for help in addressing confution issue.
Date: Mon, 20 Dec 2004 17:00:15 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, I think an "executive decision" has to be made...

As I am only aware of Klaus and I having direct access to this
project, I'd like to second Klaus' ideas and add my own:

1.) simulavrxx likely does not drop in replace simulavr in enough
places to supercede simulavr yet, (I'll trust Klaus on this)
2.) I have not seen anyone ask to step in to support simulavr.
Granted, I don't think anyone asked for volunteers as such
either...but without an active simulavr developer, I think it will
eventually be superceeded by simulavrxx. My guess is that we'd simply
leave simulavr alone in the tree, perhaps with some helpful notes in
that final version, and from there on make simulavrxx install a link
from simulavr to the real simulator, simulavrxx.
3.) The open question I feel the simulavr[xx] developers might present
the community is this: What simple changes, perhaps to website only,
could we make to address the issues of confusion. Answers in forms of
patches or sample textx, webpages preferred.

There are many ways to skin this cat. If it would help to update the
website in some way, please let me know. I know I do not feel I have
shepherded this project very well as of late. I have my reasons, but
the result is what matters.  And everyone's point is well taken.


Now for some rambling:

I have heard some report that simulavr C, and that make interfacing
easier somehow, and they don't need to install C++...
1.)I don't understand why installing C++ is a problem, so I may find
enligthenment there.
2.) What is the problem interfacing C and C++? I assume it has to do
with the C++ runtime initialization requirements being different from
C? I wouldn't mind someone trying to explain this to me, off-list if
desired. Perhaps there is something worth accomodating in the C++ code?

Any help/ constructive criticisms are welcome.  I for one suspect
there are features in savannah that I could use to better post work
that needs to be done and assign tasks (even if only to Klaus and I)
so that people can see what develoments are underway, and perhaps chip
in here and there.  I haven't really read up on all the savannah
features available to me.

I do have windows available to me, and have collected preliminary code
and information that I should be able to use to enable a proper win32
build. I also heard someone had taken on looking into this as well,
but I have seen no results yet.

~ The Holiday's are almost upon us, so let me just add: Merry Chrismas,
(belated?) happy Hannukah, Joyous Holidays and whatever else you may
like to receive well wishes on!

I go away for holidays, so I will likely not be paying close attention
to this project. Whether I'll have net access is dubious.

Cheers,

~ Rudolph wrote:

|
|>
|> I have another item that I would like to address, and that is
|> naming.
|>
|> I know that the new program has been called simulavrxx, to show
|> that it has a C++ code base.
|>
|> But ultimately it was derived from simulavr, which I think is a
|> fine name.
|
|
|
| The first step of implementation was derived from simulavr, right.
| But after a while it is completly written new. Only the instruction
| decoder and some code for gdb is from simulavr. Actually it makes
| sense to have both, because simulavrxx is not complete and could
| not complete replace the simulavr. So if there are windows users
| they have only th chance to take the simulavr. If you need the new
| feature set you have to use unix and simulavrxx. If we can fullfill
| all needs from both user groups we can change to simulavr. But this
| will take a while I think.
|
|>
|> I feel that if you continue to call it simulavrxx, it will just
|> make it more confusing to users as to what it is.
|>
| I think in the moment it clarifies the situation. It is important
| that we have these both tools which are really different.
|
|> I would like to propose that you call it simulavr, but with a
|> different version number please. I understand that the internals
|> are vastly different.
|>
| Not yet I think. Simulavrxx is a complete different thing which
| have the same target: simulation of an avr. I think that is also a
| bit philosophy :-) If you want to name simulavrxx to simulavr we
| have to remove simulavr? I think that is not a good decission in
| the moment. And keeping two different serial number version arround
| makes it not better for us is my opinion.
|
| But if all the guys arround think simulavrV2 is better we can just
| do it :-)
|
| Bye Klaus
|
|
|
| _______________________________________________ Simulavr-devel
| mailing list address@hidden
| http://lists.nongnu.org/mailman/listinfo/simulavr-devel
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBx0tsuZBxYuVmoeoRAjgNAJwP8oXTXZpSeSoJSxjQh35zAfc+dwCfddqI
JDqbwjNo5ppH1wA5SEEB7eg=
=aYlO
-----END PGP SIGNATURE-----





reply via email to

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