C_ToolShed
29 messages in this thread
Black Belt Systems is pleased to announce the C_ToolShed. This is a product
aimed at those who do C development on the Amiga.
It consists of two separate sections – the first is a complete
"Boilerplate" set of C sources which form the basis for a robust Amiga
application. We provide source code for WorkBench and CLI argument handling
– and I do mean handling, this is really different and useful – source for
a complete ARexx host – source for the usual Windows, Intuitext, Menus,
Timer, Serial port, Intuition control loop; The source has built in
CLI-help and error handling, both from tables, no extra code required no
matter how many cmes you add. There is also a linkable file requester
(optional use, of course) with some nice boolean requester capabilities
too.
The second section consists of a bunch command utilties. Either they don't
exist elsewhere, or these are superior to what we've seen. I'll just give
one example here.
We have a _complete_ autodoc generator. It takes C source code, and from
the comments it (1) generates a "body" of a document with section headers,
page/file references for each doc section, and page numbers. It builds a
complete table of contents, in page number order (the body text is
generated in the order the comments are encountered), and lastly, it builds
a complete index based upon keywords found in the comments – you control
the keywords. The files it will process are defined by a listfile, which
simply has the form file1 c/r file2 c/r… fileN c/r. It's really a
teriffic tool to have if you want paper docs (other than the code itself),
and it's a must if you are working with another person or persons on a
project.
There are lots of other tools on there, and lots more source code goodies.
We've priced it at 19.95 so that it can be purchased BEFORE people enter
into a C project; we know the average programmers ship hasn't even left the
other port yet, much less "come in".
We supply boilerplate comments so you'll have a really good start on how to
build them for the best documentation. The main source is autodoc'ed too
(of course). ;^)
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
If your C_ToolShed has a "buitifier" for program code as part of
the utilities…does it have the ability to allow the user to decide if
they'll use the "UNIX style" or "alternate style" of bracing?
eg:
UNIX style:
if (this) {
that();
too();
}
alternate style:
if (this)
{
that();
too();
}
Don
It has a pretty printer – but it's one style only. And I'm sure you know
what the style is. No one is forced to use it… but I don't intend to
encourage that cr*p K&R use. :^)
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
Why aren't I surprised at your answer…and here I thought you were
all for "user choices".
Don
I am, Don. You can choose to use our formatter if you wish to participate
in our vision of C coding standardization. We feel it's worthwhile.
It is your choice, the users, to participate or not. Our position is to
provide a tool that promotes what we feel is a positive step for the user
community. Why should we do something to promote a style or styles we feel
is harmful? That would be rather silly.
You want a formatter for K&R style? Find one, or write one. Don't expect us
to do it. We're not in the business of promoting old-tech.
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
Remember your message…I will throw it back at you at some point
in the future when you bitch about some program not offering the user a
choice in the way things get done when there are several "standards" for
doing it.
Like remember the wildcard "battle"? I don't recall your stand on
the issue…so won't throw it back at you right away. But I think you know
what I mean.
Don
My stand was, the Amiga's wildcards are more powerful than the old style, I
like them, in fact I prefer them, and do not wish to see the '*' used in
the file system for other than the console and so on.
I'm not all that hot on flexibility, Don. Not that kind. There needs to be
some kind of bottom line standard everyone takes off from – and that goes
for language writing as much (or more than) anything else. One of the
primary problems with all the PD c code is much of it is unreadable,
uncompilable (due to ILAC, for instance – _the_ slimy programming practice)
and just generally unusable.
I've good good, solid reasons for what I want in C code. I run an
engineering dept that has a number of people doing things at one time – I
can't be dealing with a bunch of sloppy formatting; so I eliminated the
problem. Now, that increased my ability to deal with my work so much that I
can't possibly ignore it. Others who have been "forced" into this style are
happy they were. No exceptions. We have three new people coming on board,
hopefully, in the next 3-4 weeks – I'll let you know if any of them have
problems. But, in the meantime, it looks to me like I have a _very_ good
means of eliminating a large number of problems. I aim to stick by it
unless something better comes along – which so far, nothing has even come
close. I'm sharing that in the ToolShed package, to be used or not as the
buyer pleases. The idea was to share it – not to provide Yet Another C
Formatter to munge code to the users taste. Those are already out there.
Ben
Amateur Radio Callsign is A A 7 A S
That's the best reason for a C coding standard. It doesn't better what
standard you use, as long as you DO use a standard. I'm a firm believer in
that. In fact, when I joined the group I'm in at work, I changed my coding
style to conform to their standards. It works out great. I can pick up
about any piece of code we have, and I'm not lost trying to figure out
which style is being used.
As for which standard to use, that's up the development group.
Steve
Yep – and my development group is a dictatorship. :*)
Guess who wears the spurs? :*)))
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
I fully agree…within a group, all should stick to a single
standard, no matter which standard that may be. At work, where I do 99% of
the maintance of other's code…I have a heck of a time deciphering other's
code until I run it thru cb (the UNIX C beautifier) which matches my
prefered style. Unfortunately, I don't have the power to enforce a single
standard, else I would. No one else seems interested in the subject.
My only point was the usual that user's have a choice where there
are several "standards" for doing the same thing. We've all seen flame
wars where folks get real upset when someone (or program) enforces a single
style that matches their preference…but not necessairly other's
preferences.
An example was the wildcard issue…as I said, I didn't recall your
stand on that issue…so wasn't going to re-hash it.
Don
Har! Sorta like Henry Ford's concern for user choices when he made the
Model A.
-larry
Larry, I was wondering about the terminal type "amiga" on Suns (is it
elsewhere as well). Basically, it doesn't work right. Frankly, I was
shocked there was one at all. Do you know anything about this? I am using
this termcap by a Mr. Polk with dnet. Of course, everything that happens at
Sun is directly due to you, right?
— Ethan
Heh heh.. well, there are one or two things I don't have any say in at Sun.
<chuckle>
I haven't used the amiga termcap supplied by sun, and use ansi instead when
I am running Aterm. Seems to work fine for me. I do have an amiga termcap
in my home directory at work, that I put there a few years ago, but I can't
remember if it worked well or not. I'll check it out and see what
difefrences there are, and if there are some differences, I'll send it to
you.
One thing though, the way it works is dependent not only on the termcap,
but on what terminal program you are using. Some may not pass certain
sequences or characters on to the screen, and if that's the case, you could
be out of luck if there is no way to do the operation othewrwise,
-larry
I am using dnet, which as I understand it opens a con: window. Other
people claim to not have any problem with the same termcap file. The unix
machines I use are Sun 4s. That's all I know about them. They also crash a
lot. And the NFS server is very buggy. But besides that, … 8^>
Seriously, I would appreciate knowing if it works on yours. When RI is
issued I get a C on my screen as opposed the correct code to move the
cursor right. Thanks,
— Ethan
Ethan,
I used 'ansi' when I had DNet hardwired to the Sun 2/50, and it was no
problem at all, as I remember. I can't test it out right now, because I
have the Sun down for some mods.
Sun 4s crashing a lot? Hmm… not around here they don't. What OS are
they running? (rev)
-larry
They are running some wierd combo of BSD and Sun OS I've been told.
The problem is with the NFS. There is a bug in it and it prevents some
crashed tasks from being removed. Over a week or two the number of hung
tasks build up and slows down things tremendously.
— Ethan
Don,
If you're looking for a good code "beautifier", you might want to take a
look at GNU's indent. It has numerous options for different coding styles,
including the ones in your last message. At any rate, I'm just finishing a
port of the latest indent code and should have it ready to upload tomorrow.
– Dave
Dave,
Ok….actually, for my own use…I just write it "right" the first
time. When I get sample code, and want to clean it up…I just run it thru
cb on our UNIX box at work. But I'll take a look at your indent program,
might save me an up/download to the UNIX box.
Don
Don,
Indent will be uploaded tonight. I had to track down a few gotchas in
the code (the original programmer relied on malloc() returning a zeroed-out
memory block) and add some prototypes for Lattice, so it took a little
longer than I thought. At any rate, I think you'll find it far superior to
cb.
I've found it invaluable at work. Our sccs scripts automatically
"indents" a module to a standard format before checking it in, so every
programmer is free to use the format he/she likes best. Eliminates a lot
of the "my format is right, yours is wrong" arguments…
– Dave
Dave,
Ok…I'll look for it later on. Thanks!
Don
I think you'll find that there is already a version of indent in the
libs. I found a UNIX=>MsDOS port on BIX and recompiled it for the Amiga a
couple of months ago. The only changes I made to the code were in dealing
with the difference in path names. I'd agree that it is a very versatile
program, and I'd love to see your version.
By the way, the version I ported was copyrighted by Sun, and released to
the PD. It sounds as if you're dealing with another GNU rewrite 😉
Jeff,
The indent I uploaded is also copyrighted by Sun, though severely
modified by GNU. It must be somewhat newer than the one in the libs, as it
contains more options. If you have no problems with the one you ported,
then there is probably no reason to switch. I had simply become dependent
on some of the options found in the newer version.
– Dave
I just took a quick look at your upload, and they have the same
copyright notice. Your port is noticably larger, but I notice that you
wrote up a decent Amiga version readme. Me, I just added a comment to the
existing doc (right after where the guy who had ported it to the Mac had
added his 😉 Considering that I did very little more than recompiler the
thing (I put the default profile file in S:), I didn't feel comfortable
with taking any more credit than that.
I'll take a look at the extra options. There were a few minor nits I
had with the version I had ported, maybe with yours I'll be able to format
my code exactly the way I want. In any case, I'll try it out. Extra size
for extra features is a tradeoff I'm willing to make.
I just had another thought. Howabout the next time a C code
formatting argument gets started we enforce INDENT options as a common
vocabulary. I can see it now:
" USE '-ce'!"
" NO, you fool, USE '-nce'!"
Cretin! Any fool knows you use '-ce'! 🙂
The readme file started out as a single, concise paragraph. Then I figured
I'd better add a bit about the s:.indent.pro file. From there I figured I
should detail some of the command line options and from then on it was
pretty much downhill… So much for being concise.
– Dave
Or for that mater…
if (this) {
that();
too();
}
or…
if (this)
{
that();
too();
}
Sure wish we had a vgrind for this machine. 🙂
-larry
Ordering information, please? (re: C_ToolShed)
(my ship hasn't even broken the compiler out of the box yet 🙂
tmm/Richard Cunningham
Die and go to BBS Hell 🙂
You can order using VISA, MC, or COD by telephone. Call:
(800) TK-AMIGA 9-12 and 1-5 Mountain time. It's toll free, of course.
You can order by mail, sending check or money order. We do NOT suggest the
use of cash – the postal service is comprised of government employees…
draw your own conclusions.
Black Belt Systems RR1 Box 4272 398 Johnson Road Glasgow, Montana 59230
Ben
Amateur Radio Callsign is A A 7 A S