nazgul@apollo.UUCP (06/20/87)
Extending the DM
J.W. Peterson states that he sent in a UCR complaining about the lack
of word wrap, extensibility, etc. in the DM two years ago and nothing ever
happened. From this he concludes that it's not worth complaining. I beg
to differ. We listen to complaints and we try to act on them. Due to the
realities of software releases, schedules and the like we unfortunately can't
say much more than "we'll consider that" even if we *are* doing more. I
will grant you that two years is a long time to wait - I've certainly been
itching for the changes myself. As usual it has been a question of whether
to do the quick patch, or do it right. Ideally we'd like to do both -one
for the short term, one for the long - but that simply takes up too many
people's time.
So keep sending UCRs. In fact I'll ask you one better. If you have specific
things you'd like to see Apollo do in the user environment arena, (e.g.
windowing, key definitions, editors...), send me mail. I'm not talking about
bug reports or specific enhancement requests - those should be UCRs - but
rather what you're ideal user environment would look like. Do you want tiled
windows? Overlapping? Psuedo-tiled (like the ones I recently posted)? What
kinds of things do you want to use keydefs for? Would you like to have them
more context senstive? Bind them to specific programs? (Actually even now you
can bind them to specific streams, see pad_$def_pfk). What's the ideal editor
look like? Multi-font? Word-wrap? Give me a list of what you'd like and
(importantly) prioritize it.
I'm not promising we'll do any of it, I'm certainly not promising that I'll
respond to any of it, but I *do* promise that it will get to the people who
are working on those issues and that it will be taken into account in what
ever work we do. Remember, so long as we work in a vaccum the only thing you'll
get from us is what we *think* you want. If you trust our guesses, don't
send us any information.
[Oh boy, now my mail box is in BIG trouble!]
Actually, if you could do me the favor of including the string "ue-request"
in the subject line I'd appreciate it, then at least I can have AZ store it
in a separate inbox.
------
DSEE Benefits
A couple of things that I think DSEE has over RCS/Make.
DSEE manages binaries. This means that if I'm working on one part of
a system, and someone else is working on another, we can share binaries.
DSEE keeps track of what binaries have been built using what compiler options.
The model description tells it which options are critical and which are not,
so it knows whether or not you can use the result of someone elses build.
This is very nice on large projects when multiple people are working on
different branches of a few files, but need to share the rest. Furthermore
you can tell DSEE whether or not the tools are critical, so if you get a
new compiler, or translator or whatever tool you are using, DSEE will know
whether it should recompile everything.
DSEE can automatically perform actions when something happens (such as
the replacement of an item). So you can tell it to watch a file for you
and tell you when it changes.
DSEE supports threads. These allow you to tell DSEE what versions of
what files to use when you build, and what options to use on what files
(either specifically or by wildcard). For instance I often have a thread
that looks like this:
-for %.c -reserved -use -O -g -T bsd4.2
-reserved
-for %.c -exact -use -O -T bsd4.2
/nazgul -when_exists
[]
Or, in English:
Compile reserved (checked out) files using -O, -g and a systype of bsd4.2.
Use the reserved version of a file if it exists.
For other files use exactly the flags -O and systype of bsd4.2
(this ensures that all non-reserved files don't have debug flags on)
IF there's a branch in my name use it.
Otherwise take whatever you can get.
Threads allow you to do things like (as I just did now) tell DSEE that I want a
different version of a header file and have it promptly know that as a result
it has to recompile five other programs that depend on that file.
DSEE supports multiple builders. For instance I have a version of the
ICON programming language under DSEE. It consists of 4 libraries (insert
files, translator, linker, runtime) under control of a single dsee model.
There are about 80 files in all. I'll start off a rebuild of everything
right now and see how long it takes. This will take a little longer than
a normal build, since it purges the old builds in the process, but it should
still give you and idea of the advantage.
------
Converting to DSEE
Converting *any* software system from one system of control to another
is going to be painful. In going from Makefile control to DSEE I've generally
found it better just to start from scratch. Make and DSEE have opposite views
of the world (consider "make foo.o" vs. "build foo.c" and you'll get an idea
of the difference). I've written a shell script which runs in conjunction
with the DSEE make_model tool. You run it over your .c and .h files and
it produces a DSEE model that's just about ready to run. Once you've got
the model description out of the way converting to DSEE becomes *much* easier.
I will send the script and some rudimentary instructions (I haven't had time to
write a man page for it) to Scott Turner for him to add to his Apollo archive.
Kee Hinckley
Oh yes! The DSEE build time?
DSEE> sh date
Sat Jun 20 16:14:25 EDT 1987
DSEE> build -force_all
...
Build completed.
95 builds were required,
all were completed successfully.
DSEE> sh date
Sat Jun 20 16:30:27 EDT 1987
16 minutes.
--
UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu
I'm not sure which upsets me more; that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.