Discussion:
Big Commits
Kailash Sethuraman
2005-12-01 10:35:59 UTC
Permalink
Hi,
Gmail has been acting up, I couldnt send the mail I wanted to
yesterday, anyway there was a big commit yesterday. I actually had
work that overlapped with Peter's previous commit, hence had to merge
them and ensure the commit went right. Vg still does not compile, but
we are getting there, *again* sigh. I think that we need a different
approach to commits.

I propose that any further changes to valgrind, by us should be encapsulated in
/* vg4nbsd */
/* !vg4nbsd */ comments.
We may work on arch indep things, so VGO_netbsdelf2 ifdefs may always
not indicate where our changes are. This makes us clear when we have
changed logic.
Lets do this going forward?
Peter I have answered your question about do_pipe_inner in the code.
sys_pipe's semantics differ on linux and netbsd, do_pipe_inner is a
stub to convert the semantics back and forth. Instead of having
VG_(pipe) take different arguments and littering code all over.
I might have based it on netbsd's linux emu implementation. I forget if I did.

Is it possible to get svn to write to our ML. Anyone done this before?

Regards,
Kailash
Peter Bex
2005-12-02 00:40:10 UTC
Permalink
Post by Kailash Sethuraman
Hi,
Gmail has been acting up, I couldnt send the mail I wanted to
yesterday, anyway there was a big commit yesterday. I actually had
work that overlapped with Peter's previous commit, hence had to merge
them and ensure the commit went right.
How'd that happen? It's always a good idea to start the day by doing an
update and checkin when you finish for the day. That way, nobody does
any double work. That's just a waste of resources, IMHO.
Post by Kailash Sethuraman
Vg still does not compile, but we are getting there, *again* sigh. I
think that we need a different approach to commits.
Perhaps that's a good idea.
Post by Kailash Sethuraman
I propose that any further changes to valgrind, by us should be encapsulated in
/* vg4nbsd */
/* !vg4nbsd */ comments.
We may work on arch indep things, so VGO_netbsdelf2 ifdefs may always
not indicate where our changes are. This makes us clear when we have
changed logic.
Lets do this going forward?
Is this really necessary? We should let our tools do this for us. For
example, we could tag (copy to /tags) after we finish synching with a
version of Valgrind main code. Then we can simply do svn diff on the
trunk and the tag to see what has changed in between.

What are your thoughts on this?
Post by Kailash Sethuraman
Peter I have answered your question about do_pipe_inner in the code.
sys_pipe's semantics differ on linux and netbsd, do_pipe_inner is a
stub to convert the semantics back and forth. Instead of having
VG_(pipe) take different arguments and littering code all over.
I might have based it on netbsd's linux emu implementation. I forget if I did.
Aha, I see.
Post by Kailash Sethuraman
Is it possible to get svn to write to our ML. Anyone done this before?
It's possible alright, just like with CVS. Valgrind does this too, right?
I've never done it though, so I wouldn't know where to begin.

Regards,
Peter
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Kailash Sethuraman
2005-12-02 09:19:00 UTC
Permalink
Hi,
Post by Peter Bex
How'd that happen? It's always a good idea to start the day by doing an
update and checkin when you finish for the day. That way, nobody does
any double work. That's just a waste of resources, IMHO.
Yes, the problem was that i was working on it the previous night, but
broke m_main.c.
I had to redo the diffs. Its still incomplete by the way. I didnt
commit because of that.
Post by Peter Bex
Post by Kailash Sethuraman
Vg still does not compile, but we are getting there, *again* sigh. I
think that we need a different approach to commits.
Perhaps that's a good idea.
Post by Kailash Sethuraman
I propose that any further changes to valgrind, by us should be encapsulated in
/* vg4nbsd */
/* !vg4nbsd */ comments.
We may work on arch indep things, so VGO_netbsdelf2 ifdefs may always
not indicate where our changes are. This makes us clear when we have
changed logic.
Lets do this going forward?
Is this really necessary? We should let our tools do this for us. For
example, we could tag (copy to /tags) after we finish synching with a
version of Valgrind main code. Then we can simply do svn diff on the
trunk and the tag to see what has changed in between.
What are your thoughts on this?
Sounds like a plan. However will it be easily visible when we do the next sync?
Rather than doing an svn diff to check and then check against another diff?
Post by Peter Bex
It's possible alright, just like with CVS. Valgrind does this too, right?
I've never done it though, so I wouldn't know where to begin.
Will look into it.
Peter Bex
2005-12-02 11:05:59 UTC
Permalink
Post by Kailash Sethuraman
Post by Peter Bex
Post by Kailash Sethuraman
I propose that any further changes to valgrind, by us should be encapsulated in
/* vg4nbsd */
/* !vg4nbsd */ comments.
We may work on arch indep things, so VGO_netbsdelf2 ifdefs may always
not indicate where our changes are. This makes us clear when we have
changed logic.
Lets do this going forward?
Is this really necessary? We should let our tools do this for us. For
example, we could tag (copy to /tags) after we finish synching with a
version of Valgrind main code. Then we can simply do svn diff on the
trunk and the tag to see what has changed in between.
What are your thoughts on this?
Sounds like a plan. However will it be easily visible when we do the next sync?
Rather than doing an svn diff to check and then check against another diff?
I don't think that's possible. AFAIK it is required to do svn diff and then
diff against the new Valgrind. So on second thought, that's not an
acceptable option. I guess we'll have to do it your way, by marking those
spots with comments.

Peter
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Kailash Sethuraman
2005-12-02 11:48:21 UTC
Permalink
Post by Peter Bex
I don't think that's possible. AFAIK it is required to do svn diff and then
diff against the new Valgrind. So on second thought, that's not an
acceptable option. I guess we'll have to do it your way, by marking those
spots with comments.
Yes, but I think its also good to tag once syncs are completed.
So we should implement both. once this sync is completed, we will tag,
on subsequent changes, we shall encapsulate changes in comments.

Kailash
Peter Bex
2005-12-02 18:34:35 UTC
Permalink
Post by Kailash Sethuraman
Yes, but I think its also good to tag once syncs are completed.
So we should implement both. once this sync is completed, we will tag,
on subsequent changes, we shall encapsulate changes in comments.
Agreed
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
Eric Auge
2005-12-06 22:29:40 UTC
Permalink
agreed for the comment plans, I'm just back from some busy job time :),
updating valgrind right now, where are we ?

Eric.
Post by Kailash Sethuraman
Post by Peter Bex
I don't think that's possible. AFAIK it is required to do svn diff and then
diff against the new Valgrind. So on second thought, that's not an
acceptable option. I guess we'll have to do it your way, by marking those
spots with comments.
Yes, but I think its also good to tag once syncs are completed.
So we should implement both. once this sync is completed, we will tag,
on subsequent changes, we shall encapsulate changes in comments.
Kailash
Loading...