Daniel Barlow wrote:
> William Harold Newman <william.newman@...> writes:
> > Incidentally, if anyone thinks I'm doing something less than optimal
> > in the CVS admin, you're probably right, so please speak right up,
> > since I'm pretty unfamiliar with any but the really basic features.
> My experience has been that it's generally better not to develop on a
> branch if it's avoidable - use the HEAD for developing and the
> branches for "stable releases that might need bugs fixed". That's
> more of a guideline than a rule, though; it makes "cvs log" and the
> web-based tools a lot more informative. And means that all the new
> files you create on the branch don't end up in the Attic for most of
> their working life.
> The _rule_ is "be sure you tagged the point that you branched from"
> (i.e. a static tag in addition to the branch tag) because merges onto
> the HEAD are murderously difficult otherwise.
If I understand correctly from the CVS info pages, the branch actually
remembers where it branched from, so I should be able to use "update
-j" (I think) for the first merge without too much pain. It does looks
as though repeated merges would be horrendous unless I remember to tag
earlier merge points so that I could use the "update -j
previous_merge_point -j branch" idiom (or maybe it's the other order,
dunno. Since I only intend to do a single merge on this branch,
after which I intend never to use it again (since the next time I
need to check in something unstable I can make a "flaky2" branch,
and so forth) I hope I'll be OK without a root_of_flaky2 tag.
I'll find out soon one way or another..
I hadn't thought about the CVS log issues. After I do the merge, I'll
look at the cvs2cl.pl output, and if it's insufficiently informative,
I'll see about copying or summarizing from the flaky1 checkin messages
into the main branch log messages after the merge.
> > I suspect that at least some of the current problem is partly "your
> > fault", perhaps because of changes you made in the way that
> > current_region_free_pointer is used. But the behavior of
> um ... um ...
> I haven't touched current_region_free_pointer - in fact, I didn't know
> it existed until I just grepped for it. gencgc.c is a closed book to me.
> current_dynamic_space and dynamic_space_free_pointer I accept full
> responsibility for, otoh
Argh, yes, I was confused between the current_foo variables. Far from
my only confusion this week, alas.
> > I do think causing the GENCGC code to use current_dynamic_space
> > without initializing it was a bad idea, though:
> > +#ifndef GENCGC
> > + current_dynamic_space = DYNAMIC_0_SPACE_START;
> > #endif
> validate.c? I think the line is redundant anyway, actually.
> current_dynamic_space is initialized in coreparse.c (line 85ish) from
> whatever the core file says it is. It could be DYNAMIC_0 or _1 anyway
> (whichever was current when we dumped), so that code in validate is
> bogus 50% of the time even when it is compiled in.
Argh, more confusion. I was somehow thinking that if it wasn't
initialized unless a core file was loaded, that was a problem, but of
course core files are always loaded.
> > and then all the stuff which used to use DYNAMIC_SPACE_START using
> > current_dynamic_space instead.
> It is entirely possible that I missed something there, yes.
> Incidentally, I don't know if renaming that variable to
> current_dynamic_space_start is on your list of proposed cleanups,
> but that and sorting out the visibility of dynamic_space_free_pointer
> (globally available on some ports, static on others) are two easy hits
> that would probaly make the system substantially less likely to bite.
You probably did it better than I did. As I posted a few minutes ago,
I've mostly reverted back to 0.6.12.7.
I'll try to clean up my little list and post it. It actually needn't
be a near term issue for you, though, since I probably won't do
anything about it until August or later, and if for some mad reason I
do, there's a fair amount of internal-to-GENCGC cleanup I could start
with without impacting the stop-and-copy GC world.
On Thu, May 17, 2001 at 08:09:58PM +0100, Daniel Barlow wrote:
> My experience so far with flaky1 (x86 linux) is that
> 1) it builds
> 2) it appears to run unpurified, but I don't have the ram to wait for
> it to build anything, so I haven't got through more than about two
> files that way
> 3) it purifies (it's most likely that I just got lucky)
> 4) it won't rebuild itself because ensure-directories-exist doesn't
OK, thank you, that's good to know.
> The problem (which is not the problem that you're having, but ...) was
> introduced by my unix-stat change: there used to be a check in it for
> the empty string
> (defun unix-stat (name)
> (declare (type unix-pathname name))
> (when (string= name "")
> (setf name "."))
> so that (unix-stat "") would stat the current directory
> I removed it ((unix-stat "") now returns NIL just like the equivalent
> C function returns the equivalent -1) when I put the wrappers in - on
> the grounds that I considered it broken (and that there was no
> parallel check in unix-lstat; had there been, I might have assigned it
> slightly greater merit). Unfortunately, it's required ...
This seems to be an example of our thinking alike, in two
(1) You're very likely remembering *wanting* to remove it, showing
that you agree with me that it's a stupid wart.
(2) Whatever bad software feng shui has been bringing me extra
confusion this week may be visiting you, too, since unless
I'm even more confused than before, you didn't remove the test,
tried to tidy up Lisp-level stat stuff; removed mysterious
(STRING= NAME "") behavior from UNIX-STAT
> ENSURE-DIRECTORIES-EXIST will attempt to call (unix-stat "") when
> called with a pathname whose directory component is relative. I think
> the right thing is to fix ENSURE-DIRECTORIES-EXIST rather than kludge
> UNIX-STAT, but I wonder if the workaround is also needed elsewhere.
Hmm, I did wonder whether the special treatment of "" was needed. (I
was pretty sure it had been needed some time in the evolutionary past,
but a quick check didn't spot any places where it was obviously needed
now.) Now I know. And I fully agree that the correct way to deal with
it is to fix the caller, so I'll take a shot at that before trying
to rebuild the system with itself.
> I don't have a patch, but please find attached a test script. For the
> moment I'll hack around it and carry on to see if I can find the
> _actual_ problem with this thing, but I thought you might want to know
> this anyway.
William Harold Newman <william.newman@...>
"Tweak alpha so it sends SIGBUS for unaligned access, and does NOT
do a fixup. This encourages people to fix their code." -- a commit
note from <http://www.OpenBSD.org/plus29.html>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C