14.04.2012 21:51, Bart Oldeman написал:
> On 14 April 2012 04:27, Stas Sergeev wrote:
>> I was always subscribed there, I checked that many
>> times, and the mail delivery knob was set to enabled.
>> Yet you said I was somehow unsubscribed because
>> of the bounces, and that was true: delivery didn't work
>> until I posted to the list.
> I tried to subscribe you to dosemu-cvs now under your list.ru address.
Ah, thanks, I thought it was dosemu-notify in the past...
> I'll change e_invalidate to have addr as a DOS address (i.e. unsigned
> int), and then it can do the right thing
Thanks!
This will "magically" fix my EMM patch, as currently
you'll just get a log full of faults and an inadequate
performance with it and non-zero mem base.
>>> One problem is that there are still quite a few places that don't use
>>> the READ_BYTE (etc) macros, and take pointers directly into DOS space
>> That's horrible... how much of them are still in?
> Too many.. Do a grep for MK_FP32 and Addr (an older alias for
> MK_FP32). These macros are the main culprits for the&mem_base[xxx]
> pointers. Note: when MK_FP32 does the right thing we'll also need to
> change FP_OFF32 and FP_SEG32!
Ahh, now I see the problem!
You needed to adjust them to mem_base to be able
to later substract the mem_base in FP_OFF32 macro,
but would you use dosaddr_to_unixaddr() instead,
and the FP_OFF32 macro would start to require some
kind of unixaddr_to_dosaddr() which is completely unexpected.
The good thing is that there seems to be only 20-30
instances of MK_FP to fix.
Maybe the right thing to do would be to even convert
those macros to the structure of seg,off instead of int?
> that would be dosaddr_to_unixaddr(fuckedup_dos_addr-mem_base) -- but I
> get your point.
> Then it's basically the same thing as the
> LINEAR2UNIX(fuckedup_dos_addr-mem_base) that I mentioned a few emails
> ago.
OK, I didn't know the precise definition of the fuckedup_dos_addr
a few mails ago. :)
> I was thinking of Mercurial myself simply because the transition from
> svn would be smoother (and it keeps the revision numbers that are also
> in the changelog history) and I have a bit more experience with it
> than git.
I tried hg actually before started to use git, and was
completely unsatisfied with its stance on the newcommers.
I was stuck with the simple things, and when asking for help
in the MLs, I was getting the replies like:
---
Append
[extensions]
mq=
to your ~/.hgrc. (You may need "hgext/mq=".)
Enabling hgk ("hg view", requires Tcl/Tk), hbisect ("hg bisect") and
patchbomb ("hg email") may also be useful.
---
which looked too cryptical for novices. :)
And with git the startup was very smooth, because it
always gives you a hints, like "you can't do this, try that
instead", or "you have done that, now you may likely to
need to do this" etc, so my conclusion was that git is
the most user-friendly thing. :)
> But then I could still setup git on the server and use
> hg-git locally. I'll have a look how to set it up later. If you have
> time before you can always use git-svn for now I suppose.
OK.
I'll see if I can start doing something of what we got to,
so that the patch can be properly integrated.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Dosemu-devel mailing list
Dosemu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dosemu-devel
