[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] test mechanism
From: |
Thomas Klepp |
Subject: |
Re: [Simulavr-devel] test mechanism |
Date: |
Tue, 25 Aug 2009 20:26:37 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
Hi Michael,
now I have time to answer.
I thought it was something like that.
I'd inferred that methods that referred to
"non-existent" methods would need similar treatment.
This problem, that SWIG dosn't "translate" some operator methods comes
from, how SWIG creates interfaces. All class methods, which SWIG found
will be encapsulated in just normal C functions. And, for example for
python, this functions will be collected in tables, which represent on
python side for example a class. That SWIG now can't "translate" some
methods is because this mechanism. A translation function itself can
handle operator methods like a assignment. So it's no danger for
malfunctions because of not translated operator methods. It's only, that
such operator functions couldn't translated.
In any case, the more general questions are what is to be development
protocol and will it change while I am working on something messy.
Yes, that's really a question. But I can't answer this. Nobody from
sinulavr maintainers has given a statement, what's the way to future.
Stay on CVS, maybe backport changes from git (but this is now a lot of
changes) or switch to git or whatelse.
My question points to that, that in git repo we use a derived class from
RWMemoryMember, called IOReg. Your code would work too for registers,
This is different from the CVS version?
Yes, IOReg gives a connection between hardware units and rw memory
array. Before you had external RWMemoryMember classes, which connect
memory array to hardware unit. Now IOReg registers are member of the
hardware units.
Before it was (for example):
rw[0x63] = new RWPin(this, portg);
Now it's coded as:
rw[0x63] = &portg->pin_reg;
I think, this idea from Onno is easier to understand and easier for
changes and maintainance.
I made sbi and cbi virtual so they could be overridden.
Whose git repo is "git repo"?
Yep, also a good question. :-) My repo is a fork of Onno's, but we have
agreed, that's not a good idea to have more than one. The most of
reasons are connected, how this forks can be synchronized, the best is,
to get it fully synchronized. But for that it's not necessary to have
forks. But Onno is busy with other things and so I have made some
development on my fork. The plan is, if Onno have time, to sync my fork
to Onno's repo and then to delete my fork. In the moment, my master
branch is younger (and more current) than Onno's.
I expect to need to use git eventually,
so what is the best way to make progress?
The easiest starting point for you (in my opinion) would be: install
git, pull (for example) my master branch with "git clone" (see "git help
clone" for help). So you get a workarea and a view what's happen here.
bootstrap, configure and make work as usual (for you it's necessary to
give configure also the option --enable-python to get the python
interface too) I have tried to describe something, how to use git, see
the wiki on my repo site.
For your own changes it's the best to make your own development branch,
starting from master branch. So (and if you don't push this branch to an
remote repo) you get a private branch for your changes. Later it's
possible, to merge back your chnages to master branch or to pack a
patchbomb of your changes to send it by mail, to sync new changes on
master (after "git pull master") to your private branch and so one. And
of course, you can delete also branches, if you want. :-)
And because git don't need a server, you can try all operations before
on local clones of a repo. (just to try or to learn more about git, I
have made it also in this way).
cu, Thomas
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/15
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/17
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/18
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/19
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/19
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/19
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/20
- Re: [Simulavr-devel] test mechanism,
Thomas Klepp <=
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/21
- Re: [Simulavr-devel] test mechanism, address@hidden, 2009/08/25