|
Be Newsletter
Issue 39, September 4, 1996
Table of Contents
BE ENGINEERING INSIGHTS: Source Code Control on the BeBox
By Ming Low
Life was good from Winter to Spring and Summer to Fall. I
was the lone escapee from the weekly newsletter article. I
wore pocket protectors, kept a messy office, walked zigzag
and backwards, and hid in small corners for days just so I
couldn't be found. I anticipated... I planned... I executed.
But I forgot to turn off BeMail. "You have 1 new message." I
didn't have to look twice to know it was a message from Her.
I tried to delete the message, but I stumbled and deleted
the apps folder instead. Panicking, I hit the reset button
and forced a rebuild of the database... just as She was
walking into my office. With my database nuked, I was sure I
had covered my tracks. But when my machine came up, the
mail_deamon told a different story: "There is 1 unread
message." I was red-faced and caught with the e-mail in my
BeBox. I had no choice; I uncapped my pen and pulled out my
checkbook. But I didn't have enough in my checking account
to cover what She wanted.
So now it's time to do some writing on managing your source
files on the BeBox.
With the DR7 release, we started shipping the GNU source
code control utilities, called Revision Control System
(RCS). We use these tools at Be as a back-end for our source
code control. The RCS tools let you store, retrieve, merge,
log changes, and identify revisions to your source files.
The commands to check out a file from RCS and to check it
back in again are as simple as
"ci <filename>"
and
"co <filename>"
This method works well, but it can become cumbersome if you
have multiple directories or nested subdirectories. And
beyond the usability issue, there's also the fact that your
working directory will be cluttered with an equal number of
RCS ",v" files.
The easiest way to get around these problems is to write a
few Bash shell scripts that can:
- Pass the appropriate options to
ci and co
- Descend subdirectories to look for files to check in or
out
- Redirect the target RCS from current working directory
to a "mirrored" RCS repository directory
- Create "missing" directories when you ask to check out a
file that's far down the RCS tree
Through these scripts, you can tailor and reduce the
complexity of creating a simple source code control system
on the BeBox.
There are a couple of gotchas currently in the BeBox that
will make writing and using these scripts not as
straightforward as they could be. One is that scripts are
executed very slowly on the BeBox. This problem, which is
targeted to be fixed for DR9, can be traced to the way fork
and exec work.
The other major gotcha is that the file system doesn't check
the write permissions of a file. The danger in this is that
you can check out a file as read-only, yet still edit the
file. Furthermore, while you will be able to edit the file,
RCS will not let you check it in as a revision. The simple
solution for this may be to just set up all files in RCS as
nonstrict, allowing check-in of files without locking.
At Be, we use many scripts and programs that cover the basic
RCS tools.
I hope that this brief introduction to the RCS system,
combined with the RCS documentation in the
/documentation/Shell Tools directory, will help you create
and tailor a source code control system for your project.
BE DEVELOPER TALK: Mark Smith, Halibut Computers
E-mail:
mark@halibut.com
I'm a third year student at Cal Poly, San Luis Obispo, in
Computer Engineering. I first saw the BeBox while on an
Internship with InterNex Information Services in Santa Clara
(practically neighbors!). I liked it when I first saw it,
and I still like it now. The idea of a computer that's
trying to learn from the mistakes of all the current
platforms sounded very interesting.
My two main interests have always been music and computers.
It wasn't until recently that I started to get into mixing
the two, and even now I see that the publicly available
music software sucks -- I hope to change that. In addition
to music, I'm also interested in networking. (Networking and
sound, now there's a combination.) The BeBox looks good for
the sound side of things: Real-time mixing, sampling, and
sequencing.
When I look for a new computer, I first look at what's
cheap. (Hey... I'm a student. What can I say?) The BeBox
looks like an excellent platform for its price. It's also
got the I/O that I want for my projects. The GeekPort(TM)
will make interfacing to drum pads a breeze, the MIDI ports
will make an obvious impact, and the 16-bit I/O is also a
huge advantage. And it all comes standard!!
From my one-person company, Halibut Computers, I run a
bulletin board service (Citadel UX). I'm thinking of porting
it to the BeOS(TM). I'm also working on some sound remixing
software for Linux. In general, I'm interested in developing
public domain software in the spirit of GNU. I'd also like
to share ideas with other Be developers that have interests
similar to mine. Anyone else willing (read: crazy enough) to
shell out the $1K to work on public domain sound and DSP
stuff? If there are other developers that are willing, I'd
like see if we can't start working on things together. It's
better to not have to reinvent the wheel, brakes,
suspension, steering, and all the other standard options
when trying to build a sports car.
Browsing the Rumors
By Jean-Louis Gassée
My column on the war of two browsers last week triggered the
highest volume of e-mail responses yet to my weekly essays.
I must have underestimated the heat of the browser war and
the interest it generates. Several readers pointed to an
apparent omission: Microsoft has been shipping a Mac version
of Explorer 2.0 for a while and I failed to mention it. This
is true, the omission was intentional and poorly presented.
What I should have said is: At the 2.0 level, on the Mac or
on Windows, Internet Explorer could not compete with
Navigator, its much more complete feature set (news, mail,
multiple simultaneous downloads...), and much better
execution. I appreciate the feedback and the opportunity to
clarify my position.
Speaking of clarity and position, I have to deal with the
two "Wall Street Journal" stories of August 29 and September
3. These stories report rumors of conversations between
Apple and our little company and raise various
possibilities, including an acquisition. I could pretend the
stories aren't there, but that wouldn't make them go away.
For the record, I can but confirm what I told "MacWeek" when
they asked about secret meetings at Macworld in Boston,
following our presentation of the BeOS port on a Power
Computing Mac clone. Nothing of the sort took place. The
only conversation I had with an Apple executive, Heidi
Roizen, was about wines and lazy afternoons on barges
floating down canals in Burgundy. I shook hands with Ike
Nassi when he passed by our booth and took pictures of an
Apple Fellow, Guy Kawasaki.
I also confirmed to "MacWeek" that I discussed technical
cooperation with Michael Spindler. I felt both parties might
benefit, being part of the PowerPC alliance. The first
conversation took place in the Spring of 1994, as we were
porting our system from the Hobbit to the PowerPC. The
second happened in February 1995. At the time, I was looking
at the whites of the repo man's eyes, we were running out of
money, and I offered Michael Spindler a financial
transaction that would keep our company afloat and provide
Apple some insurance against delays or other problems with
Copland. Nothing came out of these discussions and, with the
usual but unfair 20/20 hindsight, it's probably for the
best.
Instead of receiving assistance from Apple, we were helped
by friendly investors. My associate Jean Calmon and I lent
funds to the company for a while and, in April 1996, we
raised $14 million (see our web site for details), thus
giving us the financial viability needed to develop our
business. When I write "for the best," I mean we enjoy a
situation where agendas are nicely aligned: Developers,
investors, the team, everyone agrees on what needs to be
done. None of our investors, this includes all Be employees,
is in any hurry to unload shares. With alliances, different
cultures and goals are often hard to align, efficiency and
agility tend to suffer, and motivation can be hard to
maintain. This seems to be the sentiment on the net. Most
people who comment on newsgroups advise us to stay
independent, for fear of losing the agility and focus that
got us where we are today.
We agree. We still have a lot to do and a lot to prove. DR8
is in duplication and we're now focusing on DR9, the port to
PowerMacs, and the CD we'd like to sell out of our booth at
the San Francisco Macworld in January 1997.
BeDevTalk Summary
BeDevTalk is an unmonitored discussion group in which
technical information is shared by Be developers and
interested parties. In this column, we summarize some of the
active threads, listed by their subject lines as they
appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on
our web site: http://www.be.com/aboutbe/mailinglists.html.
- ---- NEW -------------
Subject: Dependencies and installers and shared libraries
AKA: Sound card discussion (or why my BeBox sounds better
than my PC)
AKA: Audio
A reminiscence on Amiga turned into a discussion of what
machine would make the best multimedia kiosk box.
Unsurprisingly, a number of Be proponents were in the
audience. The MM kiosk idea begat talk of the advantages of
built-in sound (versus sound cards).
- ---- NEW -------------
Subject: Filesystem Links
AKA: Links: to SymLInk or not to SymLInk
Some discussion of how hard and soft links should be
implemented in the Be file system (and a bit of a UNIX and
shell link tutorial). The implied necessity of links was
questioned: Some folks think that record_refs obviate the
need for links; others think that links are needed, and the
sooner the better.
- ---- NEW -------------
Subject: How are we suppose to do this?
Polling and redrawing; if you want smooth game animation,
does the application's redraw frequency need to exceed (or
even equal) the monitor's vertical blank rate? A short
introduction to gaming terms ("physics rate,î "gfx rate")
culminated in the blessing of 15 Hz as a "good enough"
redraw rate. Others differed, citing low rates as a cause of
"VR sickness;" some folks think that 15 Hz is simply too low
given that the brain can process 100 images a second.
Relatedly, should polling the user's input be faster than
the redraw? It was offered, not without objection, that it's
pointless to poll faster than you draw.
- ---- NEW -------------
Re: L2 cache and 603e (was: Be told me this ...)
Anticipation of the 133 MHz 603e spawned talk of performance
improvement; Dominic Giampaolo (of Be) posted some
benchmarks. The lack of an L2 cache was lamented, but, as
one writer pointed out, the 66 MHz 603 doesn't have an L2,
but it's zippy, nonetheless.
- ---- NEW -------------
Subject: X Windows for Gamekit
AKA: Drawing in another app's window
Should Be support X? The X champions say "Why not?" The
thread then veered into a discussion of whether inter-
application drawing should be allowed, and how it should be
implemented. Sending "draw it like this" info in a BMessage
to the remote app was suggested.
- ---- NEW -------------
Re: Honey, let's get Married!!!
This thread carries the file representation torch that
proved too scorching in previous incarnations (notably, the
filename case-insensitivity thread). Given here were
theories on how the GUI and the shell should display
filenames, and how the two should interact. For example, it
was proposed that if you drop a file icon into a shell
window, the shell should display (as text) the file's name.
|
